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:   Thu, 9 Jun 2022 09:56:21 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Denis Ciocca <denis.ciocca@...com>, linus.walleij@...aro.org,
        lars@...afoo.de, andy.shevchenko@...il.com, aardelean@...iqon.com,
        cai.huoqing@...ux.dev, linux-iio@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 5.18 03/68] iio: st_sensors: Add a local lock for
 protecting odr

On Wed, Jun 08, 2022 at 10:26:51AM +0100, Jonathan Cameron wrote:
>On Tue,  7 Jun 2022 13:47:29 -0400
>Sasha Levin <sashal@...nel.org> wrote:
>
>> From: Miquel Raynal <miquel.raynal@...tlin.com>
>>
>> [ Upstream commit 474010127e2505fc463236470908e1ff5ddb3578 ]
>>
>> Right now the (framework) mlock lock is (ab)used for multiple purposes:
>> 1- protecting concurrent accesses over the odr local cache
>> 2- avoid changing samplig frequency whilst buffer is running
>>
>> Let's start by handling situation #1 with a local lock.
>>
>> Suggested-by: Jonathan Cameron <jic23@...nel.org>
>> Cc: Denis Ciocca <denis.ciocca@...com>
>> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
>> Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com
>> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
>> Signed-off-by: Sasha Levin <sashal@...nel.org>
>
>Hi Sasha,
>
>This one is a cleanup rather than a fix. It's part of a long term move to stop
>drivers using an internal lock (which works, but limits our ability to
>change the core code).  No problem backporting it if it makes
>taking some other fix easier, but I'm not immediately seeing such a patch.

Yup, it's not a dependency. I'll drop it.

-- 
Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ