Re: [PATCH v5 3/4] proc_pid_fdinfo.5: Add subsection headers for different fd types

Hi Ian, On Thu, Dec 05, 2024 at 11:38:27PM -0800, Ian Rogers wrote: > Make the sections about eventfd, epoll, signalfd, inotify, fanotify, > timerfd better separated with a clearer subsection header. > --- > man/man5/proc_pid_fdinfo.5 | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Re: [PATCH v5 2/4] proc_pid_fdinfo.5: Make pid clearer in the name and 1st paragraph

Hi Ian, On Thu, Dec 05, 2024 at 11:38:26PM -0800, Ian Rogers wrote: > Previously the pid was highlighted through being a tagged paragraph > but not mentioned in the description. Add italics to the path > emphasizing pid and then change the first sentence to include pid in > the definition. > > Su

Re: [PATCH v5 1/4] proc_pid_fdinfo.5: Reduce indent for most of the page

52cae984c07d73dee1c> Have a lovely day! Alex > --- > v5. Remove the word Since. > v4. Since from Alejandro Colomar review comment. > --- > man/man5/proc_pid_fdinfo.5 | 51 +++--- > 1 file changed, 25 insertions(+), 26 deletions(-) > &

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

On Sun, Nov 03, 2024 at 01:05:42AM +0100, Alejandro Colomar wrote: > Hi Colin, > > On Sat, Nov 02, 2024 at 11:47:14PM +, Colin Watson wrote: > > On Sat, Nov 02, 2024 at 10:36:20PM +0100, Alejandro Colomar wrote: > > > This is quite naive, and will not work with pag

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

Hi Colin, On Sat, Nov 02, 2024 at 11:47:14PM +, Colin Watson wrote: > On Sat, Nov 02, 2024 at 10:36:20PM +0100, Alejandro Colomar wrote: > > This is quite naive, and will not work with pages that define their own > > stuff, since this script is not groff(1). But it shoul

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

Hi Branden, Colin, On Sat, Nov 02, 2024 at 11:40:13AM +0100, Alejandro Colomar wrote: > > I also of course have ideas for generalizing the feature, so that you > > can request any (sub)section by name, and, with a bit more ambition,[4] > > paragraph tags (`TP`) too. > &

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

Hi Branden, On Sat, Nov 02, 2024 at 05:08:37AM -0500, G. Branden Robinson wrote: > [adding Colin Watson to CC; and the groff list because I started musing] > > Hi Alex, > > At 2024-11-01T21:07:29+0100, Alejandro Colomar wrote: > > > > > -/proc/pid/fdinfo/ \- info

Re: [PATCH v4 3/4] proc_pid_fdinfo.5: Add subsection headers for different fd types

Hi Branden, Ian, On Sat, Nov 02, 2024 at 04:20:07AM -0500, G. Branden Robinson wrote: > Hi Ian, > > At 2024-11-01T14:18:29-0700, Ian Rogers wrote: > > Make the sections about eventfd, epoll, signalfd, inotify, fanotify, > > timerfd better separated with a clearer subsection header. > > > > Signe

Re: [PATCH v4 1/4] proc_pid_fdinfo.5: Reduce indent for most of the page

Hi Ian, On Fri, Nov 01, 2024 at 02:18:27PM -0700, Ian Rogers wrote: > When /proc/pid/fdinfo was part of proc.5 man page the indentation made > sense. As a standalone man page the indentation doesn't need to be so > far over to the right. Remove the initial tagged pragraph, move the > "since Linux

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

Hi Ian, On Fri, Nov 01, 2024 at 11:19:18AM -0700, Ian Rogers wrote: > On Fri, Nov 1, 2024 at 6:24 AM Alejandro Colomar wrote: > > > > On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote: > > > When /proc/pid/fdinfo was part of proc.5 man page the indentatio

Re: [PATCH v2 1/3] proc_pid_fdinfo.5: Reduce indent for most of the page

On Tue, Oct 15, 2024 at 02:17:17PM -0700, Ian Rogers wrote: > When /proc/pid/fdinfo was part of proc.5 man page the indentation made > sense. As a standalone man page the indentation doesn't need to be so > far over to the right. Remove the initial tagged pragraph and move the > styling to the init

Re: [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup()

On Sun, Sep 29, 2024 at 09:58:30AM GMT, Alejandro Colomar wrote: > [CC += Andy, Gustavo] > > On Sat, Sep 28, 2024 at 02:17:30PM GMT, Kees Cook wrote: > > > > diff --git a/mm/util.c b/mm/util.c > > > > index 983baf2bd675..4542d8a800d9 100644 > > >

Re: [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup()

[CC += Andy, Gustavo] On Sat, Sep 28, 2024 at 02:17:30PM GMT, Kees Cook wrote: > > > diff --git a/mm/util.c b/mm/util.c > > > index 983baf2bd675..4542d8a800d9 100644 > > > --- a/mm/util.c > > > +++ b/mm/util.c > > > @@ -62,8 +62,14 @@ char *kstrdup(const char *s, gfp_t gfp) > > > > > > len = s

Re: [PATCH v8 1/8] Get rid of __get_task_comm()

Hi Kees, On Wed, Aug 28, 2024 at 05:17:55PM GMT, Kees Cook wrote: > On Wed, Aug 28, 2024 at 05:09:08PM +0200, Alejandro Colomar wrote: > > Hi Kees, > > > > On Wed, Aug 28, 2024 at 06:48:39AM GMT, Kees Cook wrote: > > > > [...] > > > > > >Th

Re: [PATCH v8 1/8] Get rid of __get_task_comm()

ARRAY_SIZE() instead to clarify that they are regular > > characters. > > > >Co-developed-by: Alejandro Colomar > >Signed-off-by: Alejandro Colomar > >Signed-off-by: Yafang Shao > > > >diff --git a/arch/um/include/shared/user.h b/arch/um/inc

Re: [PATCH v8 1/8] Get rid of __get_task_comm()

of wide characters, not the number of bytes. When translating that to normal characters, one wants conceptually the same operation, but on (normal) characters. That is, one wants strscpy(dst, src, ARRAY_SIZE(dst)). While strscpy() with sizeof() works just fine because sizeof(char)==1 by definiti

Re: [PATCH v8 1/8] Get rid of __get_task_comm()

On Wed, Aug 28, 2024 at 12:15:40PM GMT, Alejandro Colomar wrote: > Hi Yafang, > > On Wed, Aug 28, 2024 at 11:03:14AM GMT, Yafang Shao wrote: > > We want to eliminate the use of __get_task_comm() for the following > > reasons: > > > > - The task_lock() is unnec

Re: [PATCH v8 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}

On Wed, Aug 28, 2024 at 12:32:53PM GMT, Alejandro Colomar wrote: > On Wed, Aug 28, 2024 at 11:03:19AM GMT, Yafang Shao wrote: > > These three functions follow the same pattern. To deduplicate the code, > > let's introduce a common helper __kmemdup_nul(). > > >

Re: [PATCH v8 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}

; Cc: Matthew Wilcox > Cc: Alejandro Colomar > --- Reviewed-by: Alejandro Colomar Cheers, Alex > mm/util.c | 68 ++- > 1 file changed, 27 insertions(+), 41 deletions(-) > > diff --git a/mm/util.c b/mm/util.c > index 9a77

Re: [PATCH v8 1/8] Get rid of __get_task_comm()

> https://lore.kernel.org/all/CAHk-=whwtuc-ajmgjveaetkomemfstwkwu99v7+b6ayhmma...@mail.gmail.com/ > Suggested-by: Alejandro Colomar > Link: > https://lore.kernel.org/all/2jxak5v6dfxlpbxhpm3ey7oup4g2lnr3ueurfbosf5wdo65dk4@srb3hsk72zwq > Signed-off-by: Yafang Shao > Cc: Alexander

Re: [PATCH v7 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}

Hi Yafang, On Sat, Aug 17, 2024 at 10:58:02AM GMT, Alejandro Colomar wrote: > Hi Yafang, > > On Sat, Aug 17, 2024 at 10:56:22AM GMT, Yafang Shao wrote: > > These three functions follow the same pattern. To deduplicate the code, > > let's introduce a c

Re: [PATCH v7 4/8] bpftool: Ensure task comm is always NUL-terminated

Hi Yafang, On Sun, Aug 18, 2024 at 10:27:01AM GMT, Yafang Shao wrote: > On Sat, Aug 17, 2024 at 4:39 PM Alejandro Colomar wrote: > > > > Hi Yafang, > > > > On Sat, Aug 17, 2024 at 10:56:20AM GMT, Yafang Shao wrote: > > > Let's explicitly ensure the d

Re: [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup()

Hi Linus, On Sat, Aug 17, 2024 at 09:26:21AM GMT, Linus Torvalds wrote: > On Sat, 17 Aug 2024 at 01:48, Alejandro Colomar wrote: > > > > I would compact the above to: > > > > len = strlen(s); > > buf = kmalloc_track_caller(l

Re: [PATCH v7 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}

On Sat, Aug 17, 2024 at 10:58:02AM GMT, Alejandro Colomar wrote: > Hi Yafang, > > On Sat, Aug 17, 2024 at 10:56:22AM GMT, Yafang Shao wrote: > > These three functions follow the same pattern. To deduplicate the code, > > let's introduce a common helper __kmemdup_nu

Re: [PATCH v7 6/8] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}

Hi Yafang, On Sat, Aug 17, 2024 at 10:56:22AM GMT, Yafang Shao wrote: > These three functions follow the same pattern. To deduplicate the code, > let's introduce a common helper __kmemdup_nul(). > > Suggested-by: Andrew Morton > Signed-off-by: Yafang Shao > Cc: Simon Horman > Cc: Matthew Wilco

Re: [PATCH v7 5/8] mm/util: Fix possible race condition in kstrdup()

Hi Yafang, On Sat, Aug 17, 2024 at 10:56:21AM GMT, Yafang Shao wrote: > In kstrdup(), it is critical to ensure that the dest string is always > NUL-terminated. However, potential race condidtion can occur between a > writer and a reader. > > Consider the following scenario involving task->comm: >

Re: [PATCH v7 4/8] bpftool: Ensure task comm is always NUL-terminated

Hi Yafang, On Sat, Aug 17, 2024 at 10:56:20AM GMT, Yafang Shao wrote: > Let's explicitly ensure the destination string is NUL-terminated. This way, > it won't be affected by changes to the source string. > > Signed-off-by: Yafang Shao > Reviewed-by: Quentin Monnet > --- > tools/bpf/bpftool/pid

Re: [PATCH v6 1/9] Get rid of __get_task_comm()

> https://lore.kernel.org/all/CAHk-=whwtuc-ajmgjveaetkomemfstwkwu99v7+b6ayhmma...@mail.gmail.com/ > Suggested-by: Alejandro Colomar > Link: > https://lore.kernel.org/all/2jxak5v6dfxlpbxhpm3ey7oup4g2lnr3ueurfbosf5wdo65dk4@srb3hsk72zwq > Signed-off-by: Yafang Shao > Cc: Alexander

Re: [PATCH v5 0/9] Improve the copy of task comm

Hi Yafang, On Thu, Aug 08, 2024 at 10:49:17AM GMT, Yafang Shao wrote: > > > Now, it might be a good idea to also verify that 'buf' is an actual > > > array, and that this code doesn't do some silly "sizeof(ptr)" thing. > > > > I decided to use NITEMS() instead of sizeof() for that reason. > > (NIT

Re: [PATCH v5 0/9] Improve the copy of task comm

Hi Linus, Serge let me know about this thread earlier today. On 2024-08-05, Linus Torvalds wrote: > On Mon, 5 Aug 2024 at 20:01, Yafang Shao wrote: > > > > One concern about removing the BUILD_BUG_ON() is that if we extend > > TASK_COMM_LEN to a larger size, such as 24, the caller with a > > ha