- 19 Jul, 2017 20 commits
-
-
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:
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 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:
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 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by:
-
