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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170523235317.GE11878@marvin.atrad.com.au>
Date:   Wed, 24 May 2017 09:23:17 +0930
From:   Jonathan Woithe <jwoithe@...t42.net>
To:     Micha?? K??pie?? <kernel@...pniu.pl>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/8] platform/x86: fujitsu-laptop: track the last
 instantiated FUJ02E3 ACPI device

On Tue, May 23, 2017 at 11:47:06PM +0200, Micha?? K??pie?? wrote:
> > On Fri, May 19, 2017 at 09:44:45AM +0200, Micha?? K??pie?? wrote:
> > > It is easier to simply store a module-wide
> > > pointer to the last (most likely only) FUJ02E3 ACPI device found, make
> > > the aforementioned API use it and cover our bases by warning the user if
> > > firmware exposes multiple FUJ02E3 ACPI devices.
> > > :
> > > @@ -788,6 +789,9 @@ static int acpi_fujitsu_laptop_add(struct acpi_device *device)
> > >  	if (!priv)
> > >  		return -ENOMEM;
> > >  
> > > +	WARN_ONCE(fext, "More than one FUJ02E3 ACPI device was found.  Driver may not work as intended.");
> > > +	fext = device;
> > > +
> > >  	fujitsu_laptop = priv;
> > >  	fujitsu_laptop->acpi_handle = device->handle;
> > >  	sprintf(acpi_device_name(device), "%s",
> > 
> > I thought WARN_ONCE() printed the warning when it was encountered for the
> > first time and then suppressed it on all other occasions.
> 
> Correct.
> 
> > If this is true
> > then we'll get the warning even when there is only one FUJ02E3 in the
> > system.  Am I missing something?
> 
> Probably the fact that the first argument of the macro is a conditional
> expression ...

Ah (having now had an opportunity to look at the source of WARN_ONCE()),
it's tested within WARN_ONCE.

> ("fext" is functionally equivalent to "fext != NULL" in this case).

Indeed, by virtue of the test done in WARN_ONCE().  Ok, that makes sense.

Regards
  jonathan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ