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@google.com Date: Mon Jun 8 21:33:14 2020 -0700
mmap locking API: initial implementation as rwsem wrappersThe 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? 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). 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.
I will drop this patch from the tree now, so everyone can figure out what they want to do in the future :)
That certainly seems like the right way to go for now, thanks!