aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* lib/vsprintf.c: improve sanity check in vsnprintf()Rasmus Villemoes2017-04-111-1/+1
| | | | | | | | | | | | | On 64 bit, size may very well be huge even if bit 31 happens to be 0. Somehow it doesn't feel right that one can pass a 5 GiB buffer but not a 3 GiB one. So cap at INT_MAX as was probably the intention all along. This is also the made-up value passed by sprintf and vsprintf. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* lib/vsprintf.c: eliminate some branchesRasmus Villemoes2017-04-111-19/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since FORMAT_TYPE_INT is simply 1 more than FORMAT_TYPE_UINT, and similarly for BYTE/UBYTE, SHORT/USHORT, LONG/ULONG, we can eliminate a few instructions by making SIGN have the value 1 instead of 2, and then use arithmetic instead of branches for computing the right spec->type. It's a little hacky, but certainly in the same spirit as SMALL needing to have the value 0x20. For example for the spec->qualifier == 'l' case, gcc now generates 75e: 0f b6 53 01 movzbl 0x1(%rbx),%edx 762: 83 e2 01 and $0x1,%edx 765: 83 c2 09 add $0x9,%edx 768: 88 13 mov %dl,(%rbx) instead of 763: 0f b6 53 01 movzbl 0x1(%rbx),%edx 767: 83 e2 02 and $0x2,%edx 76a: 80 fa 01 cmp $0x1,%dl 76d: 19 d2 sbb %edx,%edx 76f: 83 c2 0a add $0xa,%edx 772: 88 13 mov %dl,(%rbx) Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* lib/vsprintf.c: fix comparison to boolFabian Frederick2017-04-111-2/+2
| | | | | | | | | | Fixing 2 coccinelle warnings: lib/vsprintf.c:2350:2-9: WARNING: Assignment of bool to 0/1 lib/vsprintf.c:2389:3-10: WARNING: Assignment of bool to 0/1 Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* vsprintf: Add support for IORESOURCE_UNSET in %pRBjorn Helgaas2017-04-112-5/+10
| | | | | | | | | | | | | | | | | | | Sometimes we have a struct resource where we know the type (MEM/IO/etc.) and the size, but we haven't assigned address space for it. The IORESOURCE_UNSET flag is a way to indicate this situation. For these "unset" resources, the start address is meaningless, so print only the size, e.g., - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit] + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit] For %pr (printing with raw flags), we still print the address range, because %pr is mostly used for debugging anyway. Thanks to Fengguang Wu <fengguang.wu@intel.com> for suggesting resource_size(). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
* vsprintf: add %pad extension for dma_addr_t useJoe Perches2017-04-112-8/+36
| | | | | | | | | | | | | | | | | | | dma_addr_t's can be either u32 or u64 depending on a CONFIG option. There are a few hundred dma_addr_t's printed via either cast to unsigned long long, unsigned long or no cast at all. Add %pad to be able to emit them without the cast. Update Documentation/printk-formats.txt too. Signed-off-by: Joe Perches <joe@perches.com> Cc: "Shevchenko, Andriy" <andriy.shevchenko@intel.com> Cc: Rob Landley <rob@landley.net> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* lib/vsprintf.c: document formats for dentry and struct fileOlof Johansson2017-04-111-0/+2
| | | | | | | | | | Looks like these were added to Documentation/printk-formats.txt but not the in-file table. Signed-off-by: Olof Johansson <olof@lixom.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* add formats for dentry/file pathnamesAl Viro2017-04-112-0/+91
| | | | | | | | New formats: %p[dD][234]?. The next pointer is interpreted as struct dentry * or struct file * resp. ('d' => dentry, 'D' => file) and the last component(s) of pathname are printed (%pd => just the last one, %pd2 => the last two, etc.) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* rcu: Check both root and current rcu_node when setting up future grace periodPranith Kumar2017-04-111-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rcu_start_future_gp() function checks the current rcu_node's ->gpnum and ->completed twice, once without ACCESS_ONCE() and once with it. Which is pointless because we hold that rcu_node's ->lock at that point. The intent was to check the current rcu_node structure and the root rcu_node structure, the latter locklessly with ACCESS_ONCE(). This commit therefore makes that change. The reason that it is safe to locklessly check the root rcu_nodes's ->gpnum and ->completed fields is that we hold the current rcu_node's ->lock, which constrains the root rcu_node's ability to change its ->gpnum and ->completed fields. Of course, if there is a single rcu_node structure, then rnp_root==rnp, and holding the lock prevents all changes. If there is more than one rcu_node structure, then the code updates the fields in the following order: 1. Increment rnp_root->gpnum to start new grace period. 2. Increment rnp->gpnum to initialize the current rcu_node, continuing initialization for the new grace period. 3. Increment rnp_root->completed to end the current grace period. 4. Increment rnp->completed to continue cleaning up after the old grace period. So there are four possible combinations of relative values of these four fields: N N N N: RCU idle, new grace period must be initiated. Although rnp_root->gpnum might be incremented immediately after we check, that will just result in unnecessary work. The grace period already started, and we try to start it. N+1 N N N: RCU grace period just started. No further change is possible because we hold rnp->lock, so the checks of rnp_root->gpnum and rnp_root->completed are stable. We know that our request for a future grace period will be seen during grace-period cleanup. N+1 N N+1 N: RCU grace period is ongoing. Because rnp->gpnum is different than rnp->completed, we won't even look at rnp_root->gpnum and rnp_root->completed, so the possible concurrent change to rnp_root->completed does not matter. We know that our request for a future grace period will be seen during grace-period cleanup, which cannot pass this rcu_node because we hold its ->lock. N+1 N+1 N+1 N: RCU grace period has ended, but not yet been cleaned up. Because rnp->gpnum is different than rnp->completed, we won't look at rnp_root->gpnum and rnp_root->completed, so the possible concurrent change to rnp_root->completed does not matter. We know that our request for a future grace period will be seen during grace-period cleanup, which cannot pass this rcu_node because we hold its ->lock. Therefore, despite initial appearances, the lockless check is safe. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> [ paulmck: Update comment to say why the lockless check is safe. ] Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 48bd8e9b82a750b983823f391c67e70553757afa Signed-off-by: Kishan Kumar <kishank@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Change-Id: I2ce0b10e34e5183ffcd6810cada86962ecf85d8f
* rcu: Update cpu_needs_another_gp() for futures from non-NOCB CPUsPaul E. McKenney2017-04-113-29/+29
| | | | | | | | | | | | | | | | | | | In the old days, the only source of requests for future grace periods was NOCB CPUs. This has changed: CPUs routinely post requests for future grace periods in order to promote power efficiency and reduce OS jitter with minimal impact on grace-period latency. This commit therefore updates cpu_needs_another_gp() to invoke rcu_future_needs_gp() instead of rcu_nocb_needs_gp(). The latter is no longer used, so is now removed. This commit also adds tracing for the irq_work_queue() wakeup case. Change-Id: Ifafd85017d358804b0b7a757ef68c1aebf435a99 Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 365187fbc04fd55766bf6a94e37e558505bf480a Signed-off-by: Kishan Kumar <kishank@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
* rcu: Protect ->gp_flags accesses with ACCESS_ONCE()Paul E. McKenney2017-04-111-7/+6
| | | | | | | | | | | | | | | | | A number of ->gp_flags accesses don't have ACCESS_ONCE(), but all of the can race against other loads or stores. This commit therefore applies ACCESS_ONCE() to the unprotected ->gp_flags accesses. Reported-by: Alexey Roytman <alexey.roytman@oracle.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 91dc95427a0d30ac2c58d6e943c7f40a3f25d908 [kishank@codeaurora.org resolve trivial conflicts] Signed-off-by: Kishan Kumar <kishank@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Change-Id: I2ed581b545fb9c93468658fa621e71c091ec250b
* rcu: Prevent spurious-wakeup DoS attack on rcu_gp_kthread()Paul E. McKenney2017-04-111-3/+8
| | | | | | | | | | | | | | | | | | | | | Spurious wakeups in the force-quiescent-state loop in rcu_gp_kthread() cause the timeout to be recalculated, which would prevent rcu_gp_fqs() from ever being called. This would in turn would prevent the grace period from ever ending for as long as there was at least one CPU in an extended quiescent state that had not yet passed through a quiescent state. This commit therefore avoids recalculating the timeout unless the previous pass's call to wait_event_interruptible_timeout() actually did time out, thus preventing the above scenario. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 88d6df612cc3c99f56cc18461fcc531c3a145544 [kishank@codeaurora.org resolve trivial conflicts] Signed-off-by: Kishan Kumar <kishank@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Change-Id: I43f22a80d4334ea5a7105a6da6f929239df76a11
* rcu: Avoid redundant grace-period kthread wakeupsPaul E. McKenney2017-04-111-3/+5
| | | | | | | | | | | | | | | | | | | | When setting up an in-the-future "advanced" grace period, the code needs to wake up the relevant grace-period kthread, which it currently does unconditionally. However, this results in needless wakeups in the case where the advanced grace period is being set up by the grace-period kthread itself, which is a non-uncommon situation. This commit therefore checks to see if the running thread is the grace-period kthread, and avoids doing the irq_work_queue()-mediated wakeup in that case. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 1eafd31c640d6799c63136246a59d608bed93c74 [kishank@codeaurora.org resolve trivial conflicts] Signed-off-by: Kishan Kumar <kishank@codeaurora.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Change-Id: I1fdcf6664fdc7dce188488f05f33931e3614c853
* rcu: Switch callers from rcu_process_gp_end() to note_gp_changes()Paul E. McKenney2017-04-111-28/+3
| | | | | | | | | | | | | Because note_gp_changes() now incorporates rcu_process_gp_end() function, this commit switches to the former and eliminates the latter. In addition, this commit changes external calls from __rcu_process_gp_end() to __note_gp_changes(). Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 470716fc043aba2fea832334e58d5cd5d82288a3 Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* rcu: Flag lockless access to ->gp_flags with ACCESS_ONCE()Paul E. McKenney2017-04-111-1/+1
| | | | | | | | | | | | | This commit applies ACCESS_ONCE() to an outside-of-lock access to ->gp_flags. Although it is hard to imagine any sane compiler messing this particular case up, the documentation benefits are substantial. Plus the definition of "sane compiler" grows ever looser. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 591c6d1710cd73824057d08eda302cf2a7cfd18a [kishank@codeaurora.org resolve trivial conflicts] Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* rcu: Merge __rcu_process_gp_end() into __note_gp_changes()Paul E. McKenney2017-04-111-42/+6
| | | | | | | | | | | This commit eliminates some duplicated code by merging __rcu_process_gp_end() into __note_gp_changes(). Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: ba9fbe955f026780e6b27c279dba7c86dfdcb7d5 Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* rcu: Rename note_new_gpnum() to note_gp_changes()Paul E. McKenney2017-04-111-6/+7
| | | | | | | | | | | | Because note_new_gpnum() now also checks for the ends of old grace periods, this commit changes its name to note_gp_changes(). Later commits will merge rcu_process_gp_end() into note_gp_changes(). Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: d34ea3221a0f34ed42eadabf054604bbcc7ecd27 Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* rcu: Make __note_new_gpnum() check for ends of prior grace periodsPaul E. McKenney2017-04-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | The current implementation can detect the beginning of a new grace period before noting the end of a previous grace period. Although the current implementation correctly handles this sort of nonsense, it would be good to reduce RCU's state space by making such nonsense unnecessary, which is now possible thanks to the fact that RCU's callback groups are now numbered. This commit therefore makes __note_new_gpnum() invoke __rcu_process_gp_end() in order to note the ends of prior grace periods before noting the beginnings of new grace periods. Of course, this now means that note_new_gpnum() notes both the beginnings and ends of grace periods, and could therefore be used in place of rcu_process_gp_end(). But that is a job for later commits. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 398ebe6000c16135d12ce2ff64318f306ffb20b0 Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* rcu: Move code to apply callback-numbering simplificationsPaul E. McKenney2017-04-111-59/+59
| | | | | | | | | | | | The addition of callback numbering allows combining the detection of the ends of old grace periods and the beginnings of new grace periods. This commit moves code to set the stage for this combining. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 6eaef633d77f50f031dd355ff5f91aaa1aaf9885 Signed-off-by: Kishan Kumar <kishank@codeaurora.org>
* net: delete remnants of NL80211_FASTSCANMister Oyster2017-04-111-7/+0
|
* BACKPORT: smarter propagate_mnt()Al Viro2017-04-114-77/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current mainline has copies propagated to *all* nodes, then tears down the copies we made for nodes that do not contain counterparts of the desired mountpoint. That sets the right propagation graph for the copies (at teardown time we move the slaves of removed node to a surviving peer or directly to master), but we end up paying a fairly steep price in useless allocations. It's fairly easy to create a situation where N calls of mount(2) create exactly N bindings, with O(N^2) vfsmounts allocated and freed in process. Fortunately, it is possible to avoid those allocations/freeings. The trick is to create copies in the right order and find which one would've eventually become a master with the current algorithm. It turns out to be possible in O(nodes getting propagation) time and with no extra allocations at all. One part is that we need to make sure that eventual master will be created before its slaves, so we need to walk the propagation tree in a different order - by peer groups. And iterate through the peers before dealing with the next group. Another thing is finding the (earlier) copy that will be a master of one we are about to create; to do that we are (temporary) marking the masters of mountpoints we are attaching the copies to. Either we are in a peer of the last mountpoint we'd dealt with, or we have the following situation: we are attaching to mountpoint M, the last copy S_0 had been attached to M_0 and there are sequences S_0...S_n, M_0...M_n such that S_{i+1} is a master of S_{i}, S_{i} mounted on M{i} and we need to create a slave of the first S_{k} such that M is getting propagation from M_{k}. It means that the master of M_{k} will be among the sequence of masters of M. On the other hand, the nearest marked node in that sequence will either be the master of M_{k} or the master of M_{k-1} (the latter - in the case if M_{k-1} is a slave of something M gets propagation from, but in a wrong peer group). So we go through the sequence of masters of M until we find a marked one (P). Let N be the one before it. Then we go through the sequence of masters of S_0 until we find one (say, S) mounted on a node D that has P as master and check if D is a peer of N. If it is, S will be the master of new copy, if not - the master of S will be. That's it for the hard part; the rest is fairly simple. Iterator is in next_group(), handling of one prospective mountpoint is propagate_one(). It seems to survive all tests and gives a noticably better performance than the current mainline for setups that are seriously using shared subtrees. Change-Id: I45648e8a405544f768c5956711bdbdf509e2705a Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* BACKPORT: don't bother with propagate_mnt() unless the target is sharedAl Viro2017-04-111-10/+7
| | | | | | | | | | If the dest_mnt is not shared, propagate_mnt() does nothing - there's no mounts to propagate to and thus no copies to create. Might as well don't bother calling it in that case. Change-Id: Id94af8ad288bf9bfc6ffb5570562bbc2dc2e0d87 Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* block: remove request ref_countChristoph Hellwig2017-04-113-12/+0
| | | | | | | | | | This reference count has been around since before git history, but the only place where it's used is in blk_execute_rq, and ther it is entirely useless as it is incremented before submitting the request and decremented in the end_io handler before waking up the submitter thread. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* block: make rq->cmd_flags be 64-bitJens Axboe2017-04-115-41/+41
| | | | | | | | We have officially run out of flags in a 32-bit space. Extend it to 64-bit even on 32-bit archs. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* block: Convert kmalloc_node(...GFP_ZERO...) to kzalloc_node(...)Joe Perches2017-04-114-5/+4
| | | | | | | Use the helper function instead of __GFP_ZERO. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
* random: initialize the non-blocking pool via add_hwgenerator_randomness()Theodore Ts'o2017-04-111-5/+11
| | | | | | | | | If we have a hardware RNG and are using the in-kernel rngd, we should use this to initialize the non-blocking pool so that getrandom(2) doesn't block unnecessarily. Cc: stable@kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* Bluetooth: Release locks before sleeping for L2CAP socket shutdownRupesh Tatiya2017-04-112-2/+36
| | | | | | | | | | | | If there are unacknowledged frames during an ongoing L2CAP transfer and if socket is shutdown, it will result in deadlock as locks are not released before going to sleep. The L2CAP receive thread will be waiting on locks to update unacknowledged frame count, whereas socket shutdown thread will be sleeping till unacknowledged count becomes 0 resulting in deadlock. Signed-off-by: Rupesh Tatiya <rtatiya@codeaurora.org>
* Bluetooth: Return the correct address type for L2CAP socketsMarcel Holtmann2017-04-113-2/+33
| | | | | | | | | | | | | | | | | | | The L2CAP sockets can use BR/EDR public, LE public and LE random addresses for various combinations of source and destination devices. So make sure that getsockname(), getpeername() and accept() return the correct address type. For this the address type of the source and destination is stored with the L2CAP channel information. The stored address type is not the one specific for the HCI protocol. It is the address type used for the L2CAP sockets and the management interface. The underlying HCI connections store the HCI address type. If needed, it gets converted to the socket address type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Kamal Negi <kamaln@codeaurora.org>
* Bluetooth: Store source address of HCI connectionsMarcel Holtmann2017-04-112-0/+2
| | | | | | | | | | | | | | The source addressed was based on the public address of the HCI device, but with LE connections this not always the case. For example single mode LE-only controllers would use a static random address. And this address is configured by userspace. To not complicate the lookup of what kind of address is in use, store the correct source address for each HCI connection. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Kamal Negi <kamaln@codeaurora.org>
* Bluetooth: Store the source address type of LE connectionsMarcel Holtmann2017-04-112-0/+10
| | | | | | | | | | | When establishing LE connections, it is possible to use a public address (if available) or a random address. The type of address is only known when creating connections, so make sure it is stored in hci_conn structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Kamal Negi <kamaln@codeaurora.org>
* bluetooth: Initiate authentication before sending l2cap connect response.Kamal Negi2017-04-111-0/+2
| | | | | | | | | | Check and inititiate, if necessary, authentication procedure for the connection before sending l2cap connect response. For legacy devices, this pacth will initiate authentication procedure in the first l2cap connect request as legacy do not initiate authentication after connection. Signed-off-by: Kamal Negi <kamaln@codeaurora.org>
* Bluetooth: remove unnecessary check on BT_CLOSED socks during acceptRupesh Tatiya2017-04-112-8/+12
| | | | | | | | | | | BT_CLOSED sockets are unlinked from teardown callback. Trying to unlink such sockets from bt_accept_dequeue may lead to NULL dereference as teardown callback does not hold lock for parent sock. bt_accept_unlink may be called from two threads, resulting in incorrect socket ref count. Return if parent is NULL. Signed-off-by: Rupesh Tatiya <rtatiya@codeaurora.org>
* Bluetooth: Fix redundant encryption when receiving Security RequestJohan Hedberg2017-04-111-1/+21
| | | | | | | | | | | | | If we're already encrypted with a good enough LTK we should just ignore an incoming SMP Security Request. The code was already taking care of this in the smp_conn_security function before calling smp_ltk_encrypt but failed to do the same in smp_cmd_security_req. This patch fixes the issue by moving up the smp_sufficient_security function and using it in the Security Request handler before trying to request encryption. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Rupesh Tatiya <rtatiya@codeaurora.org>
* kernel: Fix few typosMasanari Iida2017-04-117-8/+8
| | | | | | | | | | This patch fix spelling typo found in DocBook/kernel-api.xml. It is because the file is generated from the source comments, I have to fix the comments in source codes. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Optimized task_sched_runtime for upto 20% increase in PerformanceShoaib05972017-04-111-0/+14
|
* random: Remove kernel blocking APIHerbert Xu2017-04-112-13/+0
| | | | | | | This patch removes the kernel blocking API as it has been completely replaced by the callback API. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Add callback API for random pool readinessHerbert Xu2017-04-112-0/+87
| | | | | | | | | | | | | | | | | The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with a callback API instead. The callback is invoked potentially from interrupt context so the user needs to schedule their own work thread if necessary. In addition to adding callbacks, they can also be removed as otherwise this opens up a way for user-space to allocate kernel memory with no bound (by opening algif_rng descriptors and then closing them). Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Blocking API for accessing nonblocking_poolStephan Mueller2017-04-112-0/+13
| | | | | | | | | | | | The added API calls provide a synchronous function call get_blocking_random_bytes where the caller is blocked until the nonblocking_pool is initialized. CC: Andreas Steffen <andreas.steffen@strongswan.org> CC: Theodore Ts'o <tytso@mit.edu> CC: Sandy Harris <sandyinchina@gmail.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* random: Wake up all getrandom(2) callers when pool is readyHerbert Xu2017-04-111-1/+1
| | | | | | | | | | If more than one application invokes getrandom(2) before the pool is ready, then all bar one will be stuck forever because we use wake_up_interruptible which wakes up a single task. This patch replaces it with wake_up_all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* BACKPORT: aio: mark AIO pseudo-fs noexecNick Desaulniers2017-04-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This ensures that do_mmap() won't implicitly make AIO memory mappings executable if the READ_IMPLIES_EXEC personality flag is set. Such behavior is problematic because the security_mmap_file LSM hook doesn't catch this case, potentially permitting an attacker to bypass a W^X policy enforced by SELinux. I have tested the patch on my machine. To test the behavior, compile and run this: #define _GNU_SOURCE #include <unistd.h> #include <sys/personality.h> #include <linux/aio_abi.h> #include <err.h> #include <stdlib.h> #include <stdio.h> #include <sys/syscall.h> int main(void) { personality(READ_IMPLIES_EXEC); aio_context_t ctx = 0; if (syscall(__NR_io_setup, 1, &ctx)) err(1, "io_setup"); char cmd[1000]; sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'", (int)getpid()); system(cmd); return 0; } In the output, "rw-s" is good, "rwxs" is bad. Signed-off-by: Jann Horn <jann@thejh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 22f6b4d34fcf039c63a94e7670e0da24f8575a5a) Bug: 31711619 Change-Id: I9f2872703bef240d6b82320c744529459bb076dc
* defconfig: regen for 3.10.105Mister Oyster2017-04-111-24/+29
|
* Linux 3.10.105Willy Tarreau2017-04-111-1/+1
|
* crypto: gcm - Fix IV buffer size in crypto_gcm_setkeyOndrej Mosnáček2017-04-111-1/+1
| | | | | | | | | | | | | | | commit 50d2e6dc1f83db0563c7d6603967bf9585ce934b upstream. The cipher block size for GCM is 16 bytes, and thus the CTR transform used in crypto_gcm_setkey() will also expect a 16-byte IV. However, the code currently reserves only 8 bytes for the IV, causing an out-of-bounds access in the CTR transform. This patch fixes the issue by setting the size of the IV buffer to 16 bytes. Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers") Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: skcipher - Fix blkcipher walk OOM crashHerbert Xu2017-04-111-1/+2
| | | | | | | | | | | | | | | | | | | | | commit acdb04d0b36769b3e05990c488dc74d8b7ac8060 upstream. When we need to allocate a temporary blkcipher_walk_next and it fails, the code is supposed to take the slow path of processing the data block by block. However, due to an unrelated change we instead end up dereferencing the NULL pointer. This patch fixes it by moving the unrelated bsize setting out of the way so that we enter the slow path as inteded. Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block") Cc: stable@vger.kernel.org Reported-by: xiakaixu <xiakaixu@huawei.com> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: cryptd - initialize child shash_desc on importArd Biesheuvel2017-04-111-2/+7
| | | | | | | | | | | | | | commit 0bd2223594a4dcddc1e34b15774a3a4776f7749e upstream. When calling .import() on a cryptd ahash_request, the structure members that describe the child transform in the shash_desc need to be initialized like they are when calling .init() Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: algif_skcipher - Load TX SG list after waitingHerbert Xu2017-04-111-7/+7
| | | | | | | | | | | | | | commit 4f0414e54e4d1893c6f08260693f8ef84c929293 upstream. We need to load the TX SG list in sendmsg(2) after waiting for incoming data, not before. Cc: stable@vger.kernel.org Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: algif_skcipher - Fix race condition in skcipher_check_keyHerbert Xu2017-04-111-3/+6
| | | | | | | | | | | | commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream. We need to lock the child socket in skcipher_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: algif_hash - Fix race condition in hash_check_keyHerbert Xu2017-04-111-3/+6
| | | | | | | | | | | | commit ad46d7e33219218605ea619e32553daf4f346b9f upstream. We need to lock the child socket in hash_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: af_alg - Forbid bind(2) when nokey child sockets are presentHerbert Xu2017-04-111-9/+7
| | | | | | | | | | | | | | | | commit a6a48c565f6f112c6983e2a02b1602189ed6e26e upstream. This patch forbids the calling of bind(2) when there are child sockets created by accept(2) in existence, even if they are created on the nokey path. This is needed as those child sockets have references to the tfm object which bind(2) will destroy. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: algif_skcipher - Remove custom release parent functionHerbert Xu2017-04-111-40/+3
| | | | | | | | | | | | commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
* crypto: algif_hash - Remove custom release parent functionHerbert Xu2017-04-111-40/+3
| | | | | | | | | | | | commit f1d84af1835846a5a2b827382c5848faf2bb0e75 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by: Willy Tarreau <w@1wt.eu>
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-26 18:17:48 +0000