search for: config_debug_sg

On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: [...] > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > */ > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > +#ifdef CONFIG_DEBUG_SG > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > + if (!(prandom_u32_max(2) & 1)) > + goto do_vmalloc; > +#endif I really do not think there is anything DEBUG_SG specific here. Why you simply do not follow should_failslab path or even reuse the functi...

On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: [...] > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > */ > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > +#ifdef CONFIG_DEBUG_SG > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > + if (!(prandom_u32_max(2) & 1)) > + goto do_vmalloc; > +#endif I really do not think there is anything DEBUG_SG specific here. Why you simply do not follow should_failslab path or even reuse the functi...

...ko wrote: > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > > [...] > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > */ > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > +#ifdef CONFIG_DEBUG_SG > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > + if (!(prandom_u32_max(2) & 1)) > > > + goto do_vmalloc; > > > +#endif > > > > I really do not think there is anything DEBUG_SG specific here. Why you > &...

...ko wrote: > > > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > > [...] > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > */ > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > +#ifdef CONFIG_DEBUG_SG > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > + if (!(prandom_u32_max(2) & 1)) > > > + goto do_vmalloc; > > > +#endif > > > > I really do not think there is anything DEBUG_SG specific here. Why you > &...

...Patocka wrote: > > > > [...] > > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > > > */ > > > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > > > > > +#ifdef CONFIG_DEBUG_SG > > > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > > > + if (!(prandom_u32_max(2) & 1)) > > > > > + goto do_vmalloc; > > > > > +#endif > > > > > > > > I really do not th...

...Patocka wrote: > > > > [...] > > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > > > */ > > > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > > > > > +#ifdef CONFIG_DEBUG_SG > > > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > > > + if (!(prandom_u32_max(2) & 1)) > > > > > + goto do_vmalloc; > > > > > +#endif > > > > > > > > I really do not th...

...he virtio-net driver, dm-integrity or RHEL7 powerpc-specific code. These bugs are hard to reproduce because kvmalloc falls back to vmalloc only if memory is fragmented. In order to detect these bugs reliably I submit this patch that changes kvmalloc to fall back to vmalloc with 1/2 probability if CONFIG_DEBUG_SG is turned on. CONFIG_DEBUG_SG is used, because it makes the DMA API layer verify the addresses passed to it, and so the user will get a reliable stacktrace. Some bugs (such as buffer overflows) are better detected with kmalloc code, so we must test the kmalloc path too. Signed-off-by: Mikulas Pat...

On Tue, 24 Apr 2018, Michal Hocko wrote: > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote: > [...] > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > */ > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > +#ifdef CONFIG_DEBUG_SG > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > + if (!(prandom_u32_max(2) & 1)) > > + goto do_vmalloc; > > +#endif > > I really do not think there is anything DEBUG_SG specific here. Why you > simply do not follow should_fai...

...on 23-04-18 20:06:16, Mikulas Patocka wrote: > > > [...] > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > > */ > > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > > > +#ifdef CONFIG_DEBUG_SG > > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > > + if (!(prandom_u32_max(2) & 1)) > > > > + goto do_vmalloc; > > > > +#endif > > > > > > I really do not think there is anything DEBUG_SG...

...> > [...] > > > > > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f > > > > > > */ > > > > > > WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); > > > > > > > > > > > > +#ifdef CONFIG_DEBUG_SG > > > > > > + /* Catch bugs when the caller uses DMA API on the result of kvmalloc. */ > > > > > > + if (!(prandom_u32_max(2) & 1)) > > > > > > + goto do_vmalloc; > > > > > > +#endif > > > > > > > &gt...

...code. > > > > These bugs are hard to reproduce because kvmalloc falls back to vmalloc > > only if memory is fragmented. > > > > In order to detect these bugs reliably I submit this patch that changes > > kvmalloc to fall back to vmalloc with 1/2 probability if CONFIG_DEBUG_SG > > is turned on. CONFIG_DEBUG_SG is used, because it makes the DMA API layer > > verify the addresses passed to it, and so the user will get a reliable > > stacktrace. > > Why not just do it unconditionally? Sounds better than "50% of the time > this will catch b...

...o kmalloc > only if memory is fragmented. > > In order to detect these bugs reliably I submit this patch that changes > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on. > > Signed-off-by: Mikulas Patocka <mpatocka at redhat.com> Maybe make it conditional on CONFIG_DEBUG_SG too? Otherwise I think you just trigger a hard to debug memory corruption. > --- > mm/util.c | 2 ++ > 1 file changed, 2 insertions(+) > > Index: linux-2.6/mm/util.c > =================================================================== > --- linux-2.6.orig/mm/util.c 2018...

On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > Some bugs (such as buffer overflows) are better detected > with kmalloc code, so we must test the kmalloc path too. Well now, this brings up another item for the collective TODO list -- implement redzone checks for vmalloc. Unless this is something already taken care of by kasan or similar.

On Mon, 23 Apr 2018, Matthew Wilcox wrote: > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > Some bugs (such as buffer overflows) are better detected > > with kmalloc code, so we must test the kmalloc path too. > > Well now, this brings up another item for the collective TODO list -- > implement redzone checks for vmalloc. Unless this is something

On Tue, 24 Apr 2018, Matthew Wilcox wrote: > On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > > Some bugs (such as buffer overflows) are better detected > > > > with kmalloc code, so

On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > Some bugs (such as buffer overflows) are better detected > with kmalloc code, so we must test the kmalloc path too. Well now, this brings up another item for the collective TODO list -- implement redzone checks for vmalloc. Unless this is something already taken care of by kasan or similar.

...AFAIR. I've said it is not a good idea longterm. I would be much more willing to change my mind if you would back your patch by a real bug report. Hacks are acceptable when we have a real issue in hands. But if we want to fix potential issue then better make it properly. [...] > I sent the CONFIG_DEBUG_SG patch before (I wonder why he didn't repond to > it). I'll send a third version of the patch that actually randomly chooses > between kmalloc and vmalloc, because some abuses can only be detected with > kmalloc and we should test both. > > For bisecting, it is better to a...

...AFAIR. I've said it is not a good idea longterm. I would be much more willing to change my mind if you would back your patch by a real bug report. Hacks are acceptable when we have a real issue in hands. But if we want to fix potential issue then better make it properly. [...] > I sent the CONFIG_DEBUG_SG patch before (I wonder why he didn't repond to > it). I'll send a third version of the patch that actually randomly chooses > between kmalloc and vmalloc, because some abuses can only be detected with > kmalloc and we should test both. > > For bisecting, it is better to a...

On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > Some bugs (such as buffer overflows) are better detected > > > with kmalloc code, so we must test the kmalloc path too. > > > > Well now, this brings up

On Tue, Apr 24, 2018 at 08:29:14AM -0400, Mikulas Patocka wrote: > > > On Mon, 23 Apr 2018, Matthew Wilcox wrote: > > > On Mon, Apr 23, 2018 at 08:06:16PM -0400, Mikulas Patocka wrote: > > > Some bugs (such as buffer overflows) are better detected > > > with kmalloc code, so we must test the kmalloc path too. > > > > Well now, this brings up