- 22 Oct, 2015 40 commits
-
-
Peter Seiderer authored
commit 98ce94c8 upstream. Linux cifs mount with ntlmssp against an Mac OS X (Yosemite 10.10.5) share fails in case the clocks differ more than +/-2h: digest-service: digest-request: od failed with 2 proto=ntlmv2 digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2 Fix this by (re-)using the given server timestamp for the ntlmv2 authentication (as Windows 7 does). A related problem was also reported earlier by Namjae Jaen (see below): Windows machine has extended security feature which refuse to allow authentication when there is time difference between server time and client time when ntlmv2 negotiation is used. This problem is prevalent in embedded enviornment where system time is set to default 1970. Modern servers send the server timestamp in the TargetInfo Av_Pair structure in the challenge message [see MS-NLMP 2.2.2.1] In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must use the server provided timestamp if present OR current time if it is not Reported-by:
Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Li Jun authored
commit 8315b77d upstream. Use imx6sx instead of imx6sl's platform flags for imx6sx. Fixes: e14db48d ("usb: chipidea: imx: add runtime power management support") Signed-off-by:
Li Jun <jun.li@freescale.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Alexey Brodkin authored
commit 5959b32e upstream. As per DW MobileStorage databook "each descriptor can transfer up to 4kB of data in chained mode", moreover buffer size that is put in "des1" is limited to 13 bits, i.e. for example on attempt to IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written will be 0. On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in SG-list of 8kB size and that leads to unpredictable behavior of the SD/MMC controller. In particular on write to FAT partition of SD-card the controller will stuck in the middle of DMA transaction. Solution to the problem is simple - we need to pass large (> 4kB) data buffers to the controller via multiple descriptors. And that's what that change does. What's interesting I did try original driver on same platform but configured with 4kB PAGE_SIZE and may confirm that data blocks passed in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody ever faced a problem I did. Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Cc: Seungwon Jeon <tgih.jun@samsung.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: arc-linux-dev@synopsys.com Cc: linux-kernel@vger.kernel.org Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Dan Carpenter authored
commit 9dd6a064 upstream. We don't catch this allocation failure because there is a typo and we check the wrong variable. Fixes: 14b50f80 ('Drivers: hv: util: introduce hv_utils_transport abstraction') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Javi Merino authored
commit eba4f88d upstream. The power table is not being freed on error from cpufreq_cooling register or when unregistering. Free it. Fixes: c36cf071 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
Javi Merino <javi.merino@arm.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Javi Merino authored
commit 459ac375 upstream. build_dyn_power_table() allocates the power table while holding rcu_read_lock. kcalloc using GFP_KERNEL may sleep, so it can't be called in an RCU read-side path. Move the rcu protection to the part of the function that really needs it: the part that handles the dev_pm_opp pointer received from dev_pm_opp_find_freq_ceil(). In the unlikely case that there is an OPP added to the cpu while this function is running, return -EAGAIN. Fixes: c36cf071 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Linus Lüssing authored
commit 65d7d460 upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 17cf0ea4 ("batman-adv: tvlv - add distributed arp table container") Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Antonio Quartulli <antonio@meshcoding.com> Signed-off-by:
-
Linus Torvalds authored
commit b9a53227 upstream. As reported by Dmitry Vyukov, we really shouldn't do ipc_addid() before having initialized the IPC object state. Yes, we initialize the IPC object in a locked state, but with all the lockless RCU lookup work, that IPC object lock no longer means that the state cannot be seen. We already did this for the IPC semaphore code (see commit e8577d1f: "ipc/sem.c: fully initialize sem_array before making it visible") but we clearly forgot about msg and shm. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Davidlohr Bueso <dbueso@suse.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Reyad Attiyat authored
commit 4758dcd1 upstream. This commit checks for the URB_ZERO_PACKET flag and creates an extra zero-length td if the urb transfer length is a multiple of the endpoint's max packet length. Signed-off-by:
Reyad Attiyat <reyad.attiyat@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Cc: Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Mathias Nyman authored
commit cc8e4fc0 upstream. Don't check if timer is running with a timer_pending() before deleting it with del_timer_sync(), this defies the whole point of the sync part and can cause a possible race. Instead we just want to make sure the timer is initialized early enough before we have a chance to delete it. Reported-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Mathias Nyman authored
commit dca77945 upstream. Some changes between xhci 0.96 and xhci 1.0 specifications forced us to check the hci version in code, some of these checks were implemented as hci_version == 1.0, which will not work with new xhci 1.1 controllers. xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these checks to hci_version >= 1.0 Signed-off-by:
-
Roger Quadros authored
commit 448116bf upstream. During quick plug/removal of OTG adapter during dual-role testing it can happen that xhci_alloc_device() is called for the newly detected device after the DRD library has called xhci_stop to remove the HCD. If that is the case, just fail early to prevent the following warning. [ 154.732649] hub 4-0:1.0: USB hub found [ 154.742204] hub 4-0:1.0: 1 port detected [ 154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt 0000 [ 154.854609] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd [ 154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 155.043315] usb usb4: USB disconnect, device number 1 [ 155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop [ 155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered [ 155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1 [ 155.071710] usb usb3: USB disconnect, device number 1 [ 155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.082389] ------------[ cut here ]------------ [ 155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800 xhci_setup_device+0x410/0x484 [xhci_hcd]() [ 155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc [ 155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: G W 4.1.4-00834-gcd9380b-dirty #50 [ 155.156073] Hardware name: Generic AM43 (Flattened Device Tree) [ 155.162117] Workqueue: usb_hub_wq hub_event [usbcore] [ 155.167249] Backtrace: [ 155.169751] [<c0012af0>] (dump_backtrace) from [<c0012c8c>] (show_stack+0x18/0x1c) [ 155.177390] r6:c089d4a4 r5:ffffffff r4:00000000 r3:ee46c000 [ 155.183137] [<c0012c74>] (show_stack) from [<c05f7c14>] (dump_stack+0x84/0xd0) [ 155.190446] [<c05f7b90>] (dump_stack) from [<c00439ac>] (warn_slowpath_common+0x80/0xbc) [ 155.198605] r7:00000009 r6:00000ed8 r5:bf27eb70 r4:00000000 [ 155.204348] [<c004392c>] (warn_slowpath_common) from [<c0043a0c>] (warn_slowpath_null+0x24/0x2c) [ 155.213202] r8:ee49f000 r7:ee7c0004 r6:00000000 r5:ee7c0158 r4:ee7c0000 [ 155.220051] [<c00439e8>] (warn_slowpath_null) from [<bf27eb70>] (xhci_setup_device+0x410/0x484 [xhci_hcd]) [ 155.229816] [<bf27e760>] (xhci_setup_device [xhci_hcd]) from [<bf27ec10>] (xhci_address_device+0x14/0x18 [xhci_hcd]) [ 155.240415] r10:ee598200 r9:00000001 r8:00000002 r7:00000001 r6:00000003 r5:00000002 [ 155.248363] r4:ee49f000 [ 155.250978] [<bf27ebfc>] (xhci_address_device [xhci_hcd]) from [<bf20cb94>] (hub_port_init+0x1b8/0xa9c [usbcore]) [ 155.261403] [<bf20c9dc>] (hub_port_init [usbcore]) from [<bf2101e0>] (hub_event+0x738/0x1020 [usbcore]) [ 155.270874] r10:ee598200 r9:ee7c0000 r8:ee7c0038 r7:ee518800 r6:ee49f000 r5:00000001 [ 155.278822] r4:00000000 [ 155.281426] [<bf20faa8>] (hub_event [usbcore]) from [<c005754c>] (process_one_work+0x128/0x340) [ 155.290196] r10:00000000 r9:00000003 r8:00000000 r7:fedfa000 r6:eeec5400 r5:ee598314 [ 155.298151] r4:ee434380 [ 155.300718] [<c0057424>] (process_one_work) from [<c00578f8>] (worker_thread+0x158/0x49c) [ 155.308963] r10:ee434380 r9:00000003 r8:eeec5400 r7:00000008 r6:ee434398 r5:eeec5400 [ 155.316913] r4:eeec5414 [ 155.319482] [<c00577a0>] (worker_thread) from [<c005cc40>] (kthread+0xdc/0xf8) [ 155.326765] r10:00000000 r9:00000000 r8:00000000 r7:c00577a0 r6:ee434380 r5:ee4441c0 [ 155.334713] r4:00000000 r3:00000000 [ 155.338341] [<c005cb64>] (kthread) from [<c000fc08>] (ret_from_fork+0x14/0x2c) [ 155.345626] r7:00000000 r6:00000000 r5:c005cb64 r4:ee4441c0 [ 155.356108] ---[ end trace a58d34c223b190e6 ]--- [ 155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1! [ 155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device [ 155.579667] ------------[ cut here ]------------ Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Roger Quadros authored
commit 8c24d6d7 upstream. xhci_stop will be called twice, once for the shared hcd and again for the primary hcd. We stop the XHCI controller in any case so clean up everything on the first call else we can timeout waiting for pending requests to complete. Signed-off-by:
-
Roger Quadros authored
commit e5bfeab0 upstream. For whatever reason if XHCI died in the previous instant then it will never recover on the next xhci_start unless we clear the DYING flag. Signed-off-by:
-
Roger Quadros authored
commit 85ac90f8 upstream. Else it races with xhci_setup_device Signed-off-by:
-
Tomer Barletz authored
commit 2b7627b7 upstream. xhci_pme_quirk() is only used when CONFIG_PM is defined. Compiling a kernel without PM complains about this function [reworded commit message -Mathias] Signed-off-by:
Tomer Barletz <barletz@gmail.com> Signed-off-by:
-
Mathias Nyman authored
commit a6809ffd upstream. We want to give the command abortion an additional try to stop the command ring before we completely hose xhci. Tested-by:
Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit cbb4be65 upstream. Fix potential null-pointer dereference at probe by making sure that the required endpoints are present. The whiteheat driver assumes there are at least five pairs of bulk endpoints, of which the final pair is used for the "command port". An attempt to bind to an interface with fewer bulk endpoints would currently lead to an oops. Fixes CVE-2015-5257. Reported-by:
Moein Ghasemzadeh <moein@istuary.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Dave Airlie authored
commit 274d8352 upstream. Since 9eb1e57f drm/dp/mst: make sure mst_primary mstb is valid in work function we validate the mstb structs in the work function, and doing that takes a reference. So we should never get here with the work function running using the mstb device, only if the work function hasn't run yet or is running for another mstb. So we don't need to sync the work here, this was causing lockdep spew as below. [ +0.000160] ============================================= [ +0.000001] [ INFO: possible recursive locking detected ] [ +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G W ------------ [ +0.000001] --------------------------------------------- [ +0.000001] kworker/4:2/1262 is trying to acquire lock: [ +0.000001] ((&mgr->work)){+.+.+.}, at: [<ffffffff810b29a5>] flush_work+0x5/0x2e0 [ +0.000007] but task is already holding lock: [ +0.000001] ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710 [ +0.000004] other info that might help us debug this: [ +0.000001] Possible unsafe locking scenario: [ +0.000002] CPU0 [ +0.000000] ---- [ +0.000001] lock((&mgr->work)); [ +0.000002] lock((&mgr->work)); [ +0.000001] *** DEADLOCK *** [ +0.000001] May be due to missing lock nesting notation [ +0.000002] 2 locks held by kworker/4:2/1262: [ +0.000001] #0: (events_long){.+.+.+}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710 [ +0.000004] #1: ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710 [ +0.000003] stack backtrace: [ +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G W ------------ 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 [ +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015 [ +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ +0.000001] ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d [ +0.000004] ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003 [ +0.000002] ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00 [ +0.000003] Call Trace: [ +0.000004] [<ffffffff816fe04d>] dump_stack+0x19/0x1b [ +0.000004] [<ffffffff8110f47f>] __lock_acquire+0x115f/0x1250 [ +0.000002] [<ffffffff8110fd49>] lock_acquire+0x99/0x1e0 [ +0.000002] [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0 [ +0.000002] [<ffffffff810b29ee>] flush_work+0x4e/0x2e0 [ +0.000002] [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0 [ +0.000004] [<ffffffff81025905>] ? native_sched_clock+0x35/0x80 [ +0.000002] [<ffffffff81025959>] ? sched_clock+0x9/0x10 [ +0.000002] [<ffffffff810da1f5>] ? local_clock+0x25/0x30 [ +0.000002] [<ffffffff8110dca9>] ? mark_held_locks+0xb9/0x140 [ +0.000003] [<ffffffff810b4ed5>] ? __cancel_work_timer+0x95/0x160 [ +0.000002] [<ffffffff810b4ee8>] __cancel_work_timer+0xa8/0x160 [ +0.000002] [<ffffffff810b4fb0>] cancel_work_sync+0x10/0x20 [ +0.000007] [<ffffffffa0160d17>] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper] [ +0.000006] [<ffffffffa0163968>] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper] [ +0.000002] [<ffffffff810b5850>] process_one_work+0x220/0x710 [ +0.000002] [<ffffffff810b57e4>] ? process_one_work+0x1b4/0x710 [ +0.000005] [<ffffffff810b5e5b>] worker_thread+0x11b/0x3a0 [ +0.000003] [<ffffffff810b5d40>] ? process_one_work+0x710/0x710 [ +0.000002] [<ffffffff810beced>] kthread+0xed/0x100 [ +0.000003] [<ffffffff810bec00>] ? insert_kthread_work+0x80/0x80 [ +0.000003] [<ffffffff817121d8>] ret_from_fork+0x58/0x90 v2: add flush_work. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit df4839fd upstream. output ports should always have a connector, unless in the rare case connector allocation fails in the driver. In this case we only need to teardown the pdt, and free the struct, and there is no need to send a hotplug msg. In the case were we add the port to the destroy list we need to send a hotplug if we destroy any connectors, so userspace knows to reprobe stuff. this patch also handles port->connector allocation failing which should be a rare event, but makes the code consistent. Reviewed-by:
-
Michel Dänzer authored
commit 4281f46e upstream. Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop, the radeon_atom_encoder_dpms_avivo part is only compile tested. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
commit da168d81 upstream. I've done some extensive history digging across libdrm, mesa and xf86-video-{intel,nouveau,ati}. The only potential user of this with kms drivers I could find was ttmtest, which once used drmGetLock still. But that mistake was quickly fixed up. Even the intel xvmc library (which otherwise was really good with using dri1 stuff in kms mode) managed to never take the hw lock for dri2 (and hence kms). Hence it should be save to unconditionally disallow this. Cc: Peter Antoine <peter.antoine@intel.com> Reviewed-by:
Peter Antoine <peter.antoine@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Jani Nikula authored
commit cd67d226 upstream. The VBT MIPI Sequence Block version 3 has forward incompatible changes: First, the block size in the header has been specified reserved, and the actual size is a separate 32-bit value within the block. The current find_section() function to will only look at the size in the block header, and, depending on what's in that now reserved size field, continue looking for other sections in the wrong place. Fix this by taking the new block size field into account. This will ensure that the lookups for other sections will work properly, as long as the new 32-bit size does not go beyond the opregion VBT mailbox size. Second, the contents of the block have been completely changed. Gracefully refuse parsing the yet unknown data version. Cc: Deepak M <m.deepak@intel.com> Reviewed-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Alex Deucher authored
commit 74b3112e upstream. Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Port of radeon commit: drm/radeon: Restore LCD backlight level on resume (>= R5xx) Signed-off-by:
-
Alex Deucher authored
commit 5a6adfa2 upstream. The value was much too low, which could cause the userspace visible vblank counter to move backwards when the hardware counter wrapped around. Ported from radeon commit: b0b9bb4dReviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by:
-
Leo Liu authored
commit 5146419e upstream. Invalid messages can crash the hw otherwise Ported from radeon commit a1b403daSigned-off-by:
Leo Liu <leo.liu@amd.com> Reviewed-by:
-
Leo Liu authored
commit 2bd188d0 upstream. Fixes suspend issues with UVD. Signed-off-by:
-
Leo Liu authored
commit 1ee4478a upstream. This causes problems with multiple suspend/resume cycles. Signed-off-by:
-
Christian König authored
commit b7d698d7 upstream. mem->start is a long, so this can overflow on 32bit systems. Signed-off-by:
-
Fabiano Fidêncio authored
commit 8d0d9401 upstream. When disabling/enabling a crtc the primary area must be updated independently of which crtc has been disabled/enabled. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735Signed-off-by:
Fabiano Fidêncio <fidencio@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 69e5d3f8 upstream. If the server isn't new enough to give us state, report the first monitor as always connected, otherwise believe the server side. Signed-off-by:
-
Steve French authored
commit 646200a0 upstream. The error paths in set_file_size for cifs and smb3 are incorrect. In the unlikely event that a server did not support set file info of the file size, the code incorrectly falls back to trying SMBWriteX (note that only the original core SMB Write, used for example by DOS, can set the file size this way - this actually does not work for the more recent SMBWriteX). The idea was since the old DOS SMB Write could set the file size if you write zero bytes at that offset then use that if server rejects the normal set file info call. Fortunately the SMBWriteX will never be sent on the wire (except when file size is zero) since the length and offset fields were reversed in the two places in this function that call SMBWriteX causing the fall back path to return an error. It is also important to never call an SMB request from an SMB2/sMB3 session (which theoretically would be possible, and can cause a brief session drop, although the client recovers) so this should be fixed. In practice this path does not happen with modern servers but the error fall back to SMBWriteX is clearly wrong. Removing the calls to SMBWriteX in the error paths in cifs_set_file_size Pointed out by PaX/grsecurity team Signed-off-by:
Steve French <steve.french@primarydata.com> Reported-by:
PaX Team <pageexec@freemail.hu> CC: Emese Revfy <re.emese@gmail.com> CC: Brad Spengler <spender@grsecurity.net> Signed-off-by:
-
Steve French authored
commit e0ddde9d upstream. leases (oplocks) were always requested for SMB2/SMB3 even when oplocks disabled in the cifs.ko module. Signed-off-by:
Chandrika Srinivasan <chandrika.srinivasan@citrix.com> Signed-off-by:
-
Steve French authored
commit ceb1b0b9 upstream. Kerberos, which is very important for security, was only enabled for CIFS not SMB2/SMB3 mounts (e.g. vers=3.0) Patch based on the information detailed in http://thread.gmane.org/gmane.linux.kernel.cifs/10081/focus=10307 to enable Kerberized SMB2/SMB3 a) SMB2_negotiate: enable/use decode_negTokenInit in SMB2_negotiate b) SMB2_sess_setup: handle Kerberos sectype and replicate Kerberos SMB1 processing done in sess_auth_kerberos Signed-off-by:
Noel Power <noel.power@suse.com> Signed-off-by:
Jim McDonough <jmcd@samba.org> Signed-off-by:
-
Trond Myklebust authored
commit 8fa4592a upstream. If all other conditions in nfs_can_extend_write() are met, and there are no locks, then we should be able to assume close-to-open semantics and the ability to extend our write to cover the whole page. With this patch, the xfstests generic/074 test completes in 242s instead of >1400s on my test rig. Fixes: bd61e0a9 ("locks: convert posix locks to file_lock_context") Cc: Jeff Layton <jlayton@primarydata.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Peng Tao authored
commit 048883e0 upstream. We really want sizeof(struct page *) instead. Otherwise we limit maximum IO size to 64 pages rather than 512 pages on a 64bit system. Fixes 2e11f829(nfs: cap request size to fit a kmalloced page array). Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Peng Tao <tao.peng@primarydata.com> Fixes: 2e11f829 ("nfs: cap request size to fit a kmalloced page array") Signed-off-by:
-
Trond Myklebust authored
commit 24311f88 upstream. When a read delegation is being recalled, and we're reclaiming the cached opens, we need to make sure that we only reclaim read-only modes. A previous attempt to do this, relied on retrieving the delegation type from the nfs4_opendata structure. Unfortunately, as Kinglong pointed out, this field can only be set when performing reboot recovery. Furthermore, if we call nfs4_open_recover(), then we end up clobbering the state->flags for all modes that we're not recovering... The fix is to have the delegation recall code pass this information to the recovery call, and then refactor the recovery code so that nfs4_open_delegation_recall() does not need to call nfs4_open_recover(). Reported-by:
Kinglong Mee <kinglongmee@gmail.com> Fixes: 39f897fd ("NFSv4: When returning a delegation, don't...") Tested-by:
-
Kinglong Mee authored
commit 6f29b9bb upstream. There is a reference leak of layout segment after resetting pageio read/write to mds. Signed-off-by:
-
J. Bruce Fields authored
commit 306a5549 upstream. We're incorrectly assigning a loff_t return to an int. If SEEK_HOLE or SEEK_DATA returns an offset over 2^31 then the application will see a weird lseek() result (usually -EIO). Fixes: bdcc2cd1 "NFSv4.2: handle NFS-specific llseek errors" Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Reviewed-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Johan Hedberg authored
commit d8949aad upstream. There are several actions that smp_conn_security() might make that do not require a valid SMP context (conn->smp pointer). One of these actions is to encrypt the link with an existing LTK. If the SMP context wasn't initialized properly we should still allow the independent actions to be done, i.e. the check for the context should only be done at the last possible moment. Reported-by:
Chuck Ebbert <cebbert.lkml@gmail.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
