On Thu, 2020-12-03 at 12:31 +, Matthew Wilcox wrote:
> And this just makes me think RCU freeing of mm_struct. I'm sure it's
> more complicated than that (then, or now), but if an anonymous
> process
> is borrowing a freed mm, and the mm is freed by RCU then it will not
> go
> away until the t
On Fri, 2018-07-20 at 10:30 +0200, Peter Zijlstra wrote:
> On Thu, Jul 19, 2018 at 10:04:09AM -0700, Andy Lutomirski wrote:
> > I added some more arch maintainers. The idea here is that, on x86
> > at
> > least, task->active_mm and all its refcounting is pure
> > overhead. When
> > a process exit
On Mon, 2016-07-25 at 16:29 -0700, Laura Abbott wrote:
> On 07/25/2016 02:42 PM, Rik van Riel wrote:
> > On Mon, 2016-07-25 at 12:16 -0700, Laura Abbott wrote:
> > > On 07/20/2016 01:27 PM, Kees Cook wrote:
> > > > Under CONFIG_HARDENED_USERCOPY, this adds o
On Mon, 2016-07-25 at 12:16 -0700, Laura Abbott wrote:
> On 07/20/2016 01:27 PM, Kees Cook wrote:
> > Under CONFIG_HARDENED_USERCOPY, this adds object size checking to
> > the
> > SLUB allocator to catch any copies that may span objects. Includes
> > a
> > redzone handling fix discovered by Michael
On Wed, 2016-07-20 at 16:02 +, David Laight wrote:
> From: Kees Cook
> > Sent: 20 July 2016 16:32
> ...
> > Yup: that's exactly what it's doing: walking up the stack. :)
>
> Remind me to make sure all our customers run kernels with it
> disabled.
You want a single copy_from_user to write to d
On Fri, 2016-07-15 at 09:20 +1000, Balbir Singh wrote:
> > ==
> > + ((unsigned long)end & (unsigned
> > long)PAGE_MASK)))
> > + return NULL;
> > +
> > + /* Allow if start and end are inside the same compound
> > page. */
> > + endpage = virt_to_head_page(end);
> > + if
On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
>
> Even with the SLUB fixup I'm still seeing this blow up on my arm64
> system. This is a
> Fedora rawhide kernel + the patches
>
> [0.666700] usercopy: kernel memory exposure attempt detected from
> fc0008b4dd58 () (8 bytes)
> [
On Wed, 2016-07-06 at 15:25 -0700, Kees Cook wrote:
>
> + /* Allow kernel rodata region (if not marked as Reserved).
> */
> + if (ptr >= (const void *)__start_rodata &&
> + end <= (const void *)__end_rodata)
> + return NULL;
>
One comment here.
__check_object_size get
port
> from Casey Schaufler. Additional non-slab page tests are from Rik van
> Riel.
Feel free to add my S-O-B for the code I wrote. The rest
looks good, too.
There may be some room for optimization later on, by putting
the most likely branches first, annotating with likely/unlikely,
etc
mdp_splitting flush
> until we enables IRQ
>
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Rik van Riel
--
All rights reversed
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 02/11/2014 05:34 AM, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> We will use this later to set the _PAGE_NUMA bit.
>
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Rik van Riel
--
All rights reversed
___
; hash. We also want
> to keep set_pte_at simpler by not requiring them to do hash flush for
> performance reason.
> Hence cannot use them while updating _PAGE_NUMA bit. Add new functions for
> marking pte/pmd numa
>
> Signed-off-
On 02/11/2014 05:34 AM, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> So move it within the if loop
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Rik van Riel
--
All rights reversed
___
Linuxppc-dev
ll only work if CONFIG_NUMA_BALANCING
is set.
Signed-off-by: Aneesh Kumar K.V
Reviewed-by: Rik van Riel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 12/05/2013 12:20 AM, Benjamin Herrenschmidt wrote:
On Thu, 2013-12-05 at 10:48 +0530, Aneesh Kumar K.V wrote:
Ok, I can move the changes below #ifdef CONFIG_NUMA_BALANCING ? We call
change_prot_numa from task_numa_work and queue_pages_range(). The later
may be an issue. So doing the below wi
that, the called code was made generic enough,
that change_prot_numa should actually work for
everything.
In other words:
Reviewed-by: Rik van Riel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
up in the future if
somebody changes the algorithm and forgets to update one of the
copies :-)
All right, does the following look more palatable then ?
(didn't re-test it, though)
Looks equivalent. I have also not tested :)
Signed-off-by
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Since all architectures have been converted to use vm_unmapped_area(),
there is no remaining use for the free_area_cache.
Signed-off-by: Michel Lespinasse
Yay
Acked-by: Rik van Riel
___
Linuxppc
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
. Next one will convert that function to use the
vm_unmapped_area() infrastructure and regain the performance.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the ia64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the ia64 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
___
Linuxppc
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the frv arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
___
Linuxppc
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
___
Linuxppc
On 01/08/2013 08:28 PM, Michel Lespinasse wrote:
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
Acked-by: Rik van Riel
25 matches
Mail list logo
