Re: [PATCH v3 08/12] treewide: Use initializer for struct vm_unmapped_area_info

2024-03-13 Thread Edgecombe, Rick P
On Tue, 2024-03-12 at 20:18 -0700, Kees Cook wrote: > > Thanks! This looks to do exactly what it describes. :) > > Reviewed-by: Kees Cook Thanks! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

2024-03-04 Thread Edgecombe, Rick P
On Mon, 2024-03-04 at 18:00 +, Christophe Leroy wrote: > > Personally, I think a single patch that sets "= {}" for all of them > > and > > drop the all the "= 0" or "= NULL" assignments would be the > > cleanest way > > to go. > > I agree with Kees, set = {} and drop all the "something = 0;"

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

2024-03-01 Thread Edgecombe, Rick P
On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote: > I totally understand. If the "uninitialized" warnings were actually > reliable, I would agree. I look at it this way: > > - initializations can be missed either in static initializers or via >   run time initializers. (So the risk of mistake

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

2024-02-28 Thread Edgecombe, Rick P
On Wed, 2024-02-28 at 13:22 +, Christophe Leroy wrote: > > Any preference? Or maybe am I missing your point and talking > > nonsense? > > > > So my preference would go to the addition of: > > info.new_field = 0; > > But that's very minor and if you think it is easier to manage and

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

2024-02-27 Thread Edgecombe, Rick P
On Tue, 2024-02-27 at 18:16 +, Christophe Leroy wrote: > > > Why doing a full init of the struct when all fields are re- > > > written a few > > > lines after ? > > > > It's a nice change for robustness and makes future changes easier. > > It's > > not actually wasteful since the compiler

Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info

2024-02-27 Thread Edgecombe, Rick P
On Tue, 2024-02-27 at 07:02 +, Christophe Leroy wrote: > > It could be possible to initialize the new field for each arch to > > 0, but > > instead simply inialize the field with a C99 struct inializing > > syntax. > > Why doing a full init of the struct when all fields are re-written a > few

Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()

2023-07-17 Thread Edgecombe, Rick P
On Fri, 2023-07-14 at 23:57 +0100, Mark Brown wrote: > On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote: > > The x86 Shadow stack feature includes a new type of memory called > > shadow > > stack. This shadow stack memory has some unusual properties, which > > requires > > some core

Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()

2023-06-13 Thread Edgecombe, Rick P
On Tue, 2023-06-13 at 09:19 +0200, Geert Uytterhoeven wrote: > Acked-by: Geert Uytterhoeven Thanks! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()

2023-06-13 Thread Edgecombe, Rick P
On Tue, 2023-06-13 at 14:26 +0200, David Hildenbrand wrote: > > Acked-by: David Hildenbrand Thanks! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA

2023-02-20 Thread Edgecombe, Rick P
On Mon, 2023-02-20 at 12:23 +0100, David Hildenbrand wrote: > That looks painful but IMHO worth it :) > > Acked-by: David Hildenbrand Thanks. Yes it was not the most fun, but I agree - worth it. ___ linux-snps-arc mailing list

Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA

2023-02-20 Thread Edgecombe, Rick P
On Mon, 2023-02-20 at 12:00 +1100, Michael Ellerman wrote: > Acked-by: Michael Ellerman (powerpc) Thanks! ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc