Re: [tip: x86/shstk] mm: Don't allow write GUPs to shadow stack memory

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2023-07-21 at 10:34 +0200, Ingo Molnar wrote:
> 
> * tip-bot2 for Rick Edgecombe <tip-bot2@linutronix.de> wrote:
> 
> > The following commit has been merged into the x86/shstk branch of
> > tip:
> > 
> > Commit-ID:     7c8f82db8acb9f0935703c0d96cda552bbf91ff2
> > Gitweb:       
> > https://git.kernel.org/tip/7c8f82db8acb9f0935703c0d96cda552bbf91ff2
> > Author:        Rick Edgecombe <rick.p.edgecombe@intel.com>
> > AuthorDate:    Mon, 12 Jun 2023 17:10:48 -07:00
> > Committer:     Rick Edgecombe <rick.p.edgecombe@intel.com>
> > CommitterDate: Tue, 11 Jul 2023 14:12:47 -07:00
> > 
> > mm: Don't allow write GUPs to shadow stack memory
> 
> JFYI, this commit was the last user of
> writable_file_mapping_allowed(), 
> which breaks the x86-defconfig build:
> 
>   mm/gup.c:1015:13: error: ‘writable_file_mapping_allowed’ defined
> but not used [-Werror=unused-function]
> 
> There's also a now orphan reference to
> writable_file_mapping_allowed() in 
> the comment of folio_fast_pin_allowed().

Oh, thanks for letting me know. It looks like a rebase error on my
part. This hunk should not have been dropped in that commit:
-		if (!vma_anon &&
-		    !writable_file_mapping_allowed(vma, gup_flags))
-			return -EFAULT;
Then writable_file_mapping_allowed() would still have a reference.

As for the build breakage, I'm not sure how this slipped through. My
runtime test environment was missing CONFIG_WERROR, but I got 0day
build successes for the x86_64 and i386 defconfigs specifically. I'll
have to follow up with the 0day people.

Rick