| Message ID | ae88f6c2c613d17bc1a56692cfa4f960dbc723d2.1618780558.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | workqueue: Have 'alloc_workqueue()' like macros accept a format specifier | expand |
On 4/18/21 2:26 PM, Christophe JAILLET wrote: > Improve 'create_workqueue', 'create_freezable_workqueue' and > 'create_singlethread_workqueue' so that they accept a format > specifier and a variable number of arguments. > > This will put these macros more in line with 'alloc_ordered_workqueue' and > the underlying 'alloc_workqueue()' function. > > This will also allow further code simplification. Please Cc Tejun for workqueue changes since he maintains the workqueue code. > diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h > index d15a7730ee18..145e756ff315 100644 > --- a/include/linux/workqueue.h > +++ b/include/linux/workqueue.h > @@ -425,13 +425,13 @@ struct workqueue_struct *alloc_workqueue(const char *fmt, > alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | \ > __WQ_ORDERED_EXPLICIT | (flags), 1, ##args) > > -#define create_workqueue(name) \ > - alloc_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, 1, (name)) > -#define create_freezable_workqueue(name) \ > - alloc_workqueue("%s", __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ > - WQ_MEM_RECLAIM, 1, (name)) > -#define create_singlethread_workqueue(name) \ > - alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name) > +#define create_workqueue(fmt, args...) \ > + alloc_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, 1, ##args) > +#define create_freezable_workqueue(fmt, args...) \ > + alloc_workqueue(fmt, __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ > + WQ_MEM_RECLAIM, 1, ##args) > +#define create_singlethread_workqueue(fmt, args...) \ > + alloc_ordered_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, ##args) > > extern void destroy_workqueue(struct workqueue_struct *wq); > >
> Message du 19/04/21 01:03 > De : "Bart Van Assche" > A : "Christophe JAILLET" , tj@kernel.org, jiangshanlai@gmail.com, saeedm@nvidia.com, leon@kernel.org, davem@davemloft.net, kuba@kernel.org, "Tejun Heo" > Copie à : netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org > Objet : Re: [PATCH 1/2] workqueue: Have 'alloc_workqueue()' like macros accept a format specifier > > On 4/18/21 2:26 PM, Christophe JAILLET wrote: > > Improve 'create_workqueue', 'create_freezable_workqueue' and > > 'create_singlethread_workqueue' so that they accept a format > > specifier and a variable number of arguments. > > > > This will put these macros more in line with 'alloc_ordered_workqueue' and > > the underlying 'alloc_workqueue()' function. > > > > This will also allow further code simplification. > > Please Cc Tejun for workqueue changes since he maintains the workqueue code. > Hi, The list in To: is the one given by get_maintainer.pl. Usualy, I only put the ML in Cc: I've run the script on the 2 patches of the serie and merged the 2 lists. Everyone is in the To: of the cover letter and of the 2 patches. If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in the To: line. CJ > > diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h > > index d15a7730ee18..145e756ff315 100644 > > --- a/include/linux/workqueue.h > > +++ b/include/linux/workqueue.h > > @@ -425,13 +425,13 @@ struct workqueue_struct *alloc_workqueue(const char *fmt, > > alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | \ > > __WQ_ORDERED_EXPLICIT | (flags), 1, ##args) > > > > -#define create_workqueue(name) \ > > - alloc_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, 1, (name)) > > -#define create_freezable_workqueue(name) \ > > - alloc_workqueue("%s", __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ > > - WQ_MEM_RECLAIM, 1, (name)) > > -#define create_singlethread_workqueue(name) \ > > - alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name) > > +#define create_workqueue(fmt, args...) \ > > + alloc_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, 1, ##args) > > +#define create_freezable_workqueue(fmt, args...) \ > > + alloc_workqueue(fmt, __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ > > + WQ_MEM_RECLAIM, 1, ##args) > > +#define create_singlethread_workqueue(fmt, args...) \ > > + alloc_ordered_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, ##args) > > > > extern void destroy_workqueue(struct workqueue_struct *wq); > > > > > >
On 18/04/2021 23.26, Christophe JAILLET wrote: > Improve 'create_workqueue', 'create_freezable_workqueue' and > 'create_singlethread_workqueue' so that they accept a format > specifier and a variable number of arguments. > > This will put these macros more in line with 'alloc_ordered_workqueue' and > the underlying 'alloc_workqueue()' function. > > This will also allow further code simplification. > > Suggested-by: Bart Van Assche <bvanassche@acm.org> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> > --- > include/linux/workqueue.h | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h > index d15a7730ee18..145e756ff315 100644 > --- a/include/linux/workqueue.h > +++ b/include/linux/workqueue.h > @@ -425,13 +425,13 @@ struct workqueue_struct *alloc_workqueue(const char *fmt, > alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | \ > __WQ_ORDERED_EXPLICIT | (flags), 1, ##args) > > -#define create_workqueue(name) \ > - alloc_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, 1, (name)) > +#define create_workqueue(fmt, args...) \ > + alloc_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, 1, ##args) The changes make sense, but are you sure that no current users of those macros have some % character in the string they pass? If all users pass string literals the compiler/0day bot should catch those, but as the very example you give in 2/2 shows, not everybody passes string literals. Maybe git grep would quickly tell that there's only 8 callers and they are all audited quickly or something like that; in that case please include a note to that effect in the commit log. Rasmus
On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: > The list in To: is the one given by get_maintainer.pl. Usualy, I only > put the ML in Cc: I've run the script on the 2 patches of the serie > and merged the 2 lists. Everyone is in the To: of the cover letter > and of the 2 patches. > > If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in > the To: line. Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives from a maintainer and that modify another subsystem than the subsystem maintained by that maintainer. Thanks, Bart.
On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: > On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: > > The list in To: is the one given by get_maintainer.pl. Usualy, I only > > put the ML in Cc: I've run the script on the 2 patches of the serie > > and merged the 2 lists. Everyone is in the To: of the cover letter > > and of the 2 patches. > > > > If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in > > the To: line. > Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives > from a maintainer and that modify another subsystem than the subsystem > maintained by that maintainer. Really? Do you remember a lore link for this? Generally I've been junking the CC lines (vs Andrew at the other extreme that often has 10's of CC lines) Jason
On 4/22/21 5:24 AM, Jason Gunthorpe wrote: > On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: >> On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: >>> The list in To: is the one given by get_maintainer.pl. Usualy, I only >>> put the ML in Cc: I've run the script on the 2 patches of the serie >>> and merged the 2 lists. Everyone is in the To: of the cover letter >>> and of the 2 patches. >>> >>> If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in >>> the To: line. >> Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives >> from a maintainer and that modify another subsystem than the subsystem >> maintained by that maintainer. > > Really? Do you remember a lore link for this? Last time I saw Linus mentioning this was a few months ago. Unfortunately I cannot find that message anymore. > Generally I've been junking the CC lines (vs Andrew at the other > extreme that often has 10's of CC lines) Most entries in the MAINTAINERS file have one to three email addresses so I'm surprised to read that Cc-ing maintainer(s) could result in tens of Cc lines? Thanks, Bart.
On Thu, Apr 22, 2021 at 10:12:33AM -0700, Bart Van Assche wrote: > On 4/22/21 5:24 AM, Jason Gunthorpe wrote: > > On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: > >> On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: > >>> The list in To: is the one given by get_maintainer.pl. Usualy, I only > >>> put the ML in Cc: I've run the script on the 2 patches of the serie > >>> and merged the 2 lists. Everyone is in the To: of the cover letter > >>> and of the 2 patches. > >>> > >>> If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in > >>> the To: line. > >> Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives > >> from a maintainer and that modify another subsystem than the subsystem > >> maintained by that maintainer. > > > > Really? Do you remember a lore link for this? > > Last time I saw Linus mentioning this was a few months ago. > Unfortunately I cannot find that message anymore. > > > Generally I've been junking the CC lines (vs Andrew at the other > > extreme that often has 10's of CC lines) > > Most entries in the MAINTAINERS file have one to three email addresses > so I'm surprised to read that Cc-ing maintainer(s) could result in tens > of Cc lines? git log mm/ commit 2b8305260fb37fc20e13f71e13073304d0a031c8 Author: Alexander Potapenko <glider@google.com> Date: Thu Feb 25 17:19:21 2021 -0800 kfence, kasan: make KFENCE compatible with KASAN Make KFENCE compatible with KASAN. Currently this helps test KFENCE itself, where KASAN can catch potential corruptions to KFENCE state, or other corruptions that may be a result of freepointer corruptions in the main allocators. [akpm@linux-foundation.org: merge fixup] [andreyknvl@google.com: untag addresses for KFENCE] Link: https://lkml.kernel.org/r/9dc196006921b191d25d10f6e611316db7da2efc.1611946152.git.andreyknvl@google.com Link: https://lkml.kernel.org/r/20201103175841.3495947-7-elver@google.com Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Alexander Potapenko <glider@google.com> Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Jann Horn <jannh@google.com> Co-developed-by: Marco Elver <elver@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Rientjes <rientjes@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Hillf Danton <hdanton@sina.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joern Engel <joern@purestorage.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Kees Cook <keescook@chromium.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Pekka Enberg <penberg@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: SeongJae Park <sjpark@amazon.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> > > Thanks, > > Bart.
On 4/22/21 11:00 AM, Leon Romanovsky wrote: > On Thu, Apr 22, 2021 at 10:12:33AM -0700, Bart Van Assche wrote: >> On 4/22/21 5:24 AM, Jason Gunthorpe wrote: >>> On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: >>>> On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: >>>>> The list in To: is the one given by get_maintainer.pl. Usualy, I only >>>>> put the ML in Cc: I've run the script on the 2 patches of the serie >>>>> and merged the 2 lists. Everyone is in the To: of the cover letter >>>>> and of the 2 patches. >>>>> >>>>> If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in >>>>> the To: line. >>>> Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives >>>> from a maintainer and that modify another subsystem than the subsystem >>>> maintained by that maintainer. >>> >>> Really? Do you remember a lore link for this? >> >> Last time I saw Linus mentioning this was a few months ago. >> Unfortunately I cannot find that message anymore. >> >>> Generally I've been junking the CC lines (vs Andrew at the other >>> extreme that often has 10's of CC lines) >> >> Most entries in the MAINTAINERS file have one to three email addresses >> so I'm surprised to read that Cc-ing maintainer(s) could result in tens >> of Cc lines? > > git log mm/ > > commit 2b8305260fb37fc20e13f71e13073304d0a031c8 > Author: Alexander Potapenko <glider@google.com> > Date: Thu Feb 25 17:19:21 2021 -0800 > > kfence, kasan: make KFENCE compatible with KASAN > > Make KFENCE compatible with KASAN. Currently this helps test KFENCE > itself, where KASAN can catch potential corruptions to KFENCE state, or > other corruptions that may be a result of freepointer corruptions in the > main allocators. > > [akpm@linux-foundation.org: merge fixup] > [andreyknvl@google.com: untag addresses for KFENCE] > Link: https://lkml.kernel.org/r/9dc196006921b191d25d10f6e611316db7da2efc.1611946152.git.andreyknvl@google.com > > Link: https://lkml.kernel.org/r/20201103175841.3495947-7-elver@google.com > Signed-off-by: Marco Elver <elver@google.com> > Signed-off-by: Alexander Potapenko <glider@google.com> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > Reviewed-by: Jann Horn <jannh@google.com> > Co-developed-by: Marco Elver <elver@google.com> > Cc: Andrey Konovalov <andreyknvl@google.com> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> > Cc: Andy Lutomirski <luto@kernel.org> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Christopher Lameter <cl@linux.com> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: David Rientjes <rientjes@google.com> > Cc: Eric Dumazet <edumazet@google.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Hillf Danton <hdanton@sina.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Joern Engel <joern@purestorage.com> > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> > Cc: Kees Cook <keescook@chromium.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Paul E. McKenney <paulmck@kernel.org> > Cc: Pekka Enberg <penberg@kernel.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: SeongJae Park <sjpark@amazon.de> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Will Deacon <will@kernel.org> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> But where does that Cc-list come from? If I extract that patch and run the get_maintainer.pl script, the following output appears: $ git format-patch -1 2b8305260fb37fc20e13f71e13073304d0a031c8 0001-kfence-kasan-make-KFENCE-compatible-with-KASAN.patch $ scripts/get_maintainer.pl 0001-kfence-kasan-make-KFENCE-compatible-with-KASAN.patch Alexander Potapenko <glider@google.com> (maintainer:KFENCE) Marco Elver <elver@google.com> (maintainer:KFENCE) Dmitry Vyukov <dvyukov@google.com> (reviewer:KFENCE) Andrey Ryabinin <ryabinin.a.a@gmail.com> (maintainer:KASAN) Andrey Konovalov <andreyknvl@gmail.com> (reviewer:KASAN) Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY MANAGEMENT) kasan-dev@googlegroups.com (open list:KFENCE) linux-kernel@vger.kernel.org (open list) linux-mm@kvack.org (open list:MEMORY MANAGEMENT) Additionally, please note that in my email I was referring to the MAINTAINERS file. I do not use the get_maintainers.pl script but instead select the Cc-list manually based on what I find in the MAINTAINERS file. Thanks, Bart.
On Thu, Apr 22, 2021 at 01:30PM -0700, Bart Van Assche wrote: > On 4/22/21 11:00 AM, Leon Romanovsky wrote: > > On Thu, Apr 22, 2021 at 10:12:33AM -0700, Bart Van Assche wrote: > > > On 4/22/21 5:24 AM, Jason Gunthorpe wrote: > > > > On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: > > > > > On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: > > > > > > The list in To: is the one given by get_maintainer.pl. Usualy, I only > > > > > > put the ML in Cc: I've run the script on the 2 patches of the serie > > > > > > and merged the 2 lists. Everyone is in the To: of the cover letter > > > > > > and of the 2 patches. > > > > > > > > > > > > If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in > > > > > > the To: line. > > > > > Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives > > > > > from a maintainer and that modify another subsystem than the subsystem > > > > > maintained by that maintainer. > > > > > > > > Really? Do you remember a lore link for this? > > > > > > Last time I saw Linus mentioning this was a few months ago. > > > Unfortunately I cannot find that message anymore. > > > > > > > Generally I've been junking the CC lines (vs Andrew at the other > > > > extreme that often has 10's of CC lines) > > > > > > Most entries in the MAINTAINERS file have one to three email addresses > > > so I'm surprised to read that Cc-ing maintainer(s) could result in tens > > > of Cc lines? > > > > git log mm/ > > > > commit 2b8305260fb37fc20e13f71e13073304d0a031c8 > > Author: Alexander Potapenko <glider@google.com> > > Date: Thu Feb 25 17:19:21 2021 -0800 > > > > kfence, kasan: make KFENCE compatible with KASAN > > > > Make KFENCE compatible with KASAN. Currently this helps test KFENCE > > itself, where KASAN can catch potential corruptions to KFENCE state, or > > other corruptions that may be a result of freepointer corruptions in the > > main allocators. > > > > [akpm@linux-foundation.org: merge fixup] > > [andreyknvl@google.com: untag addresses for KFENCE] > > Link: https://lkml.kernel.org/r/9dc196006921b191d25d10f6e611316db7da2efc.1611946152.git.andreyknvl@google.com > > > > Link: https://lkml.kernel.org/r/20201103175841.3495947-7-elver@google.com > > Signed-off-by: Marco Elver <elver@google.com> > > Signed-off-by: Alexander Potapenko <glider@google.com> > > Signed-off-by: Andrey Konovalov <andreyknvl@google.com> > > Reviewed-by: Dmitry Vyukov <dvyukov@google.com> > > Reviewed-by: Jann Horn <jannh@google.com> > > Co-developed-by: Marco Elver <elver@google.com> > > Cc: Andrey Konovalov <andreyknvl@google.com> > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> > > Cc: Andy Lutomirski <luto@kernel.org> > > Cc: Borislav Petkov <bp@alien8.de> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > Cc: Christopher Lameter <cl@linux.com> > > Cc: Dave Hansen <dave.hansen@linux.intel.com> > > Cc: David Rientjes <rientjes@google.com> > > Cc: Eric Dumazet <edumazet@google.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Hillf Danton <hdanton@sina.com> > > Cc: "H. Peter Anvin" <hpa@zytor.com> > > Cc: Ingo Molnar <mingo@redhat.com> > > Cc: Joern Engel <joern@purestorage.com> > > Cc: Jonathan Corbet <corbet@lwn.net> > > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > Cc: Kees Cook <keescook@chromium.org> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Paul E. McKenney <paulmck@kernel.org> > > Cc: Pekka Enberg <penberg@kernel.org> > > Cc: Peter Zijlstra <peterz@infradead.org> > > Cc: SeongJae Park <sjpark@amazon.de> > > Cc: Thomas Gleixner <tglx@linutronix.de> > > Cc: Vlastimil Babka <vbabka@suse.cz> > > Cc: Will Deacon <will@kernel.org> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> This is a special case probably as KFENCE touched various subsystems and architectures. That Cc list is from the original https://lkml.kernel.org/r/20201103175841.3495947-7-elver@google.com It was determined based on the full series, mostly from a get_maintainer.pl of 'reviewer' and 'maintainer' lists of the full series diff, minus a some false positives to avoid spamming people, and plus a few people get_maintainer.pl missed that had provided or could provide useful input. So the list above is mostly maintainers+reviewers of mm/, mm/kasan, arch/x86, and arch/arm64. > But where does that Cc-list come from? If I extract that patch and run the > get_maintainer.pl script, the following output appears: > > $ git format-patch -1 2b8305260fb37fc20e13f71e13073304d0a031c8 > 0001-kfence-kasan-make-KFENCE-compatible-with-KASAN.patch > $ scripts/get_maintainer.pl > 0001-kfence-kasan-make-KFENCE-compatible-with-KASAN.patch > Alexander Potapenko <glider@google.com> (maintainer:KFENCE) > Marco Elver <elver@google.com> (maintainer:KFENCE) KFENCE did not yet exist when the patch the above series was part of was posted... so chicken and egg situation here. ;-) > Dmitry Vyukov <dvyukov@google.com> (reviewer:KFENCE) > Andrey Ryabinin <ryabinin.a.a@gmail.com> (maintainer:KASAN) > Andrey Konovalov <andreyknvl@gmail.com> (reviewer:KASAN) > Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY MANAGEMENT) > kasan-dev@googlegroups.com (open list:KFENCE) > linux-kernel@vger.kernel.org (open list) > linux-mm@kvack.org (open list:MEMORY MANAGEMENT) Thanks, -- Marco
On Thu, Apr 22, 2021 at 01:30:00PM -0700, Bart Van Assche wrote: > But where does that Cc-list come from? If I extract that patch and run the > get_maintainer.pl script, the following output appears: Andrew takes it from the email CC list in the original email that the patch came from Jason
On Thu, Apr 22, 2021 at 09:24:19AM -0300, Jason Gunthorpe wrote: > On Mon, Apr 19, 2021 at 01:02:34PM -0700, Bart Van Assche wrote: > > On 4/18/21 11:36 PM, Marion et Christophe JAILLET wrote: > > > The list in To: is the one given by get_maintainer.pl. Usualy, I only > > > put the ML in Cc: I've run the script on the 2 patches of the serie > > > and merged the 2 lists. Everyone is in the To: of the cover letter > > > and of the 2 patches. > > > > > > If Théo is "Tejun Heo" ( (maintainer:WORKQUEUE) ), he is already in > > > the To: line. > > Linus wants to see a "Cc: ${maintainer}" tag in patches that he receives > > from a maintainer and that modify another subsystem than the subsystem > > maintained by that maintainer. > > Really? Do you remember a lore link for this? > > Generally I've been junking the CC lines (vs Andrew at the other > extreme that often has 10's of CC lines) Of course this patch has already been NAKed but it wasn't clear to me whose git tree it would have gone through. Surely if it were going through your tree you would have required an Acked-by: from Tejun and the CC: line would not be required. It would only be required if you can't get a maintainer to respond. regards, dan carpenter
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index d15a7730ee18..145e756ff315 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -425,13 +425,13 @@ struct workqueue_struct *alloc_workqueue(const char *fmt, alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED | \ __WQ_ORDERED_EXPLICIT | (flags), 1, ##args) -#define create_workqueue(name) \ - alloc_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, 1, (name)) -#define create_freezable_workqueue(name) \ - alloc_workqueue("%s", __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ - WQ_MEM_RECLAIM, 1, (name)) -#define create_singlethread_workqueue(name) \ - alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name) +#define create_workqueue(fmt, args...) \ + alloc_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, 1, ##args) +#define create_freezable_workqueue(fmt, args...) \ + alloc_workqueue(fmt, __WQ_LEGACY | WQ_FREEZABLE | WQ_UNBOUND | \ + WQ_MEM_RECLAIM, 1, ##args) +#define create_singlethread_workqueue(fmt, args...) \ + alloc_ordered_workqueue(fmt, __WQ_LEGACY | WQ_MEM_RECLAIM, ##args) extern void destroy_workqueue(struct workqueue_struct *wq);
Improve 'create_workqueue', 'create_freezable_workqueue' and 'create_singlethread_workqueue' so that they accept a format specifier and a variable number of arguments. This will put these macros more in line with 'alloc_ordered_workqueue' and the underlying 'alloc_workqueue()' function. This will also allow further code simplification. Suggested-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> --- include/linux/workqueue.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)