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] [day] [month] [year] [list]
Date: Wed, 22 May 2024 14:32:58 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: linux-arm-kernel@...ts.infradead.org,
 Duanqiang Wen <duanqiangwen@...-swift.com>, mturquette@...libre.com,
 sboyd@...nel.org, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clkdev: report over-sized strings when creating clkdev
 entries

On 5/22/24 02:34, Russell King (Oracle) wrote:
> On Wed, May 22, 2024 at 08:53:18AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
>> Hmmm. Communication problem aside, this in the end seems to be a
>> regression that is caused by a change of yours. Maybe not a major one
>> that is making a fuzz about, but still one that would be good to get
>> fixed. So who will take care of that?
> 
> I have suggested several approaches to fixing it, and each time I'm
> being ignored by Guenter, who seems to have some other agenda -
> because he seems to believe that using dev_name() when registering
> the clk with clkdev is wrong... despite the fact that clkdev uses
> dev_name().
> 

I don't have an agenda. I did not intentionally ignore anyone.
Misunderstand, maybe, but not ignore. I don't care how this is fixed.
All I intended to do was to report it. My apologies to anyone who
I managed to offend.

> What I am uncertain about is:
> 1) whether clkdev is even necessary here, or whether it is pure noise.
>     I think it's pure noise.  Why? The dev_name() that is being used#
>     to register the clk seems to be the _source_ device of the clock,
>     whereas the name given should be the _consumer_ of the clock (when
>     clk_get(dev, con_id) is called, dev is the _consumer_ device, and
>     this is the device that dev_name() is used internally with.) Thus,
>     if _that_ device is not the same as the struct device that is being
>     passed to dev_name() when registering the clk, the entry in clkdev
>     is utterly useless.
> 
> 2) why someone would think that using best_dev_name() to work around
>     this would be a good idea. One might as well pass the string
>     "hahaha" when registering the clk - because if the device name is
>     truncated, clk_get() is not going to find it. So, by registering
>     it with clkdev, we're just eating memory for no reason.
> 
> Therefore, this change is finding bugs elsewhere. Should it cause a
> boot failure? No, and I'm happy to make clkdev just warn about it.
> However, reverting the change means we're not going to find these
> issues.
> 
> Why was the change originally proposed (by Duanqiang Wen) ? The reason
> was because of this truncation causing clk_get() to fail unexpectedly.
> 
> I am all for a _sensible_ discussion over this - not one that seems to
> have an agenda about "should dev_name() be used when registering a
> clk" that seems to be Guenter's approach because _that_ is not the root
> cause of the issue and I've already explained that _that_ is not the
> issue here. Yet, Guenter insists on that.
> 

I don't know if using dev_name() is wrong or not. I don't know much
if anything about the clock subsystem. Someone else said that using
dev_name() would be a "bad idea", or at least that was my understanding.
That is all. Again, my apologies for any misunderstanding and for
getting involved beyond the initial report.

Either case, I really don't want to be involved further, and
_please_ don't make any assumptions or decisions based on anything
I may have said out of ignorance.

Thanks,
Guenter


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ