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]
Date:   Mon, 20 Jul 2020 21:14:03 +0200
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Atish Patra <Atish.Patra@....com>
Cc:     "naresh.kamboju@...aro.org" <naresh.kamboju@...aro.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "walken@...gle.com" <walken@...gle.com>,
        "palmerdabbelt@...gle.com" <palmerdabbelt@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zong.li@...ive.com" <zong.li@...ive.com>,
        "lkft-triage@...ts.linaro.org" <lkft-triage@...ts.linaro.org>
Subject: Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking
 walk_page_range

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 will drop this patch from the tree now, so everyone can figure out
what they want to do in the future :)

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ