Displaying 19 results from an estimated 19 matches for "prandom_u32_max".
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...6, 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 function?
> +
> /*
> * We want to attempt a large physically contiguous block first because
>...
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...6, 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 function?
> +
> /*
> * We want to attempt a large physically contiguous block first because
>...
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...id *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 function?
>
> CONFIG_DEBUG_SG is enabled by default in RHE...
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...id *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 function?
>
> CONFIG_DEBUG_SG is enabled by default in RHE...
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...gt; */
> > > > > 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 function?
>...
2018 Apr 24
2
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...gt; */
> > > > > 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 function?
>...
2018 Apr 24
0
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...#include <asm/sections.h>
#include <linux/uaccess.h>
@@ -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
+
/*
* We want to attempt a large physically contiguous block first because
* it is less likely to fragment multiple larger blocks and therefore
@@ -427,6 +434,9 @@ void *kvmalloc_node(size_t size, gfp_t f
if (ret || size <= PAGE_SIZE)
return...
2018 Apr 24
0
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_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
>
> 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 function?
CONFIG_DEBUG_SG is enabled by default in RHEL and Fedora debug kernel (if
you...
2018 Apr 24
0
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...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 function?
> >
> > CONFIG_DE...
2018 Apr 24
0
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...> > > 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...
2018 Apr 23
6
[PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
>
>
> On Sat, 21 Apr 2018, Matthew Wilcox wrote:
>
> > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
2018 Apr 23
6
[PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
>
>
> On Sat, 21 Apr 2018, Matthew Wilcox wrote:
>
> > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
2015 Jan 28
2
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
...he future ones.
> > > All that's required is that two paths go through the same box performing
> > > fragmentation.
> > >
> > > Is that a fair summary?
>
> No answer here?
Ups, sorry.
It is not re-randomized but only biased by a time delta (note the
prandom_u32_max). So even after such an increment happens you can still
guess the range of the current fragmentation ids for a longer time.
Otherwise it is a fair summary.
>
> > > If yes, we can make this a bit harder by mixing in some
> > > data per input and/or output devices.
> > &...
2015 Jan 28
2
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
...he future ones.
> > > All that's required is that two paths go through the same box performing
> > > fragmentation.
> > >
> > > Is that a fair summary?
>
> No answer here?
Ups, sorry.
It is not re-randomized but only biased by a time delta (note the
prandom_u32_max). So even after such an increment happens you can still
guess the range of the current fragmentation ids for a longer time.
Otherwise it is a fair summary.
>
> > > If yes, we can make this a bit harder by mixing in some
> > > data per input and/or output devices.
> > &...
2015 Jan 28
0
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
...ired is that two paths go through the same box performing
> > > > fragmentation.
> > > >
> > > > Is that a fair summary?
> >
> > No answer here?
>
> Ups, sorry.
>
> It is not re-randomized but only biased by a time delta (note the
> prandom_u32_max). So even after such an increment happens you can still
> guess the range of the current fragmentation ids for a longer time.
>
> Otherwise it is a fair summary.
>
> >
> > > > If yes, we can make this a bit harder by mixing in some
> > > > data per input...
2015 Jan 28
0
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
...ired is that two paths go through the same box performing
> > > > fragmentation.
> > > >
> > > > Is that a fair summary?
> >
> > No answer here?
>
> Ups, sorry.
>
> It is not re-randomized but only biased by a time delta (note the
> prandom_u32_max). So even after such an increment happens you can still
> guess the range of the current fragmentation ids for a longer time.
>
> Otherwise it is a fair summary.
>
> >
> > > > If yes, we can make this a bit harder by mixing in some
> > > > data per input...
2018 Apr 24
4
[PATCH v3] kvmalloc: always use vmalloc if CONFIG_DEBUG_SG
...N_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 shou...
2015 Jan 28
7
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
Hi,
On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> > Hello,
> >
> > On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote:
2015 Jan 28
7
[PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
Hi,
On Mi, 2015-01-28 at 11:46 +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 28, 2015 at 09:25:08AM +0100, Hannes Frederic Sowa wrote:
> > Hello,
> >
> > On Di, 2015-01-27 at 18:08 +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 27, 2015 at 05:02:31PM +0100, Hannes Frederic Sowa wrote:
> > > > On Di, 2015-01-27 at 09:26 -0500, Vlad Yasevich wrote: