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: <20201014173906.aytbl4bjbwjwa6wr@bogus>
Date:   Wed, 14 Oct 2020 18:39:06 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Cristian Marussi <cristian.marussi@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Sudeep Holla <sudeep.holla@....com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH] firmware: arm_scmi: Fix duplicate workqueue name

On Wed, Oct 14, 2020 at 10:13:04AM -0700, Florian Fainelli wrote:
> On 10/14/20 9:18 AM, Sudeep Holla wrote:
> > On Wed, Oct 14, 2020 at 02:48:19PM +0100, Cristian Marussi wrote:
> > 
> > [...]
> > 
> >>>
> >>> I have pushed a version with above change [1], please check if you are
> >>> happy with that ?
> >>>
> >>> [1] https://git.kernel.org/sudeep.holla/linux/c/b2cd15549b
> >>
> >> I agree with the need to retain _notify name, but I'm not so sure about
> >> the above patch...which is:
> >>
> > 
> > I agree, I thought about it and just cooked up this as a quick solution.
> > I will move to that, even I wasn't happy with this TBH.
> 
> The reason why I went with just dev_name() was such that the workqueue
> name and the device nodes under /sys would strictly match, which helps
> as an user, and also it avoided the temporary buffer and its size
> limitations.

Agreed. I just showed that as example and was hoping to use some nice
kstr* APIs to achieve what I wanted but soon realised there exists none.
So as replied earlier, I will take this change as it for now. Let us
address this in future if it becomes an issue.

Thanks for quick test, we now know whom to bother if we need more testing
😉 as out internal platforms are not that great to cover all the aspects
we add in the spec and even in the kernel.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ