- 19 Jul, 2017 34 commits
-
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 784047eb upstream. The "len" could be as low as -14 so we should check for negatives. Fixes: 9a7fe54d ("staging: r8188eu: Add source files for new driver - part 1") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 8b8a84c5 upstream. Commit 16fa3dc7 ("mfd: omap-usb-tll: HOST TLL platform driver") added support for USB TLL, but uses OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF bit the wrong way. The comments in the code are correct, but the inverted use of OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF causes the register to be enabled instead of disabled unlike what the comments say. Without this change the Wrigley 3G LTE modem on droid 4 EHCI bus can be only pinged few times before it stops responding. Fixes: 16fa3dc7 ("mfd: omap-usb-tll: HOST TLL platform driver") Signed-off-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Laura Abbott authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 861ce4a3 upstream. '__vmalloc_start_set' currently only gets set in initmem_init() when !CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing a kernel crash: [mm/usercopy] 517e1fbe: kernel BUG at arch/x86/mm/physaddr.c:78! Set '__vmalloc_start_set' appropriately for that case as well. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Laura Abbott <labbott@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: dc16ecf7 ("x86-32: use specific __vmalloc_start_set flag in __virt_addr_valid") Link: http://lkml.kernel.org/r/1494278596-30373-1-git-send-email-labbott@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit be40597a upstream. UARTn_FRAME_PARITY_ODD is 0x0300 UARTn_FRAME_PARITY_EVEN is 0x0200 So if the UART is configured for EVEN parity, it would be reported as ODD. Fix it by correctly testing if the 2 bits are set. Fixes: 3afbd89c ("serial/efm32: add new driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Johannes Berg authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit f1f3e9e2 upstream. When VHT IBSS support was added, the size of the extra elements wasn't considered in ieee80211_ibss_build_presp(), which makes it possible that it would overrun the allocated buffer. Fix it by allocating the necessary space. Fixes: abcff6ef ("mac80211: add VHT support for IBSS") Reported-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Koen Vandeputte authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit f181d6a3 upstream. Add the missing IBSS capability flag during capability init as it needs to be inserted into the generated beacon in order for CSA to work. Fixes: cd7760e6 ("mac80211: add support for CSA in IBSS mode") Signed-off-by:
Piotr Gawlowicz <gawlowicz@tkn.tu-berlin.de> Signed-off-by:
Mikołaj Chwalisz <chwalisz@tkn.tu-berlin.de> Tested-by:
Koen Vandeputte <koen.vandeputte@ncentric.com> Signed-off-by:
-
Jason A. Donenfeld authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 98c67d18 upstream. Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-wireless@vger.kernel.org Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 769dc04d upstream. When a peer sends a BAR frame with PM bit clear, we should not modify its PM state as madated by the spec in 802.11-20012 10.2.1.2. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Christophe JAILLET authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 5ebb6dd3 upstream. We should ensure that 'plane_no' is '< vb->num_planes' as done in 'vb2_plane_cookie' just a few lines below. Fixes: e23ccc0a ("[media] v4l: add videobuf2 Video for Linux 2 driver framework") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Tomasz Wilczyński authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit b8e11f7d upstream. Commit 27ed3cd2 (cpufreq: conservative: Fix the logic in frequency decrease checking) removed the 10 point substraction when comparing the load against down_threshold but did not remove the related limit for the down_threshold value. As a result, down_threshold lower than 11 is not allowed even though values from 1 to 10 do work correctly too. The comment ("cannot be lower than 11 otherwise freq will not fall") also does not apply after removing the substraction. For this reason, allow down_threshold to take any value from 1 to 99 and fix the related comment. Fixes: 27ed3cd2 (cpufreq: conservative: Fix the logic in frequency decrease checking) Signed-off-by:
Tomasz Wilczyński <twilczynski@naver.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Marc Kleine-Budde authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit 5cda3ee5 upstream. This patch adds the missing kfree() in gs_cmd_reset() to free the memory that is not used anymore after usb_control_msg(). Cc: Maximilian Schneider <max@schneidersoft.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1702104 commit ba80aa90 upstream. This patch closes a long standing race in configfs between the creation of a new symlink in create_link(), while the symlink target's config_item is being concurrently removed via configfs_rmdir(). This can happen because the symlink target's reference is obtained by config_item_get() in create_link() before the CONFIGFS_USET_DROPPING bit set by configfs_detach_prep() during configfs_rmdir() shutdown is actually checked.. This originally manifested itself on ppc64 on v4.8.y under heavy load using ibmvscsi target ports with Novalink API: [ 7877.289863] rpadlpar_io: slot U8247.22L.212A91A-V1-C8 added [ 7879.893760] ------------[ cut here ]------------ [ 7879.893768] WARNING: CPU: 15 PID: 17585 at ./include/linux/kref.h:46 config_item_get+0x7c/0x90 [configfs] [ 7879.893811] CPU: 15 PID: 17585 Comm: targetcli Tainted: G O 4.8.17-customv2.22 #12 [ 7879.893812] task: c00000018a0d3400 task.stack: c0000001f3b40000 [ 7879.893813] NIP: d000000002c664ec LR: d000000002c60980 CTR: c000000000b70870 [ 7879.893814] REGS: c0000001f3b43810 TRAP: 0700 Tainted: G O (4.8.17-customv2.22) [ 7879.893815] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28222242 XER: 00000000 [ 7879.893820] CFAR: d000000002c664bc SOFTE: 1 GPR00: d000000002c60980 c0000001f3b43a90 d000000002c70908 c0000000fbc06820 GPR04: c0000001ef1bd900 0000000000000004 0000000000000001 0000000000000000 GPR08: 0000000000000000 0000000000000001 d000000002c69560 d000000002c66d80 GPR12: c000000000b70870 c00000000e798700 c0000001f3b43ca0 c0000001d4949d40 GPR16: c00000014637e1c0 0000000000000000 0000000000000000 c0000000f2392940 GPR20: c0000001f3b43b98 0000000000000041 0000000000600000 0000000000000000 GPR24: fffffffffffff000 0000000000000000 d000000002c60be0 c0000001f1dac490 GPR28: 0000000000000004 0000000000000000 c0000001ef1bd900 c0000000f2392940 [ 7879.893839] NIP [d000000002c664ec] config_item_get+0x7c/0x90 [configfs] [ 7879.893841] LR [d000000002c60980] check_perm+0x80/0x2e0 [configfs] [ 7879.893842] Call Trace: [ 7879.893844] [c0000001f3b43ac0] [d000000002c60980] check_perm+0x80/0x2e0 [configfs] [ 7879.893847] [c0000001f3b43b10] [c000000000329770] do_dentry_open+0x2c0/0x460 [ 7879.893849] [c0000001f3b43b70] [c000000000344480] path_openat+0x210/0x1490 [ 7879.893851] [c0000001f3b43c80] [c00000000034708c] do_filp_open+0xfc/0x170 [ 7879.893853] [c0000001f3b43db0] [c00000000032b5bc] do_sys_open+0x1cc/0x390 [ 7879.893856] [c0000001f3b43e30] [c000000000009584] system_call+0x38/0xec [ 7879.893856] Instruction dump: [ 7879.893858] 409d0014 38210030 e8010010 7c0803a6 4e800020 3d220000 e94981e0 892a0000 [ 7879.893861] 2f890000 409effe0 39200001 992a0000 <0fe00000> 4bffffd0 60000000 60000000 [ 7879.893866] ---[ end trace 14078f0b3b5ad0aa ]--- To close this race, go ahead and obtain the symlink's target config_item reference only after the existing CONFIGFS_USET_DROPPING check succeeds. This way, if configfs_rmdir() wins create_link() will return -ENONET, and if create_link() wins configfs_rmdir() will return -EBUSY. Reported-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Tested-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Alex Hung authored
Some new Dell AIO systems have a button that generates a WMI event to turn the LCD on/off. BugLink: http://bugs.launchpad.net/bugs/1702541Signed-off-by:
Alex Hung <alex.hung@canonical.com> Acked-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (backported from commit ab9bb11c) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1700834 This patch addresses a bug introduced based on my interpretation of the XL710 datasheet. Specifically section 8.4.1 states that "A single transmit packet may span up to 8 buffers (up to 8 data descriptors per packet including both the header and payload buffers)." It then later goes on to say that each segment for a TSO obeys the previous rule, however it then refers to TSO header and the segment payload buffers. I believe the actual limit for fragments with TSO and a skbuff that has payload data in the header portion of the buffer is actually only 7 fragments as the skb->data portion counts as 2 buffers, one for the TSO header, and one for a segment payload buffer. Fixes: 2d37490b ("i40e/i40evf: Rewrite logic for 8 descriptor per packet check") Reported-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry-picked from 3f3f7cb8 upstream) Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 85238999 net-next) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 rx drop counter is reported by the device in the keep-alive event. update the driver's counter with the device counter. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 In ena_com_mem_addr_set(), use the above functions to split dma address to the lower 32 bits and the higher 16 bits. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 ENA driver post Rx buffers through the Rx submission queue for the ENA device to fill them with receive packets. Each Rx buffer is marked with req_id in the Rx descriptor. Newer ENA devices could consume the posted Rx buffer in out of order, and as result the corresponding Rx completion queue will have Rx completion descriptors with non contiguous req_id(s) In this change the driver holds two rings. The first ring (called free_rx_ids) is a mapping ring. It holds all the unused request ids. The values in this ring are from 0 to ring_size -1. When the driver wants to allocate a new Rx buffer it uses the head of free_rx_ids and uses it's value as the index for rx_buffer_info ring. The req_id is also written to the Rx descriptor Upon Rx completion, The driver took the req_id from the completion descriptor and uses it as index in rx_buffer_info. The req_id is then return to the free_rx_ids ring. This patch also adds statistics to inform when the driver receive out of range or unused req_id. Note: free_rx_ids is only accessible from the napi handler, so no locking is required Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 For each device reset, log to the device what is the cause the reset occur. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 Instead of using: memset(ptr, 0x0, sizeof(struct ...)) use: memset(ptr, 0x0, sizeor(*ptr)) Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 With this patch, ENA device can update the ena driver about the desired timeout values: These values are part of the "hardware hints" which are transmitted to the driver as Asynchronous event through ENA async event notification queue. In case the ENA device does not support this capability, the driver will use its own default values. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 return -EOPNOTSUPP instead of -EPERM. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 check_for_missing_tx_completions() is called from a timer task and looking for lost tx packets. The old implementation accumulate all the lost tx packets and did not check if those packets were retrieved on a later stage. This cause to a situation where the driver reset the device for no reason. Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 For the rare case where the device runs out of free rx buffer descriptors (in case of pressure on kernel memory), and the napi handler continuously fail to refill new Rx descriptors until device rx queue totally runs out of all free rx buffers to post incoming packet, leading to a deadlock: * The device won't send interrupts since all the new Rx packets will be dropped. * The napi handler won't try to allocate new Rx descriptors since allocation is part of NAPI that's not being invoked any more The fix involves detecting this scenario and rescheduling NAPI (to refill buffers) by the keepalive/watchdog task. Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 This patch also change the mapping functions to devm_ functions Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 Bug: "Completion context is occupied" error printout will be noticed in dmesg. This error will cause the admin command to fail, which will lead to an ena_probe() failure or a watchdog reset (depends on which admin command failed). Root cause: __ena_com_submit_admin_cmd() is the function that submits new entries to the admin queue. The function have a check that makes sure the queue is not full and the function does not override any outstanding command. It uses head and tail indexes for this check. The head is increased by ena_com_handle_admin_completion() which runs from interrupt context, and the tail index is increased by the submit function (the function is running under ->q_lock, so there is no risk of multithread increment). Each command is associated with a completion context. This context allocated before call to __ena_com_submit_admin_cmd() and freed by ena_com_wait_and_process_admin_cq_interrupts(), right after the command was completed. This can lead to a state where the head was increased, the check passed, but the completion context is still in use. Solution: Use the atomic variable ->outstanding_cmds instead of using the head and the tail indexes. This variable is safe for use since it is bumped in get_comp_ctx() in __ena_com_submit_admin_cmd() and is freed by comp_ctxt_release() Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1701575 The current flow to detect admin completion is: while (command_not_completed) { if (timeout) error check_for_completion() sleep() } So in case the sleep took more than the timeout (in case the thread/workqueue was not scheduled due to higher priority task or prolonged VMexit), the driver can detect a stall even if the completion is present. The fix changes the order of this function to first check for completion and only after that check if the timeout expired. Fixes: 1738cd3e ("Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Lino Sanfilippo authored
BugLink: http://bugs.launchpad.net/bugs/1701575 The check in ena_remove() for the pci driver data not being NULL is not needed, since it is always set in the probe() function. Remove the superfluous check. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by:
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by:Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
- 18 Jul, 2017 5 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Oleg Nesterov authored
expand_stack(vma) fails if address < stack_guard_gap even if there is no vma->vm_prev. I don't think this makes sense, and we didn't do this before the recent commit 1be7107f ("mm: larger stack guard gap, between vmas"). We do not need a gap in this case, any address is fine as long as security_mmap_addr() doesn't object. This also simplifies the code, we know that address >= prev->vm_end and thus underflow is not possible. Link: http://lkml.kernel.org/r/20170628175258.GA24881@redhat.comSigned-off-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Hugh Dickins <hughd@google.com> Cc: Larry Woodman <lwoodman@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2017-1000364 (cherry picked from commit 32e4e6d5) Signed-off-by:
-
Michal Hocko authored
Commit 1be7107f ("mm: larger stack guard gap, between vmas") has introduced a regression in some rust and Java environments which are trying to implement their own stack guard page. They are punching a new MAP_FIXED mapping inside the existing stack Vma. This will confuse expand_{downwards,upwards} into thinking that the stack expansion would in fact get us too close to an existing non-stack vma which is a correct behavior wrt safety. It is a real regression on the other hand. Let's work around the problem by considering PROT_NONE mapping as a part of the stack. This is a gros hack but overflowing to such a mapping would trap anyway an we only can hope that usespace knows what it is doing and handle it propely. Fixes: 1be7107f ("mm: larger stack guard gap, between vmas") Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.czSigned-off-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Willy Tarreau <w@1wt.eu> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
-
Christophe Jaillet authored
BugLink: https://bugs.launchpad.net/bugs/1704857 'rc' is known to be 0 at this point. So if 'init_sg' or 'kzalloc' fails, we should return -ENOMEM instead. Also remove a useless 'rc' in a debug message as it is meaningless here. Fixes: 026e93dc ("CIFS: Encrypt SMB3 requests before sending") Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
Steve French <smfrench@gmail.com> CC: Stable <stable@vger.kernel.org> (cherry picked from commit 517a6e43) Signed-off-by:
-
Pavel Shilovsky authored
BugLink: https://bugs.launchpad.net/bugs/1704857 Currently during receiving a read response mid->resp_buf can be NULL when it is being passed to cifs_discard_remaining_data() from cifs_readv_discard(). Fix it by always passing server->smallbuf instead and initializing mid->resp_buf at the end of read response processing. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
- 14 Jul, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
