linux-kernel - Re: [PATCH] firmware_loader: export sysctl registration

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, 1 Dec 2021 06:25:42 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     akpm@...ux-foundation.org, keescook@...omium.org,
        yzaikin@...gle.com, nixiaoming@...wei.com, ebiederm@...ssion.com,
        steve@....org, rafael@...nel.org, tytso@....edu,
        viro@...iv.linux.org.uk, pmladek@...e.com,
        senozhatsky@...omium.org, rostedt@...dmis.org,
        john.ogness@...utronix.de, dgilbert@...erlog.com,
        jejb@...ux.ibm.com, martin.petersen@...cle.com,
        linux-scsi@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH] firmware_loader: export sysctl registration

On Wed, Dec 01, 2021 at 03:20:28PM +0100, Greg KH wrote:
> On Wed, Dec 01, 2021 at 05:48:18AM -0800, Luis Chamberlain wrote:
> > On Wed, Dec 01, 2021 at 08:08:00AM +0100, Greg KH wrote:
> > > On Tue, Nov 30, 2021 at 08:45:25AM -0800, Luis Chamberlain wrote:
> > > > The firmware loader fallback sysctl table is always built-in,
> > > > but when FW_LOADER=m the build will fail. We need to export
> > > > the sysctl registration and de-registration. Use the private
> > > > symbol namespace so that only the firmware loader uses these
> > > > calls.
> > > > 
> > > > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> > > > Fixes: firmware_loader: move firmware sysctl to its own files
> > > 
> > > Have a git id for this?
> > 
> > I thought it would be ephemeral at this point since it was on
> > linux-next, so had not provided one. If it is a static commit
> > then I suppose this is 5cc0fea09ee52c9bcb6c41456bea03ca1b49602d
> 
> Depends on where it came from.  If -mm then yes, it's not a valid id.
> If someone else, it might be a real id.

It came in through -mm.

  Luis