- 03 Jul, 2017 9 commits
-
-
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:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
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 31 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:
Stefan Bader <stefan.bader@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 <sprabhu@redhat.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Cc: Stable <stable@vger.kernel.org> (cherry-picked from commit 38bd4906) 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:
Steve French <smfrench@gmail.com> (cherry picked from commit b8c60012) 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:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 This change allows to encrypt packets if it is required by a server for SMB sessions or tree connections. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 In order to allow encryption on SMB connection we need to exchange a session key and generate encryption and decryption keys. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 This will allow us to do protocol specific tranformations of packets before sending to the server. For SMB3 it can be used to support encryption. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Allocate and initialize SMB2 read request without RFC1001 length field to directly call cifs_send_recv() rather than SendReceive2() in a read codepath. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Do not process RFC1001 length in smb2_hdr_assemble() because it is not a part of SMB2 header. This allows to cleanup the code and adds a possibility combine several SMB2 packets into one for compounding. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 In order to simplify further encryption support we need to separate RFC1001 length and SMB2 header when sending a request. Put the length field in iov[0] and the rest of the packet into following iovs. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Now SendReceive2 frees the first iov and returns a response buffer in it that increases a code complexity. Simplify this by making a caller responsible for freeing request buffer itself and returning a response buffer in a separate iov. Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1670508 In order to support compounding and encryption we need to separate RFC1001 length field and SMB2 header structure because the protocol treats them differently. This change will allow to simplify parsing of such complex SMB2 packets further. Signed-off-by:
-
Jean Delvare authored
BugLink: http://bugs.launchpad.net/bugs/1670508 List soft dependencies of cifs so that mkinitrd and dracut can include the required helper modules. Reviewed-by:
Jean Delvare <jdelvare@suse.de> Cc: Steve French <sfrench@samba.org> (cherry picked from commit b9be76d5) Signed-off-by:
-
Jean Delvare authored
BugLink: http://bugs.launchpad.net/bugs/1670508 The sha256 and cmac crypto modules are only needed for SMB2+, so move the select statements to config CIFS_SMB2. Also select CRYPTO_AES there as SMB2+ needs it. Reviewed-by:
-
Jean Delvare authored
BugLink: http://bugs.launchpad.net/bugs/1670508 * CIFS_SMB2 depends on CIFS, which depends on INET and selects NLS. So these dependencies do not need to be repeated for CIFS_SMB2. * CIFS_SMB311 depends on CIFS_SMB2, which depends on INET. So this dependency doesn't need to be repeated for CIFS_SMB311. Reviewed-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1670508 New mount option "snapshot=<time>" to allow mounting an earlier version of the remote volume (if such a snapshot exists on the server). Note that eventually specifying a snapshot time of 1 will allow the user to mount the oldest snapshot. A subsequent patch add the processing for that and another for actually specifying the "time warp" create context on SMB2/SMB3 open. Check to make sure SMB2 negotiated, and ensure that we use a different tcon if mount same share twice but with different snaphshot times Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1670508 We split the rawntlmssp authentication into negotiate and authencate parts. We also clean up the code and add helpers. Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Add helper functions and split Kerberos authentication off SMB2_sess_setup. Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Add mount option "max_credits" to allow setting maximum SMB3 credits to any value from 10 to 64000 (default is 32000). This can be useful to workaround servers with problems allocating credits, or to throttle the client to use smaller amount of simultaneous i/o or to workaround server performance issues. Also adds a cap, so that even if the server granted us more than 65000 credits due to a server bug, we would not use that many. Signed-off-by:
Steve French <steve.french@primarydata.com> (cherry picked from commit 141891f4) Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1670508 Fix memory leaks introduced by the patch fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
-
Al Viro authored
BugLink: http://bugs.launchpad.net/bugs/1670508Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit a6137305) Signed-off-by:
-
Al Viro authored
BugLink: http://bugs.launchpad.net/bugs/1670508 just do ITER_BVEC recvmsg Signed-off-by:
-
