- May 15, 2019
-
-
Leonard Crestez authored
The clk rate is always stored in clk_core but might be out of date and require calls to update from hardware. Deal with that case by printing a (c) suffix. Link: http://lkml.kernel.org/r/1a474318982a5f0125f2360c4161029b17f56bd1.1556881728.git.leonard.crestez@nxp.com Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Leonard Crestez authored
An incorrect argument to list_for_each is an internal error in gdb scripts so a TypeError should be raised. The gdb.GdbError exception type is intended for user errors such as incorrect invocation. Drop the type assertion in list_for_each_entry because list_for_each isn't going to suddenly yield something else. Applies to both list and hlist Link: http://lkml.kernel.org/r/c1d3fd4db13d999a3ba57f5bbc1924862d824f61.1556881728.git.leonard.crestez@nxp.com Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by:
-
Leonard Crestez authored
Finding an individual clk_core requires walking the tree which can be quite complicated so add a helper for easy access. (gdb) print *(struct clk_scu*)$lx_clk_core_lookup("uart0_clk")->hw Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by: -
Leonard Crestez authored
Add an lx-clk-summary command which prints a subset of /sys/kernel/debug/clk/clk_summary. This can be used to examine hangs caused by clk not being enabled. Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by:
-
Leonard Crestez authored
This allows easily examining kernel hlists in python. Link: http://lkml.kernel.org/r/Message-ID : Signed-off-by:
-
Stephen Boyd authored
These scripts have some pep8 style warnings. Fix them up so that this directory is all pep8 clean. Link: http://lkml.kernel.org/r/20190329220844.38234-6-swboyd@chromium.org Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Nikolay Borisov <n.borisov.lkml@gmail.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jackie Liu <liuyun01@kylinos.cn> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by:
-
Stephen Boyd authored
Implement a command to print the timer list, much like how /proc/timer_list is implemented. This can be used to look at the pending timers on a crashed system. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-5-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-5-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
Implement gdb functions for rb_first(), rb_last(), rb_next(), and rb_prev(). These can be useful to iterate through the kernel's red-black trees. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-4-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-4-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
lx-configdump <file> dumps the contents of the gzipped .config to a text file when the config is included in the kernel with CONFIG_IKCONFIG. By default, the file written is called config.txt, but it can be any user supplied filename as well. If the kernel config is in a module (configs.ko), then it can be loaded along with symbols for the module loaded with 'lx-symbols' and then this command will still work. Obviously if you have the whole vmlinux then this can also be achieved with scripts/extract-ikconfig, but this gdb script can be useful to confirm that the memory contents of the config in memory and the vmlinux contents on disk match what is expected. [swboyd@chromium.org: v2] Link: http://lkml.kernel.org/r/20190329220844.38234-3-swboyd@chromium.org Link: http://lkml.kernel.org/r/20190325184522.260535-3-swboyd@chromium.org Signed-off-by:
-
Stephen Boyd authored
Patch series "gdb script for kconfig and timer list". This is a handful of changes to the kernel's gdb scripts to do some more debugging with kgdb. The first patch allows the vmlinux to be reloaded from where it was specified on the command line so that this set of scripts can be used from anywhere. The second patch adds a script to dump the config.gz to a file on the host debugging machine. The third patch adds some rb tree utilities and the last patch uses those rb tree walking utilities to dump out the contents of /proc/timer_list from a system under debug. This patch (of 5): If I run 'gdb <path/to/vmlinux>' and there's the vmlinux-gdb.py file there I can properly see symbols and use the lx commands provided by the GDB scripts. But once I run 'lx-symbols' at the command prompt, gdb reloads the vmlinux symbols assuming that this script was run from the directory that has vmlinux at the root. That isn't always true, but we could just look and see what symbols were already loaded and use that instead. Let's do that so this can work by being invoked anywhere. Link: http://lkml.kernel.org/r/20190325184522.260535-2-swboyd@chromium.org Signed-off-by:
-
- May 14, 2019
-
-
Masahiro Yamada authored
This is only used in confdata.c Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com>
-
Jacob Garber authored
Valid pathnames will never exceed PATH_MAX, but these file names are unsanitized and can cause buffer overflow if set incorrectly. Use snprintf to avoid this. This was flagged during a Coverity scan of the coreboot project, which also uses kconfig for its build system. Signed-off-by:
Jacob Garber <jgarber1@ualberta.ca> Signed-off-by:
-
Masahiro Yamada authored
conf_write_dep() has just one caller: conf_write_dep("include/config/auto.conf.cmd"); "name" always points to a valid string. Signed-off-by:
-
- May 12, 2019
-
-
Quentin Monnet authored
The script broke on parsing function prototype for bpf_strtoul(). This is because the last argument for the function is a pointer to an "unsigned long". The current version of the script only accepts "const" and "struct", but not "unsigned", at the beginning of argument types made of several words. One solution could be to add "unsigned" to the list, but the issue could come up again in the future (what about "long int"?). It turns out we do not need to have such restrictions on the words: so let's simply accept any series of words instead. Reported-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
-
- May 10, 2019
-
-
Chris Packham authored
Use gen_rtx_set instead of gen_rtx_SET. The former is a wrapper macro that handles the difference between GCC versions implementing the latter. This fixes the following error on my system with g++ 5.4.0 as the host compiler HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o scripts/gcc-plugins/arm_ssp_per_task_plugin.c:42:14: error: macro "gen_rtx_SET" requires 3 arguments, but only 2 given mask)), ^ scripts/gcc-plugins/arm_ssp_per_task_plugin.c: In function ‘unsigned int arm_pertask_ssp_rtl_execute()’: scripts/gcc-plugins/arm_ssp_per_task_plugin.c:39:20: error: ‘gen_rtx_SET’ was not declared in this scope emit_insn_before(gen_rtx_SET Signed-off-by:Chris Packham <chris.packham@alliedtelesis.co.nz> Fixes: 189af465 ("ARM: smp: add support for per-task stack canaries") Cc: stable@vger.kernel.org Tested-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Masahiro Yamada authored
With menuconfig / nconfig, users can input any file path from the "Save" menu, but it fails if the parent directory does not exist. Why not create the parent directory automatically. I think this is a user-friendly behavior. I changed the error messages in menuconfig / nconfig. "Nonexistent directory" is no longer the most likely reason of the failure. Perhaps, the user specified the existing directory, or attempted to write to the location without write permission. Signed-off-by: -
Masahiro Yamada authored
Kconfig updates the .config when it exits even if its content is exactly the same as before. Since its timestamp becomes newer than that of other build artifacts, additional processing is invoked, which is annoying. - syncconfig is invoked to update include/config/auto.conf, etc. - kernel/configs.o is recompiled if CONFIG_IKCONFIG is enabled, then vmlinux is relinked as well. If the .config is not changed at all, we do not have to even touch it. Just bail out showing "No change to .config". $ make allmodconfig scripts/kconfig/conf --allmodconfig Kconfig # # configuration written to .config # $ make allmodconfig scripts/kconfig/conf --allmodconfig Kconfig # # No change to .config # Reported-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masahiro Yamada authored
Currently, conf_write() can be called with a directory name instead of a file name. As far as I see, this can happen for menuconfig, nconfig, gconfig. If it is given with a directory path, conf_write() kindly appends getenv("KCONFIG_CONFIG"), but this ends up with hacky dir/basename handling, and screwed up in corner-cases like "what if KCONFIG_CONFIG is an absolute path?" as discussed before: https://patchwork.kernel.org/patch/9910037/ Since conf_write() is already messed up, I'd say "do not do it". Please pass a file path all the time. If a directory path is specified for the configuration output, conf_write() will simply error out. Now that the tmp file is created in the same directory as the .config, the previously reported "what if KCONFIG_CONFIG points to a different file system?" has been solved. Signed-off-by:
-
- May 09, 2019
-
-
Masahiro Yamada authored
There are still some trailing whitespaces under scripts/kconfig/tests/, but they must be kept. Otherwise, "make testconfig" would break. Signed-off-by:
-
- May 07, 2019
-
-
Alexey Gladkov authored
Problem: When a kernel module is compiled as a separate module, some important information about the kernel module is available via .modinfo section of the module. In contrast, when the kernel module is compiled into the kernel, that information is not available. Information about built-in modules is necessary in the following cases: 1. When it is necessary to find out what additional parameters can be passed to the kernel at boot time. 2. When you need to know which module names and their aliases are in the kernel. This is very useful for creating an initrd image. Proposal: The proposed patch does not remove .modinfo section with module information from the vmlinux at the build time and saves it into a separate file after kernel linking. So, the kernel does not increase in size and no additional information remains in it. Information is stored in the same format as in the separate modules (null-terminated string array). Because the .modinfo section is already exported with a separate modules, we are not creating a new API. It can be easily read in the userspace: $ tr '\0' '\n' < modules.builtin.modinfo ext4.softdep=pre: crc32c ext4.license=GPL ext4.description=Fourth Extended Filesystem ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others ext4.alias=fs-ext4 ext4.alias=ext3 ext4.alias=fs-ext3 ext4.alias=ext2 ext4.alias=fs-ext2 md_mod.alias=block-major-9-* md_mod.alias=md md_mod.description=MD RAID framework md_mod.license=GPL md_mod.parmtype=create_on_open:bool md_mod.parmtype=start_dirty_degraded:int ... Co-Developed-by:
Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> Signed-off-by:
Alexey Gladkov <gladkov.alexey@gmail.com> Acked-by:
Jessica Yu <jeyu@kernel.org> Signed-off-by:
-
- May 06, 2019
-
-
Andrey Ryabinin authored
The kernel the kernel is built with -Wvla for some time, so is not supposed to have any variable length arrays. Remove vla bounds checking from ubsan since it's useless now. Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
-
Andrii Nakryiko authored
When BTF generation is enabled through CONFIG_DEBUG_INFO_BTF, scripts/link-vmlinux.sh detects if pahole version is too old and gracefully continues build process, skipping BTF generation build step. But if pahole is not available, build will still fail. This patch adds check for whether pahole exists at all and bails out gracefully, if not. Cc: Alexei Starovoitov <ast@fb.com> Reported-by:
Andrii Nakryiko <andriin@fb.com> Signed-off-by:
-
- May 03, 2019
-
-
Masahiro Yamada authored
I thought this script was run via "make tags" etc. but some people run it directly. Prior to commit a9a49c2a ("kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build"), in such a usecase, "tree" was set empty since KBUILD_SRC is undefined. Now, "tree" is set to "${srctree}/", which is evaluated to "/". Fix it by taking into account the case where "srctree" is unset. Link: https://lkml.org/lkml/2019/4/19/501 Fixes: a9a49c2a ("kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build") Reported-by:
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
-
Daniel Dadap authored
recordmcount.pl uses a set of regular expressions to parse the output of objdump(1). However, if objdump(1) output is localized, it may not match the regular expressions, thereby preventing recordmcount.pl from parsing object files correctly. In order to allow recordmcount.pl to function correctly regardless of the current locale settings, set LANG=C when running objdump(1). LC_ALL is already unset in the top-level Makefile, so it is not necessary to also override that environment variable. Signed-off-by:
Daniel Dadap <ddadap@nvidia.com> Reviewed-by:
Robert Morell <rmorell@nvidia.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
As we keep migrating documents to ReST, we're starting to see more of such tags. Right now, all such tags are pointing to a documentation file, but regressions may be introduced. So, add a check for such kind of issues as well. Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
Mauro Carvalho Chehab authored
If one tries to run this script under linux-next, it would hit lots of false-positives, due to the tree merges that are stored under the Next/ directory. So, add a logic to ignore it. Signed-off-by:
-
- Apr 29, 2019
-
-
Paulo Alcantara authored
When compiling genheaders and mdp from a newer host kernel, the following error happens: In file included from scripts/selinux/genheaders/genheaders.c:18: ./security/selinux/include/classmap.h:238:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~ make[3]: *** [scripts/Makefile.host:107: scripts/selinux/genheaders/genheaders] Error 1 make[2]: *** [scripts/Makefile.build:599: scripts/selinux/genheaders] Error 2 make[1]: *** [scripts/Makefile.build:599: scripts/selinux] Error 2 make[1]: *** Waiting for unfinished jobs.... Instead of relying on the host definition, include linux/socket.h in classmap.h to have PF_MAX. Cc: stable@vger.kernel.org Signed-off-by:Paulo Alcantara <paulo@paulo.ac> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> [PM: manually merge in mdp.c, subject line tweaks] Signed-off-by:
Paul Moore <paul@paul-moore.com>
-
- Apr 28, 2019
-
-
Masahiro Yamada authored
scripts/mkutf8data is used only when regenerating utf8data.h, which never happens in the normal kernel build. However, it is irrespectively built if CONFIG_UNICODE is enabled. Moreover, there is no good reason for it to reside in the scripts/ directory since it is only used in fs/unicode/. Hence, move it from scripts/ to fs/unicode/. In some cases, we bypass build artifacts in the normal build. The conventional way to do so is to surround the code with ifdef REGENERATE_*. For example, - 7373f4f8 ("kbuild: add implicit rules for parser generation") - 6aaf49b4 ("crypto: arm,arm64 - Fix random regeneration of S_shipped") I rewrote the rule in a more kbuild'ish style. In the normal build, utf8data.h is just shipped from the check-in file. $ make [ snip ] SHIPPED fs/unicode/utf8data.h CC fs/unicode/utf8-norm.o CC fs/unicode/utf8-core.o CC fs/unicode/utf8-selftest.o AR fs/unicode/built-in.a If you want to generate utf8data.h based on UCD, put *.txt files into fs/unicode/, then pass REGENERATE_UTF8DATA=1 from the command line. The mkutf8data tool will be automatically compiled to generate the utf8data.h from the *.txt files. $ make REGENERATE_UTF8DATA=1 [ snip ] HOSTCC fs/unicode/mkutf8data GEN fs/unicode/utf8data.h CC fs/unicode/utf8-norm.o CC fs/unicode/utf8-core.o CC fs/unicode/utf8-selftest.o AR fs/unicode/built-in.a I renamed the check-in utf8data.h to utf8data.h_shipped so that this will work for the out-of-tree build. You can update it based on the latest UCD like this: $ make REGENERATE_UTF8DATA=1 fs/unicode/ $ cp fs/unicode/utf8data.h fs/unicode/utf8data.h_shipped Also, I added entries to .gitignore and dontdiff. Signed-off-by:
Theodore Ts'o <tytso@mit.edu>
-
- Apr 25, 2019
-
-
Olaf Weber authored
Remove the Hangul decompositions from the utf8data trie, and do algorithmic decomposition to calculate them on the fly. To store the decomposition the caller of utf8lookup()/utf8nlookup() must provide a 12-byte buffer, which is used to synthesize a leaf with the decomposition. This significantly reduces the size of the utf8data[] array. Changes made by Gabriel: Rebase to mainline Fix checkpatch errors Extract robustness fixes and merge back to original mkutf8data.c patch Regenerate utf8data.h Signed-off-by:
Olaf Weber <olaf@sgi.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Signed-off-by:
-
Gabriel Krisman Bertazi authored
The decomposition and casefolding of UTF-8 characters are described in a prefix tree in utf8data.h, which is a generate from the Unicode Character Database (UCD), published by the Unicode Consortium, and should not be edited by hand. The structures in utf8data.h are meant to be used for lookup operations by the unicode subsystem, when decoding a utf-8 string. mkutf8data.c is the source for a program that generates utf8data.h. It was written by Olaf Weber from SGI and originally proposed to be merged into Linux in 2014. The original proposal performed the compatibility decomposition, NFKD, but the current version was modified by me to do canonical decomposition, NFD, as suggested by the community. The changes from the original submission are: * Rebase to mainline. * Fix out-of-tree-build. * Update makefile to build 11.0.0 ucd files. * drop references to xfs. * Convert NFKD to NFD. * Merge back robustness fixes from original patch. Requested by Dave Chinner. The original submission is archived at: <https://linux-xfs.oss.sgi.narkive.com/Xx10wjVY/rfc-unicode-utf-8-support-for-xfs > The utf8data.h file can be regenerated using the instructions in fs/unicode/README.utf8data. - Notes on the update from 8.0.0 to 11.0: The structure of the ucd files and special cases have not experienced any changes between versions 8.0.0 and 11.0.0. 8.0.0 saw the addition of Cherokee LC characters, which is an interesting case for case-folding. The update is accompanied by new tests on the test_ucd module to catch specific cases. No changes to mkutf8data script were required for the updates. Signed-off-by:
-
- Apr 24, 2019
-
-
Kees Cook authored
This moves the stackleak plugin options to Kconfig.hardening's memory initialization menu. Signed-off-by:
Alexander Popov <alex.popov@linux.com> Acked-by:
-
Kees Cook authored
Right now kernel hardening options are scattered around various Kconfig files. This can be a central place to collect these kinds of options going forward. This is initially populated with the memory initialization options from the gcc-plugins. Signed-off-by:
-
- Apr 22, 2019
-
-
Guo Ren authored
Support dynamic ftrace including dynamic graph tracer. Gcc-csky with -pg will produce call site in every function prologue and we can use these call site to hook trace function. gcc with -pg origin call site: push lr jbsr _mcount nop32 nop32 If the (callee - caller)'s offset is in range of bsr instruction, we'll modify code with: push lr bsr _mcount nop32 nop32 Else if the (callee - caller)'s offset is out of bsr instrunction, we'll modify code with: push lr movih r26, ... ori r26, ... jsr r26 (r26 is reserved for jsr link reg in csky abiv2 spec.) Signed-off-by:Guo Ren <ren_guo@c-sky.com>
-
- Apr 19, 2019
-
-
Andrew Morton authored
patch(1) doesn't set the x bit on files. So if someone downloads and applies patch-4.21.xz, their kernel won't build. Fix that by executing /bin/sh. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Apr 16, 2019
-
-
Andrii Nakryiko authored
When CONFIG_DEBUG_INFO_BTF is enabled but available version of pahole is too old to support BTF generation, build script is supposed to emit warning and proceed with the build. Due to using exit instead of return from BASH function, existing handling code prematurely exits exit code 0, not completing some of the build steps. This patch fixes issue by correctly returning just from gen_btf() function only. Fixes: e83b9f55 ("kbuild: add ability to generate BTF type info for vmlinux") Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: Martin KaFai Lau <kafai@fb.com> Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
- Apr 11, 2019
-
-
Wiebe, Wladislav (Nokia - DE/Ulm) authored
Commit ea837f1c ("kbuild: make modpost processing configurable") was intended to give KBUILD_MODPOST_WARN flexibility to be configurable. Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is set which happens per default when building modules out of the tree. This change gives the opportunity to define module build behaving also in case of out of tree builds and default will become exit on error. Errors which can be detected by the build should be trapped out of the box there, unless somebody wants to notice broken stuff later at runtime. As this patch changes the default behaving from warning to error, users can consider to fix it for external module builds by: - providing module symbol table via KBUILD_EXTRA_SYMBOLS for modules which are dependent - OR getting old behaving back by passing KBUILD_MODPOST_WARN to the build Signed-off-by:
Wladislav Wiebe <wladislav.wiebe@nokia.com> Signed-off-by:
-
- Apr 09, 2019
-
-
Petr Vorel authored
Although it's not required for the build *conf-cfg.sh scripts to be executable (they're run by CONFIG_SHELL), let's be consistent with other scripts. Signed-off-by:
Petr Vorel <pvorel@suse.cz> Signed-off-by:
-
- Apr 06, 2019
-
-
Kirill Smelkov authored
fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock Commit 9c225f26 ("vfs: atomic f_pos accesses as per POSIX") added locking for file.f_pos access and in particular made concurrent read and write not possible - now both those functions take f_pos lock for the whole run, and so if e.g. a read is blocked waiting for data, write will deadlock waiting for that read to complete. This caused regression for stream-like files where previously read and write could run simultaneously, but after that patch could not do so anymore. See e.g. commit 581d21a2 ("xenbus: fix deadlock on writes to /proc/xen/xenbus") which fixes such regression for particular case of /proc/xen/xenbus. The patch that added f_pos lock in 2014 did so to guarantee POSIX thread safety for read/write/lseek and added the locking to file descriptors of all regular files. In 2014 that thread-safety problem was not new as it was already discussed earlier in 2006. However even though 2006'th version of Linus's patch was adding f_pos locking "only for files that are marked seekable with FMODE_LSEEK (thus avoiding the stream-like objects like pipes and sockets)", the 2014 version - the one that actually made it into the tree as 9c225f26 - is doing so irregardless of whether a file is seekable or not. See https://lore.kernel.org/lkml/53022DB1.4070805@gmail.com/ https://lwn.net/Articles/180387 https://lwn.net/Articles/180396 for historic context. The reason that it did so is, probably, that there are many files that are marked non-seekable, but e.g. their read implementation actually depends on knowing current position to correctly handle the read. Some examples: kernel/power/user.c snapshot_read fs/debugfs/file.c u32_array_read fs/fuse/control.c fuse_conn_waiting_read + ... drivers/hwmon/asus_atk0110.c atk_debugfs_ggrp_read arch/s390/hypfs/inode.c hypfs_read_iter ... Despite that, many nonseekable_open users implement read and write with pure stream semantics - they don't depend on passed ppos at all. And for those cases where read could wait for something inside, it creates a situation similar to xenbus - the write could be never made to go until read is done, and read is waiting for some, potentially external, event, for potentially unbounded time -> deadlock. Besides xenbus, there are 14 such places in the kernel that I've found with semantic patch (see below): drivers/xen/evtchn.c:667:8-24: ERROR: evtchn_fops: .read() can deadlock .write() drivers/isdn/capi/capi.c:963:8-24: ERROR: capi_fops: .read() can deadlock .write() drivers/input/evdev.c:527:1-17: ERROR: evdev_fops: .read() can deadlock .write() drivers/char/pcmcia/cm4000_cs.c:1685:7-23: ERROR: cm4000_fops: .read() can deadlock .write() net/rfkill/core.c:1146:8-24: ERROR: rfkill_fops: .read() can deadlock .write() drivers/s390/char/fs3270.c:488:1-17: ERROR: fs3270_fops: .read() can deadlock .write() drivers/usb/misc/ldusb.c:310:1-17: ERROR: ld_usb_fops: .read() can deadlock .write() drivers/hid/uhid.c:635:1-17: ERROR: uhid_fops: .read() can deadlock .write() net/batman-adv/icmp_socket.c:80:1-17: ERROR: batadv_fops: .read() can deadlock .write() drivers/media/rc/lirc_dev.c:198:1-17: ERROR: lirc_fops: .read() can deadlock .write() drivers/leds/uleds.c:77:1-17: ERROR: uleds_fops: .read() can deadlock .write() drivers/input/misc/uinput.c:400:1-17: ERROR: uinput_fops: .read() can deadlock .write() drivers/infiniband/core/user_mad.c:985:7-23: ERROR: umad_fops: .read() can deadlock .write() drivers/gnss/core.c:45:1-17: ERROR: gnss_fops: .read() can deadlock .write() In addition to the cases above another regression caused by f_pos locking is that now FUSE filesystems that implement open with FOPEN_NONSEEKABLE flag, can no longer implement bidirectional stream-like files - for the same reason as above e.g. read can deadlock write locking on file.f_pos in the kernel. FUSE's FOPEN_NONSEEKABLE was added in 2008 in a7c1b990 ("fuse: implement nonseekable open") to support OSSPD. OSSPD implements /dev/dsp in userspace with FOPEN_NONSEEKABLE flag, with corresponding read and write routines not depending on current position at all, and with both read and write being potentially blocking operations: See https://github.com/libfuse/osspd https://lwn.net/Articles/308445 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1406 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1438-L1477 https://github.com/libfuse/osspd/blob/14a9cff0/osspd.c#L1479-L1510 Corresponding libfuse example/test also describes FOPEN_NONSEEKABLE as "somewhat pipe-like files ..." with read handler not using offset. However that test implements only read without write and cannot exercise the deadlock scenario: https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L124-L131 https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L146-L163 https://github.com/libfuse/libfuse/blob/fuse-3.4.2-3-ga1bff7d/example/poll.c#L209-L216 I've actually hit the read vs write deadlock for real while implementing my FUSE filesystem where there is /head/watch file, for which open creates separate bidirectional socket-like stream in between filesystem and its user with both read and write being later performed simultaneously. And there it is semantically not easy to split the stream into two separate read-only and write-only channels: https://lab.nexedi.com/kirr/wendelin.core/blob/f13aa600/wcfs/wcfs.go#L88-169 Let's fix this regression. The plan is: 1. We can't change nonseekable_open to include &~FMODE_ATOMIC_POS - doing so would break many in-kernel nonseekable_open users which actually use ppos in read/write handlers. 2. Add stream_open() to kernel to open stream-like non-seekable file descriptors. Read and write on such file descriptors would never use nor change ppos. And with that property on stream-like files read and write will be running without taking f_pos lock - i.e. read and write could be running simultaneously. 3. With semantic patch search and convert to stream_open all in-kernel nonseekable_open users for which read and write actually do not depend on ppos and where there is no other methods in file_operations which assume @offset access. 4. Add FOPEN_STREAM to fs/fuse/ and open in-kernel file-descriptors via steam_open if that bit is present in filesystem open reply. It was tempting to change fs/fuse/ open handler to use stream_open instead of nonseekable_open on just FOPEN_NONSEEKABLE flags, but grepping through Debian codesearch shows users of FOPEN_NONSEEKABLE, and in particular GVFS which actually uses offset in its read and write handlers https://codesearch.debian.net/search?q=-%3Enonseekable+%3D https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1080 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1247-1346 https://gitlab.gnome.org/GNOME/gvfs/blob/1.40.0-6-gcbc54396/client/gvfsfusedaemon.c#L1399-1481 so if we would do such a change it will break a real user. 5. Add stream_open and FOPEN_STREAM handling to stable kernels starting from v3.14+ (the kernel where 9c225f26 first appeared). This will allow to patch OSSPD and other FUSE filesystems that provide stream-like files to return FOPEN_STREAM | FOPEN_NONSEEKABLE in their open handler and this way avoid the deadlock on all kernel versions. This should work because fs/fuse/ ignores unknown open flags returned from a filesystem and so passing FOPEN_STREAM to a kernel that is not aware of this flag cannot hurt. In turn the kernel that is not aware of FOPEN_STREAM will be < v3.14 where just FOPEN_NONSEEKABLE is sufficient to implement streams without read vs write deadlock. This patch adds stream_open, converts /proc/xen/xenbus to it and adds semantic patch to automatically locate in-kernel places that are either required to be converted due to read vs write deadlock, or that are just safe to be converted because read and write do not use ppos and there are no other funky methods in file_operations. Regarding semantic patch I've verified each generated change manually - that it is correct to convert - and each other nonseekable_open instance left - that it is either not correct to convert there, or that it is not converted due to current stream_open.cocci limitations. The script also does not convert files that should be valid to convert, but that currently have .llseek = noop_llseek or generic_file_llseek for unknown reason despite file being opened with nonseekable_open (e.g. drivers/input/mousedev.c) Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Yongzhi Pan <panyongzhi@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Juergen Gross <jgross@suse.com> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Tejun Heo <tj@kernel.org> Cc: Kirill Tkhai <ktkhai@virtuozzo.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Nikolaus Rath <Nikolaus@rath.org> Cc: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by:
Kirill Smelkov <kirr@nexedi.com> Signed-off-by:
-
- Apr 03, 2019
-
-
Peter Zijlstra authored
It is important that UACCESS regions are as small as possible; furthermore the UACCESS state is not scheduled, so doing anything that might directly call into the scheduler will cause random code to be ran with UACCESS enabled. Teach objtool too track UACCESS state and warn about any CALL made while UACCESS is enabled. This very much includes the __fentry__() and __preempt_schedule() calls. Note that exceptions _do_ save/restore the UACCESS state, and therefore they can drive preemption. This also means that all exception handlers must have an otherwise redundant UACCESS disable instruction; therefore ignore this warning for !STT_FUNC code (exception handlers are not normal functions). Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- Apr 02, 2019
-
-
Andrii Nakryiko authored
This patch adds new config option to trigger generation of BTF type information from DWARF debuginfo for vmlinux and kernel modules through pahole, which in turn relies on libbpf for btf_dedup() algorithm. The intent is to record compact type information of all types used inside kernel, including all the structs/unions/typedefs/etc. This enables BPF's compile-once-run-everywhere ([0]) approach, in which tracing programs that are inspecting kernel's internal data (e.g., struct task_struct) can be compiled on a system running some kernel version, but would be possible to run on other kernel versions (and configurations) without recompilation, even if the layout of structs changed and/or some of the fields were added, removed, or renamed. This is only possible if BPF loader can get kernel type info to adjust all the offsets correctly. This patch is a first time in this direction, making sure that BTF type info is part of Linux kernel image in non-loadable ELF section. BTF deduplication ([1]) algorithm typically provides 100x savings compared to DWARF data, so resulting .BTF section is not big as is typically about 2MB in size. [0] http://vger.kernel.org/lpc-bpf2018.html#session-2 [1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: Martin KaFai Lau <kafai@fb.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
-
