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: <20190829164217.GJ5281@sasha-vm>
Date:   Thu, 29 Aug 2019 12:42:17 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Tyler Hicks <tyhicks@...onical.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Todd Kjos <tkjos@...roid.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devel@...verdev.osuosl.org
Subject: Re: [PATCH AUTOSEL 4.14 05/14] binder: take read mode of mmap_sem in
 binder_alloc_free_page()

On Thu, Aug 29, 2019 at 10:10:52AM -0500, Tyler Hicks wrote:
>Hello, Sasha!
>
>On 2019-08-29 06:50:34, Sasha Levin wrote:
>> From: Tyler Hicks <tyhicks@...onical.com>
>>
>> [ Upstream commit 60d4885710836595192c42d3e04b27551d30ec91 ]
>>
>> Restore the behavior of locking mmap_sem for reading in
>> binder_alloc_free_page(), as was first done in commit 3013bf62b67a
>> ("binder: reduce mmap_sem write-side lock"). That change was
>> inadvertently reverted by commit 5cec2d2e5839 ("binder: fix race between
>> munmap() and direct reclaim").
>>
>> In addition, change the name of the label for the error path to
>> accurately reflect that we're taking the lock for reading.
>>
>> Backporting note: This fix is only needed when *both* of the commits
>> mentioned above are applied. That's an unlikely situation since they
>> both landed during the development of v5.1 but only one of them is
>> targeted for stable.
>
>This patch isn't meant to be applied to 4.14 since commit 3013bf62b67a
>("binder: reduce mmap_sem write-side lock") was never brought back to
>4.14.
>
>My backporting note above isn't helpful for AUTOSEL purposes. Do you
>have a suggestion for what I could have done in the patch tags to convey
>that guidance to AUTOSEL?

Hey Tyler,

No, this is just me messing up. AUTOSEL actually handled this well.

What happened here you ask? This series is basically a set of patches
that fix a different fix that went into stable. It didn't go through the
regular AUTOSEL flow and I goofed up manually. Sorry for the noise, I've
dropped the patch.

--
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ