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]
Date:   Thu, 11 May 2017 19:11:43 +0200
From:   "Luis R. Rodriguez" <mcgrof@...e.com>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        gregkh@...uxfoundation.org, wagi@...om.org, dwmw2@...radead.org,
        rafal@...ecki.pl, arend.vanspriel@...adcom.com, rjw@...ysocki.net,
        yi1.li@...ux.intel.com, atull@...nsource.altera.com,
        moritz.fischer@...us.com, pmladek@...e.com,
        johannes.berg@...el.com, emmanuel.grumbach@...el.com,
        luciano.coelho@...el.com, kvalo@...eaurora.org, luto@...nel.org,
        dhowells@...hat.com, pjones@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 3/5] test: add new driver_data load tester

On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> Luis,
> 
> On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > +To test an async call one could do::
> > > > +
> > > > +        echo anything > /lib/firmware/test-driver_data.bin
> > > 
> > > Your current shell script doesn't search for the firmware in
> > > /lib/firmware unless you explicitly specify $FWPATH.
> > 
> > This is true but that is the *test* shell script, and it purposely avoids the
> > existing firmware path to avoid overriding dummy test files on the production
> > path. So the above still stands as it is not using the test shell script
> > driver_data.sh.
> > 
> > I'll add a note:
> > 
> > """
> > Note that driver_data.sh uses its own temporary custom path for creating and    
> > looking for driver data files, it does this to not overwrite any production     
> > files you might have which may share the same names used by the test shell      
> > script driver_data.sh. If you are not using the driver_data.sh script your      
> > default path will be used. 
> > """
> 
> That looks fine, but I think we'd better change the line:
> 
> > > > +        echo anything > /lib/firmware/test-driver_data.bin
> 
> since it is just incorrect as far as driver_data.sh goes.

But that is accurate, given the default file we search for on test_driver_data.c
is test-driver_data.bin. It also does not create a conflict to overwrite a file
used on driver_data.sh as driver_data.sh uses a custom path. I think the note
above on custom path is sufficient for the developer or user to be aware of
the fact the driver_data.sh does it own thing, and that the example is just a
manual test case.

What do you mean by that its incorrect ?

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ