Re: [PATCH] mm: Update do_vmi_align_munmap() return semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [230630 12:19]:
> On Fri, 30 Jun 2023 at 09:06, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
> >
> > Update do_vmi_align_munmap() to return 0 for success.  Clean up the
> > callers and comments to always expect the lock downgrade to be honored
> > on the success path.  The error path will always leave the lock
> > untouched.
> 
> Thanks for doing this, but with this cleanup, it becomes clear that
> some of the callers that asked for a downgrade didn't actually want
> that at all...

...

> 
> I didn't look at what all the indirect callers here were doing, but it
> really looked to me like *most* callers wanted the lock dropped
> entirely at the end.
> 
> In fact, looking at that patch, it looks like *all* of the callers
> that asked for downgrading actually really wanted the lock dropped
> entirely.
> 
> But I may well be missing some context.  So take this not as a NAK,
> but as a "you looked at all this code, could it perhaps be simplified
> a bit more still?"
> 

Sure, I noticed that but didn't want to change too much, at least in one
commit.  I'll double check and will keep cleaning here.

I'm not sure how many error scenarios need the lock at all on return
either.

I hesitate to ask considering how much trouble I've caused with the
32bit map flag, but I also wonder about the stack guard now that the
write lock is taken for stack expansion?

Thanks,
Liam




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux