linux-kernel - Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

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: <2023092027-epileptic-jolly-84ef@gregkh>
Date:   Wed, 20 Sep 2023 12:48:00 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Zev Weiss <zev@...ilderbeest.net>
Cc:     Mark Brown <broonie@...nel.org>,
        Naresh Solanki <naresh.solanki@...ements.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output

On Wed, Sep 20, 2023 at 03:44:29AM -0700, Zev Weiss wrote:
> On Wed, Sep 20, 2023 at 02:29:15AM PDT, Greg Kroah-Hartman wrote:
> > On Wed, Sep 20, 2023 at 02:02:49AM -0700, Zev Weiss wrote:
> > >  static int regulator_userspace_notify(struct notifier_block *nb,
> > >  				      unsigned long event,
> > >  				      void *ignored)
> > >  {
> > >  	struct userspace_consumer_data *data =
> > >  		container_of(nb, struct userspace_consumer_data, nb);
> > > -	static const char * const *envp[] = { "NAME=events", NULL };
> > 
> > You removed this user/kernel api value, what will break if you do that?
> > 
> 
> Sorry, I don't follow -- what removal are you referring to?  The envp array
> still has a NAME entry -- I changed its value from "events" to "event",

Yes, that value.

> but
> I wrote that part before I realized that the 'event' parameter of the
> function was actually a bitmask that might convey multiple events and just
> forgot to change it back, so keeping it pluralized is probably more
> appropriate.
> 
> And FWIW, I didn't intend for the exact format of the EVENT parameter that I
> sketched there to be something that had to be kept; given that there might
> be multiple entries perhaps it'd be better to use separate parameters more
> like NUMEVENTS, EVENT0, EVENT1, etc?  (Or omit NUMEVENTS and just let the
> consumer count upward until it doesn't find a match.)

I don't know, what does userspace do with this value today?  If you
change it, what will break?

thanks,

greg k-h