linux-kernel - Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0fcbb91ab6dc49807dcca953c5dca673ad403045.camel@wdc.com>
Date:   Wed, 22 Jul 2020 15:11:35 +0000
From:   Atish Patra <Atish.Patra@....com>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "palmerdabbelt@...gle.com" <palmerdabbelt@...gle.com>
CC:     "walken@...gle.com" <walken@...gle.com>,
        "naresh.kamboju@...aro.org" <naresh.kamboju@...aro.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "lkft-triage@...ts.linaro.org" <lkft-triage@...ts.linaro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zong.li@...ive.com" <zong.li@...ive.com>,
        "shorne@...il.com" <shorne@...il.com>
Subject: Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking
 walk_page_range

On Wed, 2020-07-22 at 14:48 +0200, Greg KH wrote:
> On Tue, Jul 21, 2020 at 03:50:35PM -0700, Palmer Dabbelt wrote:
> > On Mon, 20 Jul 2020 12:14:03 PDT (-0700), Greg KH wrote:
> > > On Mon, Jul 20, 2020 at 06:50:10PM +0000, Atish Patra wrote:
> > > > On Mon, 2020-07-20 at 23:11 +0530, Naresh Kamboju wrote:
> > > > > RISC-V build breaks on stable-rc 5.7 branch.
> > > > > build failed with gcc-8, gcc-9 and gcc-9.
> > > > > 
> > > > 
> > > > Sorry for the compilation issue.
> > > > 
> > > > mmap_read_lock was intrdouced in the following commit.
> > > > 
> > > > commit 9740ca4e95b4
> > > > Author: Michel Lespinasse <walken@...gle.com>
> > > > Date:   Mon Jun 8 21:33:14 2020 -0700
> > > > 
> > > >     mmap locking API: initial implementation as rwsem wrappers
> > > > 
> > > > The following two commits replaced the usage of mmap_sem rwsem
> > > > calls
> > > > with mmap_lock.
> > > > 
> > > > d8ed45c5dcd4 (mmap locking API: use coccinelle to convert
> > > > mmap_sem
> > > > rwsem call sites)
> > > > 89154dd5313f (mmap locking API: convert mmap_sem call sites
> > > > missed by
> > > > coccinelle)
> > > > 
> > > > The first commit is not present in stale 5.7-y for obvious
> > > > reasons.
> > > > 
> > > > Do we need to send a separate patch only for stable branch with
> > > > mmap_sem ? I am not sure if that will cause a conflict again in
> > > > future.
> > > 
> > > I do not like taking odd backports, and would rather take the
> > > real patch
> > > that is upstream.
> > 
> > I guess I'm a bit new to stable backports so I'm not sure what's
> > expected here.
> > The failing patch fixes a bug by using a new interface.  The
> > smallest diff fix
> > for the stable kernels would be to construct a similar fix without
> > the new
> > interface, which in this case is very easy as the new interface
> > just converted
> > some generic locking calls to one-line functions.  It seems
> > somewhat circuitous
> > to land that in Linus' tree, though, as it would require breaking
> > our port
> > before fixing it to use the old interfaces and then cleaning it up
> > to use the
> > new interfaces.
> > 
> > Are we expected to pull the new interface onto stable in addition
> > to this fix?
> 
> If it really does fix a big issue, yes, that is fine to do.
> 

The original issue was manifests only for certain rootfs with
CONFIG_DEBUG_VM enabled in kernel. I am not sure if that qualfies for a
big issue :). But there was a similar fix for OpenRISC as well.

+stafford (who fixed the issue for OpenRISC)

@stafford Was there a request to backport the fix to stable ?

I can combine all the git ids that needs to be pulled in.

> > The new interface doesn't actually fix anything itself, but it
> > would allow a
> > functional kernel to be constructed that consisted of only
> > backports from
> > Linus' tree (which would also make further fixes easier).
> 
> That's fine.
> 
> > It seems safe to
> > just pull in 9740ca4e95b4 ("mmap locking API: initial
> > implementation as rwsem
> > wrappers") before this failing patch, as in this case the new
> > interface will
> > function correctly with only a subset of callers having been
> > converted.  Of
> > course that's not a generally true statement so I don't know if
> > future code
> > will behave that way, but pulling in those conversion patches is
> > definitely
> > unnecessary diff right now.
> 
> If someone wants to send me a full set of the git ids that need to be
> pulled in, I will be glad to do so.
> 
> thanks,
> 
> greg k-h

-- 
Regards,
Atish