* [PATCH] mm: util: update the kerneldoc for kstrdup_const() @ 2020-06-28 15:25 Bartosz Golaszewski 2020-06-28 17:37 ` Joe Perches 0 siblings, 1 reply; 10+ messages in thread From: Bartosz Golaszewski @ 2020-06-28 15:25 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-mm, linux-kernel, Bartosz Golaszewski From: Bartosz Golaszewski <bgolaszewski@baylibre.com> Memory allocated with kstrdup_const() must not be passed to regular krealloc() as it is not aware of the possibility of the chunk residing in .rodata. Since there are no potential users of krealloc_const() at the moment, let's just update the doc to make it explicit. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> --- mm/util.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/util.c b/mm/util.c index c63c8e47be57..27d6155edb8f 100644 --- a/mm/util.c +++ b/mm/util.c @@ -69,7 +69,8 @@ EXPORT_SYMBOL(kstrdup); * @s: the string to duplicate * @gfp: the GFP mask used in the kmalloc() call when allocating memory * - * Note: Strings allocated by kstrdup_const should be freed by kfree_const. + * Note: Strings allocated by kstrdup_const should be freed by kfree_const and + * must not be passed to krealloc(). * * Return: source string if it is in .rodata section otherwise * fallback to kstrdup. -- 2.26.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-28 15:25 [PATCH] mm: util: update the kerneldoc for kstrdup_const() Bartosz Golaszewski @ 2020-06-28 17:37 ` Joe Perches 2020-06-28 18:06 ` Bartosz Golaszewski 2020-06-29 10:54 ` David Hildenbrand 0 siblings, 2 replies; 10+ messages in thread From: Joe Perches @ 2020-06-28 17:37 UTC (permalink / raw) To: Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > Memory allocated with kstrdup_const() must not be passed to regular > krealloc() as it is not aware of the possibility of the chunk residing > in .rodata. Since there are no potential users of krealloc_const() > at the moment, let's just update the doc to make it explicit. Another option would be to return NULL if it's used from krealloc with a pointer into rodata --- mm/slab_common.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/mm/slab_common.c b/mm/slab_common.c index 37d48a56431d..f8b49656171b 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, * @new_size: how many bytes of memory are required. * @flags: the type of memory to allocate. * + * If the object pointed to is in rodata (likely from kstrdup_const) + * %NULL is returned. + * * The contents of the object pointed to are preserved up to the * lesser of the new and old sizes. If @p is %NULL, krealloc() * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) { void *ret; + if (unlikely(is_kernel_rodata((unsigned long)p))) + return NULL; + if (unlikely(!new_size)) { kfree(p); return ZERO_SIZE_PTR; ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-28 17:37 ` Joe Perches @ 2020-06-28 18:06 ` Bartosz Golaszewski 2020-06-28 18:20 ` Joe Perches 2020-06-29 10:54 ` David Hildenbrand 1 sibling, 1 reply; 10+ messages in thread From: Bartosz Golaszewski @ 2020-06-28 18:06 UTC (permalink / raw) To: Joe Perches Cc: Andrew Morton, linux-mm, Linux Kernel Mailing List, Bartosz Golaszewski On Sun, Jun 28, 2020 at 7:37 PM Joe Perches <joe@perches.com> wrote: > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > Memory allocated with kstrdup_const() must not be passed to regular > > krealloc() as it is not aware of the possibility of the chunk residing > > in .rodata. Since there are no potential users of krealloc_const() > > at the moment, let's just update the doc to make it explicit. > > Another option would be to return NULL if it's > used from krealloc with a pointer into rodata > --- > mm/slab_common.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 37d48a56431d..f8b49656171b 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > * @new_size: how many bytes of memory are required. > * @flags: the type of memory to allocate. > * > + * If the object pointed to is in rodata (likely from kstrdup_const) > + * %NULL is returned. > + * > * The contents of the object pointed to are preserved up to the > * lesser of the new and old sizes. If @p is %NULL, krealloc() > * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a > @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) > { > void *ret; > > + if (unlikely(is_kernel_rodata((unsigned long)p))) > + return NULL; > + > if (unlikely(!new_size)) { > kfree(p); > return ZERO_SIZE_PTR; > > > In that case we should probably add a WARN_ON() - otherwise the user will be baffled by krealloc() failing. Bartosz ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-28 18:06 ` Bartosz Golaszewski @ 2020-06-28 18:20 ` Joe Perches 0 siblings, 0 replies; 10+ messages in thread From: Joe Perches @ 2020-06-28 18:20 UTC (permalink / raw) To: Bartosz Golaszewski Cc: Andrew Morton, linux-mm, Linux Kernel Mailing List, Bartosz Golaszewski On Sun, 2020-06-28 at 20:06 +0200, Bartosz Golaszewski wrote: > On Sun, Jun 28, 2020 at 7:37 PM Joe Perches <joe@perches.com> wrote: > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > krealloc() as it is not aware of the possibility of the chunk residing > > > in .rodata. Since there are no potential users of krealloc_const() > > > at the moment, let's just update the doc to make it explicit. > > > > Another option would be to return NULL if it's > > used from krealloc with a pointer into rodata > > --- > > mm/slab_common.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index 37d48a56431d..f8b49656171b 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > > * @new_size: how many bytes of memory are required. > > * @flags: the type of memory to allocate. > > * > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > + * %NULL is returned. > > + * > > * The contents of the object pointed to are preserved up to the > > * lesser of the new and old sizes. If @p is %NULL, krealloc() > > * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a > > @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) > > { > > void *ret; > > > > + if (unlikely(is_kernel_rodata((unsigned long)p))) > > + return NULL; > > + > > if (unlikely(!new_size)) { > > kfree(p); > > return ZERO_SIZE_PTR; > > > > > > > > In that case we should probably add a WARN_ON() - otherwise the user > will be baffled by krealloc() failing. Maybe: --- mm/slab_common.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/mm/slab_common.c b/mm/slab_common.c index a143a8c8f874..06c2714ab8c9 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1073,6 +1073,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, * @new_size: how many bytes of memory are required. * @flags: the type of memory to allocate. * + * If the object pointed to is in rodata (likely from kstrdup_const) + * %NULL is returned. + * * The contents of the object pointed to are preserved up to the * lesser of the new and old sizes. If @p is %NULL, krealloc() * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a @@ -1084,6 +1087,14 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) { void *ret; + if (unlikely(is_kernel_rodata((unsigned long)p))) { + if (!(flags & __GFP_NOWARN)) { + printk(KERN_DEFAULT "invalid use of krealloc with const rodata\n"); + dump_stack(); + } + return NULL; + } + if (unlikely(!new_size)) { kfree(p); return ZERO_SIZE_PTR; ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-28 17:37 ` Joe Perches 2020-06-28 18:06 ` Bartosz Golaszewski @ 2020-06-29 10:54 ` David Hildenbrand 2020-06-29 19:21 ` Joe Perches 1 sibling, 1 reply; 10+ messages in thread From: David Hildenbrand @ 2020-06-29 10:54 UTC (permalink / raw) To: Joe Perches, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On 28.06.20 19:37, Joe Perches wrote: > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >> >> Memory allocated with kstrdup_const() must not be passed to regular >> krealloc() as it is not aware of the possibility of the chunk residing >> in .rodata. Since there are no potential users of krealloc_const() >> at the moment, let's just update the doc to make it explicit. > > Another option would be to return NULL if it's > used from krealloc with a pointer into rodata > --- > mm/slab_common.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/mm/slab_common.c b/mm/slab_common.c > index 37d48a56431d..f8b49656171b 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > * @new_size: how many bytes of memory are required. > * @flags: the type of memory to allocate. > * > + * If the object pointed to is in rodata (likely from kstrdup_const) > + * %NULL is returned. > + * > * The contents of the object pointed to are preserved up to the > * lesser of the new and old sizes. If @p is %NULL, krealloc() > * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a > @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t flags) > { > void *ret; > > + if (unlikely(is_kernel_rodata((unsigned long)p))) > + return NULL; > + > if (unlikely(!new_size)) { > kfree(p); > return ZERO_SIZE_PTR; > Won't we have similar issues if somebody would do a kfree() instead of a kfree_const()? So I think the original patch makes sense. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-29 10:54 ` David Hildenbrand @ 2020-06-29 19:21 ` Joe Perches 2020-06-30 8:57 ` David Hildenbrand 0 siblings, 1 reply; 10+ messages in thread From: Joe Perches @ 2020-06-29 19:21 UTC (permalink / raw) To: David Hildenbrand, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > On 28.06.20 19:37, Joe Perches wrote: > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > krealloc() as it is not aware of the possibility of the chunk residing > > > in .rodata. Since there are no potential users of krealloc_const() > > > at the moment, let's just update the doc to make it explicit. > > > > Another option would be to return NULL if it's > > used from krealloc with a pointer into rodata [] > > diff --git a/mm/slab_common.c b/mm/slab_common.c [] > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > > * @new_size: how many bytes of memory are required. > > * @flags: the type of memory to allocate. > > * > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > + * %NULL is returned. > > + * [] > Won't we have similar issues if somebody would do a kfree() instead of a > kfree_const()? So I think the original patch makes sense. Which is why I also suggested making kfree work for more types of memory freeing earlier this month. https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-29 19:21 ` Joe Perches @ 2020-06-30 8:57 ` David Hildenbrand 2020-06-30 14:14 ` Joe Perches 0 siblings, 1 reply; 10+ messages in thread From: David Hildenbrand @ 2020-06-30 8:57 UTC (permalink / raw) To: Joe Perches, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On 29.06.20 21:21, Joe Perches wrote: > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: >> On 28.06.20 19:37, Joe Perches wrote: >>> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: >>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>> >>>> Memory allocated with kstrdup_const() must not be passed to regular >>>> krealloc() as it is not aware of the possibility of the chunk residing >>>> in .rodata. Since there are no potential users of krealloc_const() >>>> at the moment, let's just update the doc to make it explicit. >>> >>> Another option would be to return NULL if it's >>> used from krealloc with a pointer into rodata > [] >>> diff --git a/mm/slab_common.c b/mm/slab_common.c > [] >>> @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, >>> * @new_size: how many bytes of memory are required. >>> * @flags: the type of memory to allocate. >>> * >>> + * If the object pointed to is in rodata (likely from kstrdup_const) >>> + * %NULL is returned. >>> + * > [] >> Won't we have similar issues if somebody would do a kfree() instead of a >> kfree_const()? So I think the original patch makes sense. > > Which is why I also suggested making kfree work for > more types of memory freeing earlier this month. > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ I'm curious, do we see a lot of BUGs that resulted from wrong usage such that we need runtime checks for such things that the code can just statically specify (If I use kstrdup_const() for allocation I can just use kfree_const() for freeing - no runtime checks needed). IOW, what's the real benefit that is worth spending extra runtime cycles? -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-30 8:57 ` David Hildenbrand @ 2020-06-30 14:14 ` Joe Perches 2020-06-30 14:36 ` David Hildenbrand 0 siblings, 1 reply; 10+ messages in thread From: Joe Perches @ 2020-06-30 14:14 UTC (permalink / raw) To: David Hildenbrand, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: > On 29.06.20 21:21, Joe Perches wrote: > > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > > > On 28.06.20 19:37, Joe Perches wrote: > > > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > > > krealloc() as it is not aware of the possibility of the chunk residing > > > > > in .rodata. Since there are no potential users of krealloc_const() > > > > > at the moment, let's just update the doc to make it explicit. > > > > > > > > Another option would be to return NULL if it's > > > > used from krealloc with a pointer into rodata > > [] > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > [] > > > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > > > > * @new_size: how many bytes of memory are required. > > > > * @flags: the type of memory to allocate. > > > > * > > > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > > > + * %NULL is returned. > > > > + * > > [] > > > Won't we have similar issues if somebody would do a kfree() instead of a > > > kfree_const()? So I think the original patch makes sense. > > > > Which is why I also suggested making kfree work for > > more types of memory freeing earlier this month. > > > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ [] > what's the real benefit that is worth spending extra runtime cycles? I very much doubt there is an actual instance where the runtime cycles matter. Where could there be a fast-path instance of free? ANd kvfree consolidation and coding simplicity make it somewhat useful. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-30 14:14 ` Joe Perches @ 2020-06-30 14:36 ` David Hildenbrand 2020-06-30 14:51 ` Joe Perches 0 siblings, 1 reply; 10+ messages in thread From: David Hildenbrand @ 2020-06-30 14:36 UTC (permalink / raw) To: Joe Perches, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On 30.06.20 16:14, Joe Perches wrote: > On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: >> On 29.06.20 21:21, Joe Perches wrote: >>> On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: >>>> On 28.06.20 19:37, Joe Perches wrote: >>>>> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: >>>>>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com> >>>>>> >>>>>> Memory allocated with kstrdup_const() must not be passed to regular >>>>>> krealloc() as it is not aware of the possibility of the chunk residing >>>>>> in .rodata. Since there are no potential users of krealloc_const() >>>>>> at the moment, let's just update the doc to make it explicit. >>>>> >>>>> Another option would be to return NULL if it's >>>>> used from krealloc with a pointer into rodata >>> [] >>>>> diff --git a/mm/slab_common.c b/mm/slab_common.c >>> [] >>>>> @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, >>>>> * @new_size: how many bytes of memory are required. >>>>> * @flags: the type of memory to allocate. >>>>> * >>>>> + * If the object pointed to is in rodata (likely from kstrdup_const) >>>>> + * %NULL is returned. >>>>> + * >>> [] >>>> Won't we have similar issues if somebody would do a kfree() instead of a >>>> kfree_const()? So I think the original patch makes sense. >>> >>> Which is why I also suggested making kfree work for >>> more types of memory freeing earlier this month. >>> >>> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > [] >> what's the real benefit that is worth spending extra runtime cycles? > > I very much doubt there is an actual instance > where the runtime cycles matter. Where could > there be a fast-path instance of free? Well, looking at kfree() I can directly spot "unlikely()", which sounds like somebody cares about branch prediction in the slab. Once you have cases that can happen equally likely it most certainly degrades performance. The question is if we care. Coming back to my question, so the major benefit you see is coding simplicity, correct? -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const() 2020-06-30 14:36 ` David Hildenbrand @ 2020-06-30 14:51 ` Joe Perches 0 siblings, 0 replies; 10+ messages in thread From: Joe Perches @ 2020-06-30 14:51 UTC (permalink / raw) To: David Hildenbrand, Bartosz Golaszewski, Andrew Morton Cc: linux-mm, linux-kernel, Bartosz Golaszewski On Tue, 2020-06-30 at 16:36 +0200, David Hildenbrand wrote: > On 30.06.20 16:14, Joe Perches wrote: > > On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: > > > On 29.06.20 21:21, Joe Perches wrote: > > > > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > > > > > On 28.06.20 19:37, Joe Perches wrote: > > > > > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > > > > > > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > > > > > krealloc() as it is not aware of the possibility of the chunk residing > > > > > > > in .rodata. Since there are no potential users of krealloc_const() > > > > > > > at the moment, let's just update the doc to make it explicit. > > > > > > > > > > > > Another option would be to return NULL if it's > > > > > > used from krealloc with a pointer into rodata > > > > [] > > > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > > > [] > > > > > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p, size_t new_size, > > > > > > * @new_size: how many bytes of memory are required. > > > > > > * @flags: the type of memory to allocate. > > > > > > * > > > > > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > > > > > + * %NULL is returned. > > > > > > + * > > > > [] > > > > > Won't we have similar issues if somebody would do a kfree() instead of a > > > > > kfree_const()? So I think the original patch makes sense. > > > > > > > > Which is why I also suggested making kfree work for > > > > more types of memory freeing earlier this month. > > > > > > > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.camel@perches.com/ > > [] > > > what's the real benefit that is worth spending extra runtime cycles? > > > > I very much doubt there is an actual instance > > where the runtime cycles matter. Where could > > there be a fast-path instance of free? > > Well, looking at kfree() I can directly spot "unlikely()", which sounds > like somebody cares about branch prediction in the slab. Or is telling the compiler of a 95%+ likely case. > Once you have cases that can happen equally likely it most certainly > degrades performance. The question is if we care. Right. Does 4 additional tests in what appears to be almost exclusively non-fast paths matter? > Coming back to my question, so the major benefit you see is coding > simplicity, correct? Yes. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-06-30 14:51 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-28 15:25 [PATCH] mm: util: update the kerneldoc for kstrdup_const() Bartosz Golaszewski 2020-06-28 17:37 ` Joe Perches 2020-06-28 18:06 ` Bartosz Golaszewski 2020-06-28 18:20 ` Joe Perches 2020-06-29 10:54 ` David Hildenbrand 2020-06-29 19:21 ` Joe Perches 2020-06-30 8:57 ` David Hildenbrand 2020-06-30 14:14 ` Joe Perches 2020-06-30 14:36 ` David Hildenbrand 2020-06-30 14:51 ` Joe Perches
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).