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:   Tue, 1 Oct 2019 15:57:41 -0300
From:   Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To:     Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Clark Williams <williams@...hat.com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH 07/24] tools headers uapi: Sync linux/fs.h with the
 kernel sources

Em Tue, Oct 01, 2019 at 11:45:21AM -0700, Eric Biggers escreveu:
> On Tue, Oct 01, 2019 at 08:11:59AM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo <acme@...hat.com>
> > 
> > To pick the changes from:
> > 
> >   78a1b96bcf7a ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl")
> >   23c688b54016 ("fscrypt: allow unprivileged users to add/remove keys for v2 policies")
> >   5dae460c2292 ("fscrypt: v2 encryption policy support")
> >   5a7e29924dac ("fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl")
> >   b1c0ec3599f4 ("fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl")
> >   22d94f493bfb ("fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl")
> >   3b6df59bc4d2 ("fscrypt: use FSCRYPT_* definitions, not FS_*")
> >   2336d0deb2d4 ("fscrypt: use FSCRYPT_ prefix for uapi constants")
> >   7af0ab0d3aab ("fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h>")
> > 
> > That don't trigger any changes in tooling, as it so far is used only
> > for:
> > 
> >   $ grep -l 'fs\.h' tools/perf/trace/beauty/*.sh | xargs grep regex=
> >   tools/perf/trace/beauty/rename_flags.sh:regex='^[[:space:]]*#[[:space:]]*define[[:space:]]+RENAME_([[:alnum:]_]+)[[:space:]]+\(1[[:space:]]*<<[[:space:]]*([[:xdigit:]]+)[[:space:]]*\)[[:space:]]*.*'
> >   tools/perf/trace/beauty/sync_file_range.sh:regex='^[[:space:]]*#[[:space:]]*define[[:space:]]+SYNC_FILE_RANGE_([[:alnum:]_]+)[[:space:]]+([[:xdigit:]]+)[[:space:]]*.*'
> >   tools/perf/trace/beauty/usbdevfs_ioctl.sh:regex="^#[[:space:]]*define[[:space:]]+USBDEVFS_(\w+)(\(\w+\))?[[:space:]]+_IO[CWR]{0,2}\([[:space:]]*(_IOC_\w+,[[:space:]]*)?'U'[[:space:]]*,[[:space:]]*([[:digit:]]+).*"
> >   tools/perf/trace/beauty/usbdevfs_ioctl.sh:regex="^#[[:space:]]*define[[:space:]]+USBDEVFS_(\w+)[[:space:]]+_IO[WR]{0,2}\([[:space:]]*'U'[[:space:]]*,[[:space:]]*([[:digit:]]+).*"
> >   $
> > 
> > This silences this perf build warning:
> > 
> >   Warning: Kernel ABI header at 'tools/include/uapi/linux/fs.h' differs from latest version at 'include/uapi/linux/fs.h'
> >   diff -u tools/include/uapi/linux/fs.h include/uapi/linux/fs.h
> > 
> > Cc: Adrian Hunter <adrian.hunter@...el.com>
> > Cc: Eric Biggers <ebiggers@...gle.com>
> > Cc: Jiri Olsa <jolsa@...nel.org>
> > Cc: Namhyung Kim <namhyung@...nel.org>
> > Link: https://lkml.kernel.org/n/tip-44g48exl9br9ba0t64chqb4i@git.kernel.org
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
> 
> What's the reason why you don't just use the include/uapi/ headers directly?

We can't use anything from outside tools/perf/ to build it, sometimes
things get changed by kernel developers and tooling breaks.

Another reason is that we want to be able to do:

[acme@...co perf]$ make help | grep perf
  perf-tar-src-pkg    - Build perf-5.3.0.tar source tarball
  perf-targz-src-pkg  - Build perf-5.3.0.tar.gz source tarball
  perf-tarbz2-src-pkg - Build perf-5.3.0.tar.bz2 source tarball
  perf-tarxz-src-pkg  - Build perf-5.3.0.tar.xz source tarball
[acme@...co perf]$

Take that tarball, transfer it to an older system and still have it
building and working.

We also use the build warnings as hints that something needs to be
changed in tooling to pick up new kernel features, such as new ioctls,
syscall arguments to handle in 'perf trace', etc.

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ