- 09 Sep, 2017 40 commits
-
-
Tomohiro Kusumi authored
The standard types unsigned int and unsigned long should be used for .compat_ioctl. autofs is the only fs using uing/ulong for this, and these are even the only uint/ulong in the entire autofs code. Drop unneeded long cast in return value of autofs_dev_ioctl_compat(). It's already long. Link: http://lkml.kernel.org/r/150285069709.4670.3884827966280147529.stgit@pluto.themaw.netSigned-off-by:
Tomohiro Kusumi <tkusumi@tuxera.com> Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Tomohiro Kusumi authored
This comment was correct when it was added in 8d7b48e0 ("autofs4: add miscellaneous device for ioctls") in 2008, but not after 4e44b685 "Get rid of path_lookup in autofs4" in 2009 which introduced find_autofs_mount(). Link: http://lkml.kernel.org/r/150285069148.4670.17959501481201077445.stgit@pluto.themaw.netSigned-off-by:
-
Tomohiro Kusumi authored
Use a macro which defines misc-dev ioctl parameter size (excluding a path beyond &path[0]) since it's been used to initialize and copy this structure ever since it first appeared in 8d7b48e0 in 2008. (or simply get rid of this if this is just unnecessary abstraction when all it needs is sizeof(struct autofs_dev_ioctl)) Edit: raven@themaw.net That's a good point but I'd prefer to keep the macro define. End edit: raven@themaw.net Link: http://lkml.kernel.org/r/150285068577.4670.2599968823770600622.stgit@pluto.themaw.netSigned-off-by:
-
Tomohiro Kusumi authored
Having header includes before any macro (without any dependency) simply looks normal. No reason to have these macros in between. Link: http://lkml.kernel.org/r/150285068011.4670.10271483982093996996.stgit@pluto.themaw.netSigned-off-by:
-
Tomohiro Kusumi authored
These are not used by either kernel or userspace, although AUTOFS_IOC_EXPIRE_DIRECT once seems to have been used by userspace in around 2006-2008, which was technically just an alias of the existing ioctl AUTOFS_IOC_EXPIRE_MULTI. ioctls for autofs are already complicated enough that they could be removed unless these are staying here to be able to compile userspace code of certain period of time from a decade ago. Edit: raven@themaw.net Yes, this is indeed very old and anything that still uses must be updated becuase it will be using broken functionality. End edit: raven@themaw.net Link: http://lkml.kernel.org/r/150285067347.4670.11494624644273072003.stgit@pluto.themaw.netSigned-off-by:
-
Ian Kent authored
Some of the autofs miscellaneous device ioctls need to be accessable to user space applications without CAP_SYS_ADMIN to get information about autofs mounts. Link: http://lkml.kernel.org/r/150216642517.11652.2338933266137331637.stgit@pluto.themaw.netSigned-off-by:
-
Ian Kent authored
The autofs miscellanous device ioctls that shouldn't require CAP_SYS_ADMIN need to be accessible to user space applications in order to be able to get information about autofs mounts. The module checks capabilities so the miscelaneous device should be fine with broad permissions. Link: http://lkml.kernel.org/r/150216641928.11652.7388977863125547969.stgit@pluto.themaw.netSigned-off-by:
-
Ian Kent authored
The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering of an automount by the call. But this flag is unconditionally cleared for all stat family system calls except statx(). stat family system calls have always triggered mount requests for the negative dentry case in follow_automount() which is intended but prevents the fstatat(2) and statx() AT_NO_AUTOMOUNT case from being handled. In order to handle the AT_NO_AUTOMOUNT for both system calls the negative dentry case in follow_automount() needs to be changed to return ENOENT when the LOOKUP_AUTOMOUNT flag is clear (and the other required flags are clear). AFAICT this change doesn't have any noticable side effects and may, in some use cases (although I didn't see it in testing) prevent unnecessary callbacks to the automount daemon. It's also possible that a stat family call has been made with a path that is in the process of being mounted by some other process. But stat family calls should return the automount state of the path as it is "now" so it shouldn't wait for mount completion. This is the same semantic as the positive dentry case already handled. Link: http://lkml.kernel.org/r/150216641255.11652.4204561328197919771.stgit@pluto.themaw.net Fixes: deccf497 ("Make stat/lstat/fstatat pass AT_NO_AUTOMOUNT to vfs_statx()") Signed-off-by:
-
Daniel Micay authored
Feed the boot command-line as to the /dev/random entropy pool Existing Android bootloaders usually pass data which may not be known by an external attacker on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS.... console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=sailfish user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff buildvariant=user veritykeyid=id:dfcb9db0089e5b3b4090a592415c28e1cb4545ab androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=yellow androidboot.veritymode=enforcing androidboot.keymaster=1 androidboot.serialno=FA6CE0305299 androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_samsung_ea8064tg_1080p_cmd:1:none:cfg:single_dsi androidboot.slot_suffix=_b fpsimd.fpsimd_settings=0 app_setting.use_app_setting=0 kernelflag=0x00000000 debugflag=0x00000000 androidboot.hardware.revision=PVT radioflag=0x00000000 radioflagex1=0x00000000 radioflagex2=0x00000000 cpumask=0x00000000 androidboot.hardware.ddr=4096MB,Hynix,LPDDR4 androidboot.ddrinfo=00000006 androidboot.ddrsize=4GB androidboot.hardware.color=GRA00 androidboot.hardware.ufs=32GB,Samsung androidboot.msm.hw_ver_id=268824801 androidboot.qf.st=2 androidboot.cid=11111111 androidboot.mid=G-2PW4100 androidboot.bootloader=8996-012001-1704121145 androidboot.oem_unlock_support=1 androidboot.fp_src=1 androidboot.htc.hrdump=detected androidboot.ramdump.opt=mem@2g:2g,mem@4g:2g androidboot.bootreason=reboot androidboot.ramdump_enable=0 ro root=/dev/dm-0 dm="system none ro,0 1 android-verity /dev/sda34" rootwait skip_initramfs init=/init androidboot.wificountrycode=US androidboot.boottime=1BLL:85,1BLE:669,2BLL:0,2BLE:1777,SW:6,KL:8136 Among other things, it contains a value unique to the device (androidboot.serialno=FA6CE0305299), unique to the OS builds for the device variant (veritykeyid=id:dfcb9db0089e5b3b4090a592415c28e1cb4545ab) and timings from the bootloader stages in milliseconds (androidboot.boottime=1BLL:85,1BLE:669,2BLL:0,2BLE:1777,SW:6,KL:8136). [tytso@mit.edu: changelog tweak] [labbott@redhat.com: line-wrapped command line] Link: http://lkml.kernel.org/r/20170816231458.2299-3-labbott@redhat.comSigned-off-by:Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Laura Abbott <labbott@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Laura Abbott <lauraa@codeaurora.org> Cc: Nick Kralevich <nnk@google.com> Signed-off-by:
-
Laura Abbott authored
Patch series "Command line randomness", v3. A series to add the kernel command line as a source of randomness. This patch (of 2): Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary initialization later to accommodate this. Link: http://lkml.kernel.org/r/20170816231458.2299-2-labbott@redhat.comSigned-off-by:
Laura Abbott <lauraa@codeaurora.org> Signed-off-by:
-
Markus Elfring authored
Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://lkml.kernel.org/r/f92aac79-b05e-321a-1a19-d38c7159ee9c@users.sourceforge.netSigned-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Jean Delvare authored
Unlike all other types, LONG_LINE, LONG_LINE_COMMENT and LONG_LINE_STRING are passed to WARN() through a variable. This causes the parser in list_types() to miss them and consequently they are not present in the output of --list-types. Additionally, types TYPO_SPELLING, FSF_MAILING_ADDRESS and AVOID_BUG are passed with a variable level, causing the parser to miss them too. So modify the regex to also catch these special cases. Link: http://lkml.kernel.org/r/20170902175610.7e4a7c9d@endymion Fixes: 3beb42ec ("checkpatch: add --list-types to show message types to show or ignore") Signed-off-by:
Jean Delvare <jdelvare@suse.de> Acked-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Jean Delvare authored
The variable name "$msg_type" is sometimes used to set the message type, and sometimes used to set the message level. This works but is kind of confusing. Use "$msg_level" in the latter case instead, to make the code clearer. Link: http://lkml.kernel.org/r/20170902175345.175db33a@endymionSigned-off-by:
-
Jean Delvare authored
Link: http://lkml.kernel.org/r/20170902175249.15bb77f2@endymionSigned-off-by:
-
Joe Perches authored
An if statement test like if ((foo == bar) && (baz != qux)) can arguably be better written without the parentheses as if (foo == bar && baz != qux) Add a test to find these cases. Link: http://lkml.kernel.org/r/dcd0561ddd0fa43c51a420d53b550d738bf42001.1502734458.git.joe@perches.comSigned-off-by:
-
Takashi Iwai authored
The sprint_oid() utility function doesn't properly check the buffer size that it causes that the warning in vsnprintf() be triggered. For example on v4.1 kernel: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2357 at lib/vsprintf.c:1867 vsnprintf+0x5a7/0x5c0() ... We can trigger this issue by injecting maliciously crafted x509 cert in DER format. Just using hex editor to change the length of OID to over the length of the SEQUENCE container. For example: 0:d=0 hl=4 l= 980 cons: SEQUENCE 4:d=1 hl=4 l= 700 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :9B47FAF791E7D1E3 24:d=2 hl=2 l= 13 cons: SEQUENCE 26:d=3 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption 37:d=3 hl=2 l= 0 prim: NULL 39:d=2 hl=2 l= 121 cons: SEQUENCE 41:d=3 hl=2 l= 22 cons: SET 43:d=4 hl=2 l= 20 cons: SEQUENCE <=== the SEQ length is 20 45:d=5 hl=2 l= 3 prim: OBJECT :organizationName <=== the original length is 3, change the length of OID to over the length of SEQUENCE Pawel Wieczorkiewicz reported this problem and Takashi Iwai provided patch to fix it by checking the bufsize in sprint_oid(). Link: http://lkml.kernel.org/r/20170903021646.2080-1-jlee@suse.comSigned-off-by:Takashi Iwai <tiwai@suse.de> Signed-off-by:
"Lee, Chun-Yi" <jlee@suse.com> Reported-by:
Pawel Wieczorkiewicz <pwieczorkiewicz@suse.com> Cc: David Howells <dhowells@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Pawel Wieczorkiewicz <pwieczorkiewicz@suse.com> Signed-off-by:
-
Eric Dumazet authored
__radix_tree_preload() only disables preemption if no error is returned. So we really need to make sure callers always check the return value. idr_preload() contract is to always disable preemption, so we need to add a missing preempt_disable() if an error happened. Similarly, ida_pre_get() only needs to call preempt_enable() in the case no error happened. Link: http://lkml.kernel.org/r/1504637190.15310.62.camel@edumazet-glaptop3.roam.corp.google.com Fixes: 0a835c4f ("Reimplement IDR and IDA using the radix tree") Fixes: 7ad3d4d8 ("ida: Move ida_bitmap to a percpu variable") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: <stable@vger.kernel.org> [4.11+] Signed-off-by:
-
Baoquan He authored
One line of code was commented out by c++ style comment for debugging, but forgot removing it. Clean it up. Link: http://lkml.kernel.org/r/1503312113-11843-1-git-send-email-bhe@redhat.comSigned-off-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
-
Dan Carpenter authored
This is mostly to keep the number of static checker warnings down so we can spot new bugs instead of them being drowned in noise. This function doesn't return normal kernel error codes but instead the return value is used to display exactly which memory failed. I chose -1 as hopefully that's a helpful thing to print. Link: http://lkml.kernel.org/r/20170817115420.uikisjvfmtrqkzjn@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Kees Cook <keescook@chromium.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
-
Davidlohr Bueso authored
As of commit 4cf0b354 ("rhashtable: avoid large lock-array allocations"), the default value for the locks multiplier was reduced from 128 to 32. Update the header file to reflect this. Link: http://lkml.kernel.org/r/20170815215401.30745-1-dave@stgolabs.netSigned-off-by:
Davidlohr Bueso <dbueso@suse.de> Cc: Florian Westphal <fw@strlen.de> Signed-off-by:
-
Yury Norov authored
The macro is the compile-time analogue of bitmap_from_u64() with the same purpose: convert the 64-bit number to the properly ordered pair of 32-bit parts, suitable for filling the bitmap in 32-bit BE environment. Use it to make test_bitmap_parselist() correct for 32-bit BE ABIs. Tested on BE mips/qemu. [akpm@linux-foundation.org: tweak code comment] Link: http://lkml.kernel.org/r/20170810172916.24144-1-ynorov@caviumnetworks.comSigned-off-by:
Yury Norov <ynorov@caviumnetworks.com> Cc: Noam Camus <noamca@mellanox.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
-
Yury Norov authored
Do some basic checks for bitmap_parselist(). [akpm@linux-foundation.org: fix printk warning] Link: http://lkml.kernel.org/r/20170807225438.16161-2-ynorov@caviumnetworks.comSigned-off-by:
-
Yury Norov authored
Current implementation of bitmap_parselist() uses a static variable to save local state while setting bits in the bitmap. It is obviously wrong if we assume execution in multiprocessor environment. Fortunately, it's possible to rewrite this portion of code to avoid using the static variable. It is also possible to set bits in the mask per-range with bitmap_set(), not per-bit, as it is implemented now, with set_bit(); which is way faster. The important side effect of this change is that setting bits in this function from now is not per-bit atomic and less memory-ordered. This is because set_bit() guarantees the order of memory accesses, while bitmap_set() does not. I think that it is the advantage of the new approach, because the bitmap_parselist() is intended to initialise bit arrays, and user should protect the whole bitmap during initialisation if needed. So protecting individual bits looks expensive and useless. Also, other range-oriented functions in lib/bitmap.c don't worry much about atomicity. With all that, setting 2k bits in map with the pattern like 0-2047:128/256 becomes ~50 times faster after applying the patch in my testing environment (arm64 hosted on qemu). The second patch of the series adds the test for bitmap_parselist(). It's not intended to cover all tricky cases, just to make sure that I didn't screw up during rework. Link: http://lkml.kernel.org/r/20170807225438.16161-1-ynorov@caviumnetworks.comSigned-off-by:
-
Florian Fainelli authored
Add a test module that allows testing that CONFIG_DEBUG_VIRTUAL works correctly, at least that it can catch invalid calls to virt_to_phys() against the non-linear kernel virtual address map. Link: http://lkml.kernel.org/r/20170808164035.26725-1-f.fainelli@gmail.comSigned-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Andy Shevchenko authored
In some cases caller would like to use error code directly without shadowing. -EINVAL feels a rightful code to return in case of error in hex2bin(). Link: http://lkml.kernel.org/r/20170731135510.68023-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Davidlohr Bueso authored
For the same reasons we already cache the leftmost pointer, apply the same optimization for rb_last() calls. Users must explicitly do this as rb_root_cached only deals with the smallest node. [dave@stgolabs.net: brain fart #1] Link: http://lkml.kernel.org/r/20170731155955.GD21328@linux-80c1.suse Link: http://lkml.kernel.org/r/20170719014603.19029-18-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
Such that we can optimize __mem_cgroup_largest_soft_limit_node(). The only overhead is the extra footprint for the cached pointer, but this should not be an issue for mem_cgroup_tree_per_node. [dave@stgolabs.net: brain fart #2] Link: http://lkml.kernel.org/r/20170731160114.GE21328@linux-80c1.suse Link: http://lkml.kernel.org/r/20170719014603.19029-17-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
... such that we can avoid the tree walks to get the node with the smallest key. Semantically the same, as the previously used rb_first(), but O(1). The main overhead is the extra footprint for the cached rb_node pointer, which should not matter for epoll. Link: http://lkml.kernel.org/r/20170719014603.19029-15-dave@stgolabs.netSigned-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
-
Davidlohr Bueso authored
... such that we can avoid the tree walks to get the node with the smallest key. Semantically the same, as the previously used rb_first(), but O(1). The main overhead is the extra footprint for the cached rb_node pointer, which should not matter for procfs. Link: http://lkml.kernel.org/r/20170719014603.19029-14-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
interval_tree.h _is_ the generic flavor. Link: http://lkml.kernel.org/r/20170719014603.19029-13-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
Allow interval trees to quickly check for overlaps to avoid unnecesary tree lookups in interval_tree_iter_first(). As of this patch, all interval tree flavors will require using a 'rb_root_cached' such that we can have the leftmost node easily available. While most users will make use of this feature, those with special functions (in addition to the generic insert, delete, search calls) will avoid using the cached option as they can do funky things with insertions -- for example, vma_interval_tree_insert_after(). [jglisse@redhat.com: fix deadlock from typo vm_lock_anon_vma()] Link: http://lkml.kernel.org/r/20170808225719.20723-1-jglisse@redhat.com Link: http://lkml.kernel.org/r/20170719014603.19029-12-dave@stgolabs.netSigned-off-by:
Jérôme Glisse <jglisse@redhat.com> Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Doug Ledford <dledford@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Jason Wang <jasowang@redhat.com> Cc: Christian Benvenuti <benve@cisco.com> Signed-off-by:
-
Davidlohr Bueso authored
... with the generic rbtree flavor instead. No changes in semantics whatsoever. Link: http://lkml.kernel.org/r/20170719014603.19029-11-dave@stgolabs.netSigned-off-by:
Jan Kara <jack@suse.cz> Acked-by:
-
Davidlohr Bueso authored
... with the generic rbtree flavor instead. No changes in semantics whatsoever. Link: http://lkml.kernel.org/r/20170719014603.19029-10-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
... with the generic rbtree flavor instead. No changes in semantics whatsoever. Link: http://lkml.kernel.org/r/20170719014603.19029-9-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
... with the generic rbtree flavor instead. No changes in semantics whatsoever. Link: http://lkml.kernel.org/r/20170719014603.19029-8-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
We can work with a single rb_root_cached root to test both cached and non-cached rbtrees. In addition, also add a test to measure latencies between rb_first and its fast counterpart. Link: http://lkml.kernel.org/r/20170719014603.19029-7-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
This adds a second test for regular rb-tree testing in that there is no need to repeat it for the augmented flavor. Link: http://lkml.kernel.org/r/20170719014603.19029-6-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
Allows for more flexible debugging. Link: http://lkml.kernel.org/r/20170719014603.19029-5-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
While overall the code is very nicely commented, it might not be immediately obvious from the diagrams what is going on. Add a very brief summary of each case. Opposite cases where the node is the left child are left untouched. Link: http://lkml.kernel.org/r/20170719014603.19029-4-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
The only times the nil-parent (root node) condition is true is when the node is the first in the tree, or after fixing rbtree rule #4 and the case 1 rebalancing made the node the root. Such conditions do not apply most of the time: (i) The common case in an rbtree is to have more than a single node, so this is only true for the first rb_insert(). (ii) While there is a chance only one first rotation is needed, cases where the node's uncle is black (cases 2,3) are more common as we can have the following scenarios during the rotation looping: case1 only, case1+1, case2+3, case1+2+3, case3 only, etc. This patch, therefore, adds an unlikely() optimization to this conditional. When profiling with CONFIG_PROFILE_ANNOTATED_BRANCHES, a kernel build shows that the incorrect rate is less than 15%, and for workloads that involve insert mostly trees overtime tend to have less than 2% incorrect rate. Link: http://lkml.kernel.org/r/20170719014603.19029-3-dave@stgolabs.netSigned-off-by:
-
