From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <legion@altlinux.ru> Date: Mon, 15 May 2023 12:43:40 +0200 From: Alexey Gladkov <legion@altlinux.ru> To: make-initrd@lists.altlinux.org Message-ID: <ZGIM3OKjStcnGgzm@example.org> References: <cover.1683200226.git.gladkov.alexey@gmail.com> <6b444ed922286eb3df8f5322b1bddf9c55753eb8.1683200226.git.gladkov.alexey@gmail.com> <ecf9f7a7-5f84-adaa-c374-1d02c8a7ff76@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <ecf9f7a7-5f84-adaa-c374-1d02c8a7ff76@gmail.com> Subject: Re: [make-initrd] [PATCH 1/3] Reimplement ueventd X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: <make-initrd.lists.altlinux.org> List-Unsubscribe: <https://lists.altlinux.org/mailman/options/make-initrd>, <mailto:make-initrd-request@lists.altlinux.org?subject=unsubscribe> List-Archive: <http://lists.altlinux.org/pipermail/make-initrd> List-Post: <mailto:make-initrd@lists.altlinux.org> List-Help: <mailto:make-initrd-request@lists.altlinux.org?subject=help> List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/make-initrd>, <mailto:make-initrd-request@lists.altlinux.org?subject=subscribe> X-List-Received-Date: Mon, 15 May 2023 10:43:42 -0000 Archived-At: <http://lore.altlinux.org/make-initrd/ZGIM3OKjStcnGgzm@example.org/> List-Archive: <http://lore.altlinux.org/make-initrd/> On Mon, May 15, 2023 at 07:38:30AM +0300, Leonid Krivoshein wrote: > > On 5/4/23 16:42, Alexey Gladkov wrote: > > [...] > > diff --git a/datasrc/ueventd/queue-processor.c b/datasrc/ueventd/queue-processor.c > > new file mode 100644 > > index 00000000..ab5e03e4 > > --- /dev/null > > +++ b/datasrc/ueventd/queue-processor.c > > @@ -0,0 +1,116 @@ > > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > > + > > +#include <sys/types.h> > > +#include <sys/stat.h> > > +#include <sys/wait.h> > > + > > +#include <stdlib.h> > > +#include <stdio.h> > > +#include <string.h> > > +#include <signal.h> > > +#include <dirent.h> > > +#include <fcntl.h> > > +#include <errno.h> > > + > > +#include "ueventd.h" > > + > > +static void event_handler(struct watch *queue, char *path) __attribute__((nonnull(1, 2))); > > +static void move_files(char *srcdir, char *dstdir) __attribute__((nonnull(1, 2))); > > +static void signal_unhandled_events(struct watch *queue) __attribute__((nonnull(1))); > > + > > +void event_handler(struct watch *queue, char *path) > > ЗдеÑÑŒ оба ÑƒÐºÐ°Ð·Ð°Ñ‚ÐµÐ»Ñ Ð¼Ð¾Ð³ÑƒÑ‚ быть конÑтантными, Ñ‚.к. данные не менÑÑŽÑ‚ÑÑ Ð¸ > дальше не передаютÑÑ. > > > > +{ > > + char *argv[] = { handler_file, path, NULL }; К Ñожалению path быть const не может так как иначе вот тут вылезет предупреждение. РеÑли тут Ñделать argv конÑтантным, то ругань будет на execve, потому что execve принимает char *const argv[]. > > + pid_t pid = vfork(); > > + > > + if (pid < 0) { > > + err("fork: %m"); > > + > > + } else if (!pid) { > > + execve(argv[0], argv, environ); > > КомпилÑтор не ругаетÑÑ Ð·Ð´ÐµÑÑŒ только потому, что подключен <unistd.h> > через "ueventd.h", а ругатьÑÑ Ñƒ него целых два повода (execve и > environ). ЕÑли Ñ‚Ñ‹ предполагаешь, что тут должна быть ругань про отÑутÑтвие Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð¸Ñ execve и environ, то Ñ‚Ñ‹ ошибаешьÑÑ. Ругани тут нет так как Ð¾Ð¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð¸Ñ Ð¿Ñ€Ð¸ÐµÐ·Ð¶Ð°ÑŽÑ‚ через ueventd.h. Или Ñ‚Ñ‹ про какие поводы Ð´Ð»Ñ Ñ€ÑƒÐ³Ð°Ð½Ð¸ ? > Ðто Ñ Ðº тому, что в твоём заголовочном файле он подключен Ð´Ð»Ñ > logging.c, а не Ð´Ð»Ñ queue-processor.c. СоглаÑно man 7 environ можно не > объÑвлÑÑ‚ÑŒ Ñту переменную в коде, еÑли <unistd.h> подключаетÑÑ Ñ > _GNU_SOURCE, Ñ‚.е. как раз твой Ñлучай. Что значит подключён Ð´Ð»Ñ logging.c ? unistd.h проÑто подключён в ueventd.h. ВеÑÑŒ Ñтот код компилируетÑÑ Ñ Ð³Ð»Ð¾Ð±Ð°Ð»ÑŒÐ½Ñ‹Ð¼ _GNU_SOURCE. > > > > + fatal("exec: %s: %m", argv[0]); > > + } else { > > + int status = 0; > > + > > + if (waitpid_retry(pid, &status, 0) != pid || !WIFEXITED(status)) > > + info("%s: session=%lu: %s failed", > > + queue->q_name, session, handler_file); > > ÐаÑчёт "session=%lu..." только лишь глÑÐ´Ñ Ð² Ñтот код понÑл, что и Ñам в > не публичном коде опрометчиво иÑпользую uint64_t Ñ Ñ‚Ð°ÐºÐ¸Ð¼ > форматированием, Ñ…Ð¾Ñ‚Ñ Ð²ÐµÐ·Ð´Ðµ по коду должно быть "session=" PRIu64 "...". > Ðужно подключить заголовочный файл <inttypes.h> либо иÑпользовать > какое-то приведение типов. Пренебречь Ñтим, как ÑейчаÑ, можно только > полагаÑÑÑŒ на конкретные платформы. Я знаю про PRIu64, но его иÑпользование не понимает clang и получаетÑÑ Ð²Ð¾Ñ‚ так: datasrc/ueventd/queue-processor.c:40:27: warning: format specifies type 'char *' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] queue->q_name, session, handler_file); ^~~~~~~ datasrc/ueventd/ueventd.h:70:69: note: expanded from macro 'rd_info' #define rd_info(format, arg...) rd_log_message(LOG_INFO, format, ##arg) ~~~~~~ ^~~ datasrc/ueventd/queue-processor.c:40:36: warning: data argument not used by format string [-Wformat-extra-args] queue->q_name, session, handler_file); ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ datasrc/ueventd/ueventd.h:70:69: note: expanded from macro 'rd_info' #define rd_info(format, arg...) rd_log_message(LOG_INFO, format, ##arg) ~~~~~~ ^ 2 warnings generated. то еÑÑ‚ÑŒ как видишь у clang PRIu64 превратилоÑÑŒ в пуÑтую Ñтроку и аргументы Ñъехали. Таким образом иÑпользование PRIu64 Ñразу делает код gcc-specific. > > > + else > > + info("%s: session=%lu: %s finished with return code %d", > > + queue->q_name, session, handler_file, WEXITSTATUS(status)); > > + } > > +} > > + > > +void move_files(char *srcdir, char *dstdir) > > ЗдеÑÑŒ оба ÑƒÐºÐ°Ð·Ð°Ñ‚ÐµÐ»Ñ Ñ‚Ð¾Ð¶Ðµ могут быть конÑтантными. Ð’ принципе да. > > +{ > > + struct dirent *ent; > > + int srcfd, dstfd; > > + > > + if ((srcfd = open(srcdir, O_RDONLY | O_CLOEXEC)) < 0) > > + fatal("open: %s: %m", srcdir); > > + > > + errno = 0; > > + if ((dstfd = open(dstdir, O_RDONLY | O_CLOEXEC)) < 0) { > > + if (errno == ENOENT) { > > + if (mkdir(dstdir, 0755) < 0) > > + fatal("mkdir: %s: %m", dstdir); > > + dstfd = open(dstdir, O_RDONLY | O_CLOEXEC); > > + } > > + if (dstfd < 0) > > + fatal("open: %s: %m", dstdir); > > + } > > + > > + DIR *d = fdopendir(srcfd); > > + if (!d) > > + fatal("fdopendir: %m"); > > + > > + while ((ent = xreaddir(d, srcdir)) != NULL) { > > + if (ent->d_name[0] != '.' && ent->d_type == DT_REG && > > Поле d_type заполнÑетÑÑ Ð½Ðµ на вÑех ÑиÑтемах (не на вÑех файловых > ÑиÑтемах), доверÑÑ‚ÑŒ можно только d_name и d_ino. ЕÑли вÑÑ‘ Ñто проиÑходит > на ramfs и еÑÑ‚ÑŒ уверенноÑÑ‚ÑŒ, что в ней Ñто поддерживаетÑÑ, то и нет > проблемы... пока в Ñтот ramfs не Ñмонтировать что-то ещё и не начать > иÑпользовать Ñтот же код Ð´Ð»Ñ Ð´Ñ€ÑƒÐ³Ð¾Ð¹ файловой ÑиÑтемы. С одной Ñтороны Ñ‚Ñ‹ прав, но Ñ Ð´Ñ€ÑƒÐ³Ð¾Ð¹ Ñтороны Ñтот код не предназначен Ð´Ð»Ñ Ð²Ñ‹Ð¿Ð¾Ð»Ð½ÐµÐ½Ð¸Ñ Ð½Ð¸Ð³Ð´Ðµ кроме initramfs, где Ñтой проблемы нет. Ð Ð´Ð»Ñ Ð¾Ñ‚Ð»Ð°Ð´ÐºÐ¸ d_type поддерживаетÑÑ Ð²Ñеми оÑновными файловыми ÑиÑтемами. ЕÑли бы Ñто был портабильный код, то Ñ ÑоглаÑен, что нужно было бы делать иначе и городить отдельный stat. > > + renameat(srcfd, ent->d_name, dstfd, ent->d_name) < 0) > > + fatal("rename `%s/%s' -> `%s/%s': %m", srcdir, ent->d_name, dstdir, ent->d_name); > > + } > > + > > + closedir(d); > > + close(dstfd); > > +} > > + > > +void signal_unhandled_events(struct watch *queue) > > И здеÑÑŒ указатель может быть конÑтантным. > > > > +{ > > + ssize_t len; > > + > > + len = write_loop(queue->q_parentfd, > > + (char *) &queue->q_watchfd, sizeof(queue->q_watchfd)); > > + if (len < 0) > > + err("write(pipe): %m"); > > + > > + info("%s: session=%lu: retry with the events remaining in the queue", queue->q_name, session); > > +} > > Ðе углублÑÑÑÑŒ в код ueventd.c (только по названию и Ñодержимому функции) > вообще Ð½ÐµÐ»ÑŒÐ·Ñ Ð¿Ð¾Ð½ÑÑ‚ÑŒ, что она делает и причём тут PIPE. РвÑÑ‘ потому, > что Ñ„ÑƒÐ½ÐºÑ†Ð¸Ñ ÑƒÑ‚Ð¸Ð»Ð¸Ñ‚Ð°Ñ€Ð½Ð°Ñ Ð¸ в "ueventd.h" Ð¿Ð¾Ð»Ñ Ñтруктуры watch не имеют > комментариев. Я не пиÑал комментарий тут, потому что мне показалоÑÑŒ поведение очень тривиальным. КлаÑÑичеÑкий ipc. Мы проÑто отÑылаем единÑтвенное Ñообщение оÑновному процеÑÑу еÑли не обработали вÑе Ñвенты в директории. > ПоÑтому Ñпрошу. Она Ñообщает о необработанных Ñвентах? Да. ПередаётÑÑ ÑƒÐ½Ð¸ÐºÐ°Ð»ÑŒÐ½Ñ‹Ð¹ признак очереди, чтобы пометить Ñту очередь как "грÑзную" и попробовать Ñнова её обработать ÑпуÑÑ‚Ñ timeout не дожидаÑÑÑŒ новых Ñвентов. > Похоже, что через PIPE родительÑкому процеÑÑу передаётÑÑ Ñ†ÐµÐ»Ð¾Ðµ чиÑло > (q_watchfd). Ðо почему Ð´Ð»Ñ Ð¿ÐµÑ€ÐµÐ´Ð°Ñ‡Ð¸ через PIPE тут иÑпользуетÑÑ > write_loop()? Ведь в/в через PIPE (даже неблокирующий) вÑегда > транзакционен, еÑли не превышает PIPE_BUF. Я пиÑал Ñтот код Ñ Ð¼Ð½Ð¾Ð³Ð¸Ð¼Ð¸ допущениÑми. ЕÑли включать паранойю, то Ñтот куÑок нужно делать ÑовÑем иначе. Я тут полагаюÑÑŒ на то, что PIPE_BUF доÑтаточно большой. > > + > > +void process_events(struct watch *queue) > > Похоже, тут тоже указатель может быть конÑтантным. > > > > +{ > > + info("%s: session=%lu: processing events", queue->q_name, session); > > + > > + char *numenv = NULL; > > + > > + xasprintf(&numenv, "SESSION=%lu", session); > > + putenv(numenv); > > ЗдеÑÑŒ возможна утечка: пропущен free(numenv), а когда numenv будет > оÑвобождена? Ðет. Ðргумент не копируетÑÑ Ð² environ, а вÑтавлÑетÑÑ ÐºÐ°Ðº еÑÑ‚ÑŒ. Ðто позволÑет не Ñоздавать излишние копии как setenv. putenv(3): The string pointed to by string becomes part of the environment, so altering the string changes the environment. > > + > > + char *srcdir, *dstdir; > > Ð”Ð»Ñ numenv еÑÑ‚ÑŒ инициализациÑ, а тут нет, Ñ…Ð¾Ñ‚Ñ Ð¸Ñпользование одинаковое. > Ðет предупреждений? Ð˜Ð½Ð¸Ñ†Ð¸Ð°Ð»Ð¸Ð·Ð°Ñ†Ð¸Ñ numenv излишнÑÑ, как и в других меÑтах, где иÑпользуетÑÑ xasprintf. Ðта Ñ„ÑƒÐ½ÐºÑ†Ð¸Ñ Ð½Ðµ может вернуть ошибку и результат вÑегда будет в первом аргументе. > > + > > + xasprintf(&srcdir, "%s/%s", filter_dir, queue->q_name); > > + xasprintf(&dstdir, "%s/%s", uevent_dir, queue->q_name); > > + > > + move_files(srcdir, dstdir); > > + > > + if (!empty_directory(dstdir)) { > > + event_handler(queue, dstdir); > > + > > + if (!empty_directory(dstdir)) > > + signal_unhandled_events(queue); > > + } > > + > > + free(srcdir); > > + free(dstdir); > > + > > + exit(0); > > +} > > [...] > > > -- > WBR, Leonid Krivoshein. > _______________________________________________ > Make-initrd mailing list > Make-initrd@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/make-initrd -- Rgrds, legion