- 19 Jul, 2017 9 commits
-
-
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 <netanel@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 800c55cb) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-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 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:
Stefan Bader <stefan.bader@canonical.com> Acked-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:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-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:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-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:
-
- 12 Jul, 2017 2 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Thadeu Lima de Souza Cascardo authored
BugLink: https://bugs.launchpad.net/bugs/1701697 In linux-4.4.0-84, we backported commit 2da62906 ("[net] drop 'size' argument of sock_recvmsg()"), which breaks building iscsitarget-dkms. iscsitarget was fixed to build with this new kernel, but we need to add a Breaks with older versions. Signed-off-by:
-
- 10 Jul, 2017 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 03 Jul, 2017 10 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1676635 It was found that ICTIMESYNCFLAG_SYNC packets are handled incorrectly on WS2012R2, e.g. after the guest is paused and resumed its time is set to something different from host's time. The problem is that we call adj_guesttime() with reftime=0 for these old hosts and we don't account for that in 'if (adj_flags & ICTIMESYNCFLAG_SYNC)' branch and hv_set_host_time(). While we could've solved this by adding a check like 'if (ts_srv_version > TS_VERSION_3)' to hv_set_host_time() I prefer to do some refactoring. We don't need to have two separate containers for host samples, struct host_ts which we use for PTP is enough. Throw away 'struct adj_time_work' and create hv_get_adj_host_time() accessor to host_ts to avoid code duplication. Fixes: 3716a49a ("hv_utils: implement Hyper-V PTP source") Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from linux-next commit 1d10602d) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1676635 Turns out that our implementation of .getcrosststamp() never actually worked. Hyper-V is sending time samples every 5 seconds and this is too much for get_device_system_crosststamp() as it's interpolation algorithm (which nobody is currently using in kernel, btw) accounts for a 'slow' device but we're not slow in Hyper-V, our time reference is too far away. .getcrosststamp() is not currently used, get_device_system_crosststamp() almost always returns -EINVAL and client falls back to using PTP_SYS_OFFSET so this patch doesn't change much. I also tried doing interpolation manually (e.g. the same way hv_ptp_gettime() works and it turns out that we're getting even lower quality: PTP_SYS_OFFSET_PRECISE with manual interpolation: * PHC0 0 3 37 4 -3974ns[-5338ns] +/- 977ns * PHC0 0 3 77 7 +2227ns[+3184ns] +/- 576ns * PHC0 0 3 177 10 +3060ns[+5220ns] +/- 548ns * PHC0 0 3 377 12 +3937ns[+4371ns] +/- 1414ns * PHC0 0 3 377 6 +764ns[+1240ns] +/- 1047ns * PHC0 0 3 377 7 -1210ns[-3731ns] +/- 479ns * PHC0 0 3 377 9 +153ns[-1019ns] +/- 406ns * PHC0 0 3 377 12 -872ns[-1793ns] +/- 443ns * PHC0 0 3 377 5 +701ns[+3599ns] +/- 426ns * PHC0 0 3 377 5 -923ns[ -375ns] +/- 1062ns PTP_SYS_OFFSET: * PHC0 0 3 7 5 +72ns[+8020ns] +/- 251ns * PHC0 0 3 17 5 -885ns[-3661ns] +/- 254ns * PHC0 0 3 37 6 -454ns[-5732ns] +/- 258ns * PHC0 0 3 77 10 +1183ns[+3754ns] +/- 164ns * PHC0 0 3 377 5 +579ns[+1137ns] +/- 110ns * PHC0 0 3 377 7 +501ns[+1064ns] +/- 96ns * PHC0 0 3 377 9 +1641ns[+3342ns] +/- 106ns * PHC0 0 3 377 8 -47ns[ +77ns] +/- 160ns * PHC0 0 3 377 5 +54ns[ +107ns] +/- 102ns * PHC0 0 3 377 8 -354ns[ -617ns] +/- 89ns This fact wasn't noticed during the initial testing of the PTP device somehow but got revealed now. Let's just drop .getcrosststamp() implementation for now as it doesn't seem to be suitable for us. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1676635 Without the patch, I always get a "BUG: spinlock bad magic" warning. Fixes: 3716a49a ("hv_utils: implement Hyper-V PTP source") Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1676635 Fix a typo. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1676635 With TimeSync version 4 protocol support we started updating system time continuously through the whole lifetime of Hyper-V guests. Every 5 seconds there is a time sample from the host which triggers do_settimeofday[64](). While the time from the host is very accurate such adjustments may cause issues: - Time is jumping forward and backward, some applications may misbehave. - In case an NTP server runs in parallel and uses something else for time sync (network, PTP,...) system time will never converge. - Systemd starts annoying you by printing "Time has been changed" every 5 seconds to the system log. Instead of doing in-kernel time adjustments offload the work to an NTP client by exposing TimeSync messages as a PTP device. Users may now decide what they want to use as a source. I tested the solution with chrony, the config was: refclock PHC /dev/ptp0 poll 3 dpoll -2 offset 0 The result I'm seeing is accurate enough, the time delta between the guest and the host is almost always within [-10us, +10us], the in-kernel solution was giving us comparable results. I also tried implementing PPS device instead of PTP by using not currently used Hyper-V synthetic timers (we use only one of four for clockevent) but with PPS source only chrony wasn't able to give me the required accuracy, the delta often more that 100us. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1676635 do_settimeofday() is deprecated, use do_settimeofday64() instead. Signed-off-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1676635 As part of the effort to interact with Hyper-V in an instruction set architecture independent way, use the new API to get the current tick. Signed-off-by:
-
Marcelo Henrique Cerri authored
BugLink: http://bugs.launchpad.net/bugs/1676635 Make the MSR and TSC clock sources available during the hv_init() and export them via hyperv_cs in a similar way as the following upstream commit does: commit dee863b5 ("hv: export current Hyper-V clocksource") Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
- 28 Jun, 2017 12 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Jiahau Chang authored
BugLink: http://bugs.launchpad.net/bugs/1695216 v4: Remove the patch code in case USB_PORT_FEAT_REMOTE_WAKE_MASK For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. Signed-off-by:
Jiahau Chang <Lars_Chang@asmedia.com.tw> Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Shih-Yuan Lee (FourDollars) authored
BugLink: http://bugs.launchpad.net/bugs/1699651 T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0a2 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Shih-Yuan Lee (FourDollars) <sylee@canonical.com> Suggested-by:
Owen Lin <olin@rivetnetworks.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (backported from commit 06e41d8a linux-next) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1670508 A signal can interrupt a SendReceive call which result in incoming responses to the call being ignored. This is a problem for calls such as open which results in the successful response being ignored. This results in an open file resource on the server. The patch looks into responses which were cancelled after being sent and in case of successful open closes the open fids. For this patch, the check is only done in SendReceive2() RH-bz: 1403319 Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Commit 4fcd1813 ("Fix reconnect to not defer smb3 session reconnect long after socket reconnect") changes the behaviour of the SMB2 echo service and causes it to renegotiate after a socket reconnect. However under default settings, the echo service could take up to 120 seconds to be scheduled. The patch forces the echo service to be called immediately resulting a negotiate call being made immediately on reconnect. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 The recent changes that added SMB3 encryption support introduced a possible use after free in the demultiplex thread. When we process an encrypted packed we obtain a pointer to SMB session but do not obtain a reference. This can possibly lead to a situation when this session was freed before we copy a decryption key from there. Fix this by obtaining a copy of the key rather than a pointer to the session under a spinlock. Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com>
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 This allows users to inforce encryption for SMB3 shares if a server supports it. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Allow to decrypt transformed packets that are bigger than the big buffer size. In particular it is used for read responses that can only exceed the big buffer size. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Allow to decrypt transformed packets, find a corresponding mid and process as usual further. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Since we have two different types of reads (pagecache and direct) we need to process such responses differently after decryption of a packet. The change allows to specify a callback that copies a read payload data into preallocated pages. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 We need to process read responses differently because the data should go directly into preallocated pages. This can be done by specifying a mid handle callback. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 We need to recognize and parse transformed packets in demultiplex thread to find a corresponsing mid and process it further. Signed-off-by:
-
