linux-kernel - Re: [PATCH v4 6/8] create/adjust generated/autoksyms.h

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: <alpine.LFD.2.20.1603031809120.13632@knanqh.ubzr>
Date:	Thu, 3 Mar 2016 20:53:27 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Michal Marek <mmarek@...e.com>
cc:	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 6/8] create/adjust generated/autoksyms.h

On Thu, 3 Mar 2016, Michal Marek wrote:

> Hi Nicolas,
> 
> sorry for the late review.
> 
> Dne 29.2.2016 v 04:48 Nicolas Pitre napsal(a):
> > +set -e
> > +
> > +cur_ksyms_file="include/generated/autoksyms.h"
> > +new_ksyms_file="include/generated/autoksyms.h.tmpnew"
> > +
> > +info() { [ "$quiet" != "silent_" ] && printf "  %-7s %s\n" "$1" "$2"; }
> 
> Using && as a shorthand for if-statements does not work when running in
> -e mode. This particular line causes the script to fail in silent mode.
> There other uses of && in the script are inside sub-shells, so they do
> work, but it would be good to convert them to avoid breakage if the
> script is edited later.

OK.

> > +# Extract changes between old and new list and touch corresponding
> > +# dependency files.
> > +# Note: sort -m doesn't work well with underscore prefixed symbols so we
> > +# use 'cat ... | sort' instead.
> > +changed=$(
> > +count=0
> > +cat "$cur_ksyms_file" "$new_ksyms_file" | sort | uniq -u |
> 
> sort "$cur_ksyms_file" "$new_ksyms_file" ?

Ah, indeed. Somehow I understood that you could use two files only
with -m.

> sort -m probably does not work, because the input files are not 
> sorted.

They used to at some point as as the content comes from the earlier 
"sort -u".  I had test samples but I can't find them anymore.

Anyway I prefer not to rely on a pre-existing ordering if possible, and 
with the addition of the file header and the CONFIG_MODVERSIONS case 
that came afterwards the content is no longer 100% sorted.  With "sort 
file1 file2" the comment is not very relevant anymore.


Nicolas