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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YaeErF5h+SQkxBXC@kroah.com>
Date:   Wed, 1 Dec 2021 15:20:28 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Luis Chamberlain <mcgrof@...nel.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 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.

thanks,

greg k-h