linux-kernel - Re: [PATCH RESEND for 5.10] pwm: sl28cpld: fix getting driver data in pwm callbacks

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: <20201204140336.jkemihnqqwozu45x@pengutronix.de>
Date:   Fri, 4 Dec 2020 15:03:36 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Michael Walle <michael@...le.cc>, kernel@...gutronix.de,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RESEND for 5.10] pwm: sl28cpld: fix getting driver data
 in pwm callbacks

Hello Lee,

On Fri, Dec 04, 2020 at 01:24:36PM +0000, Lee Jones wrote:
> On Fri, 04 Dec 2020, Thierry Reding wrote:
> > Now, I can no longer find a link to the discussion that I recall, so it
> > was either on IRC (where I don't have any logs) or I'm loosing my mind.
> 
> Don't worry, you are (probably!) still quite sane.
> 
> The discussion happened over IRC.

FTR, the conversation was as follows (with lag = Lee, tags = Thierry and
ukleinek = me):

1606741876 < ukleinek> tagr, lag: would you mind if I send 20201124212432.3117322-1-u.kleine-koenig@...gutronix.de to Linus?
1606741894 < ukleinek> tagr: or if you do mind, can you please send it?
[...]
1606742364 < lag> ukleinek: I assume this is the container_of() patch?
1606742370 < ukleinek> lag: right
1606742402 < lag> ukleinek: It seems very wrong that a leaf controller driver's ops would be called before it has probed
1606742410 < lag> ukleinek: How is that a thing?
1606742428 < ukleinek> lag: the ops can be called as soon as pwmchip_add completes
1606742443 < lag> ukleinek: Where is pwmchip_add() called
1606742470 < lag> I guess I can grep that myself
1606742480 < ukleinek> lag: just before platform_set_drvdata(pdev, priv) in sl28cpld_pwm_probe()
1606742755 < lag> ukleinek: What about moving pwmchip_add() after platform_set_drvdata() or vice versa?
1606742789 < ukleinek> lag: did you read the commit log?
1606742845 < lag> ukleinek: I did
1606742981 < ukleinek> lag: then I don't get your question
1606743049 < lag> ukleinek: Why is using container_of, which is generally horrible and only used if there is no other way to obtain data, better than changing order of the calls such that the dependencies are met
1606743127 < ukleinek> container_of is a well understood concept and it's cheaper than dev_get_drvdata
1606743198 < ukleinek> and conceptually it's easier too. (But that might only be me)
1606743241 < ukleinek> for one thing it cannot happen that I get a wrong pointer because platform_set_drvdata was called too late
1606743281 < ukleinek> also it makes use of the fact that platform_set_drvdata sets the driver's driver data and not something in the platform device

> I highlighted my concerns, but Uwe didn't respond to them.  This patch
> was the next time I saw anything on the subject.

So I did respond and if you didn't see it the problem is on your end.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)