09 Jan, 2017
40 commits
-
commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.
Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD. This floods the HBA trace area and we cannot see
other and important HBA trace records long enough.Therefore, do not trace HBA response errors for pure benign residual
under counts at the default trace level.This excludes benign residual under count combined with other validity
bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL. For all those other
cases, we still do want to see both the HBA record and the corresponding
SCSI record by default.Signed-off-by: Steffen Maier
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
Reviewed-by: Benjamin Block
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman -
commit dac37e15b7d511e026a9313c8c46794c144103cd upstream.
When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
eh_target_reset_handler(), it expects us to relent the ownership over
the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
or target - when returning with SUCCESS from the callback ('release'
them). SCSI EH can then reuse those commands.We did not follow this rule to release commands upon SUCCESS; and if
later a reply arrived for one of those supposed to be released commands,
we would still make use of the scsi_cmnd in our ingress tasklet. This
will at least result in undefined behavior or a kernel panic because of
a wrong kernel pointer dereference.To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
*)->data in the matching scope if a TMF was successful. This is done
under the locks (struct zfcp_adapter *)->abort_lock and (struct
zfcp_reqlist *)->lock to prevent the requests from being removed from
the request-hashtable, and the ingress tasklet from making use of the
scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().For cases where a reply arrives during SCSI EH, but before we get a
chance to NULLify the pointer - but before we return from the callback
-, we assume that the code is protected from races via the CAS operation
in blk_complete_request() that is called in scsi_done().The following stacktrace shows an example for a crash resulting from the
previous behavior:Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
Oops: 0038 [#1] SMP
CPU: 2 PID: 0 Comm: swapper/2 Not tainted
task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
Krnl Code: 00000000001156a2: a7190000 lghi %r1,0
00000000001156a6: a7380015 lhi %r3,21
#00000000001156aa: e32050000008 ag %r2,0(%r5)
>00000000001156b0: 482022b0 lh %r2,688(%r2)
00000000001156b4: ae123000 sigp %r1,%r2,0(%r3)
00000000001156b8: b2220020 ipm %r2
00000000001156bc: 8820001c srl %r2,28
00000000001156c0: c02700000001 xilf %r2,1
Call Trace:
([] 0x0)
[] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
[] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
[] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
[] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
[] qdio_kick_handler+0xdc/0x310 [qdio]
[] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
[] tasklet_action+0x9c/0x170
[] __do_softirq+0xe8/0x258
[] do_softirq+0xba/0xc0
[] irq_exit+0xc4/0xe8
[] do_IRQ+0x146/0x1d8
[] io_return+0x0/0x8
[] vtime_stop_cpu+0x4a/0xa0
([] 0x0)
[] arch_cpu_idle+0xa2/0xb0
[] cpu_startup_entry+0x13c/0x1f8
[] smp_start_secondary+0xda/0xe8
[] restart_int_handler+0x56/0x6c
[] 0x0
Last Breaking-Event-Address:
[] arch_spin_lock_wait+0x56/0xb0Suggested-by: Steffen Maier
Signed-off-by: Benjamin Block
Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
Signed-off-by: Steffen Maier
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman -
commit 83337e544323a8bd7492994d64af339175ac7107 upstream.
If iscsit_tpg_add_network_portal() fails then
return error code instead of 0 to user space.If iscsi-target returns 0 then user space keeps
on retrying same command infinitely, targetcli or
echo hangs till command completes with non zero
return value. In some cases it is possible that
add network portal command never completes with
success even after retrying multiple times,
for example - cxgbit_setup_np() always returns
-EINVAL if portal IP does not belong to Chelsio
adapter interface.Signed-off-by: Varun Prakash
Signed-off-by: Bart Van Assche
[ bvanassche: Added "Fixes:" and "Cc: stable" tags ]
Fixes: commit d4b3fa4b0881 ("iscsi-target: Make iscsi_tpg_np driver show/store use generic code")
Signed-off-by: Greg Kroah-Hartman -
… not support JBOD sequence map
commit d5573584429254a14708cf8375c47092b5edaf2c upstream.
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -
commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c upstream.
For SRIOV enabled firmware, if there is a OCR(online controller reset)
possibility driver set the convert flag to 1, which is not happening if
there are outstanding commands even after 180 seconds. As driver does
not set convert flag to 1 and still making the OCR to run, VF(Virtual
function) driver is directly writing on to the register instead of
waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
will wait for 30 secs before going for reset.Signed-off-by: Kiran Kumar Kasturi
Signed-off-by: Sumit Saxena
Reviewed-by: Hannes Reinecke
Reviewed-by: Tomas Henzl
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman -
commit a0ebf519b8a2666438d999c62995618c710573e5 upstream.
Make sure to drop the reference taken by class_find_device() also on
allocation errors in open().Signed-off-by: Johan Hovold
Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for...")
Signed-off-by: Alexander Shishkin
Signed-off-by: Greg Kroah-Hartman -
commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.
There is a disagreement between drivers/tty/vt/keyboard.c and
drivers/input/input-leds.c with regard to what is a Scroll Lock LED
trigger name: input calls it "kbd-scrolllock", but vt calls it
"kbd-scrollock" (two l's).
This prevents Scroll Lock LED trigger from binding to this LED by default.Since it is a scroLL Lock LED, this interface was introduced only about a
year ago and in an Internet search people seem to reference this trigger
only to set it to this LED let's simply rename it to "kbd-scrolllock".Also, it looks like this was supposed to be changed before this code was
merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
the input side.Signed-off-by: Maciej S. Szmigiero
Acked-by: Samuel Thibault
Signed-off-by: Greg Kroah-Hartman -
commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.
If a block device is closed while iterate_bdevs() is handling it, the
following NULL pointer dereference occurs because bdev->b_disk is NULL
in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
turn called by the mapping_cap_writeback_dirty() call in
__filemap_fdatawrite_range()):BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
IP: [] blk_get_backing_dev_info+0x10/0x20
PGD 9e62067 PUD 9ee8067 PMD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
RIP: 0010:[] [] blk_get_backing_dev_info+0x10/0x20
RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
Stack:
ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
Call Trace:
[] __filemap_fdatawrite_range+0x85/0x90
[] filemap_fdatawrite+0x1f/0x30
[] fdatawrite_one_bdev+0x16/0x20
[] iterate_bdevs+0xf2/0x130
[] sys_sync+0x63/0x90
[] entry_SYSCALL_64_fastpath+0x12/0x76
Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 8b 80 08 05 00 00 5d
RIP [] blk_get_backing_dev_info+0x10/0x20
RSP
CR2: 0000000000000508
---[ end trace 2487336ceb3de62d ]---The crash is easily reproducible by running the following command, if an
msleep(100) is inserted before the call to func() in iterate_devs():while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
Fix it by holding the bd_mutex across the func() call and only calling
func() if the bdev is opened.Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
Reported-and-tested-by: Wei Fang
Signed-off-by: Rabin Vincent
Signed-off-by: Jan Kara
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 9ff2007bea1f1bfc53ac0bc7ccf8200bb275fd52 upstream.
Add MEI Lewisburg PCH IDs for Purley based workstations.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman -
commit d5f8e166c25750adc147b0adf64a62a91653438a upstream.
pm_runtime_autosuspend can take synchronous or asynchronous
paths, Because we are calling pm_runtime_mark_last_busy just before
this most of the cases it takes the asynchronous way. However,
when the FW or driver resets during already running runtime suspend,
the call will result in calling to the driver's rpm callback and results
in a deadlock on device_lock.
The simplest fix is to replace pm_runtime_autosuspend with
asynchronous pm_request_autosuspend.Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman -
commit 298360af3dab45659810fdc51aba0c9f4097e4f6 upstream.
ast_get_dram_info() configures a window in order to access BMC memory.
A BMC register can be configured to disallow this, and if so, causes
an infinite loop in the ast driver which renders the system unusable.Fix this by erroring out if an error is detected. On powerpc systems with
EEH, this leads to the device being fenced and the system continuing to
operate.Signed-off-by: Russell Currey
Reviewed-by: Joel Stanley
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc
Signed-off-by: Greg Kroah-Hartman -
commit 202e0b227b906cb80a2791f21216a55d9468d61b upstream.
set valid data to mmRLC_SRM_INDEX_CNTL_ADDRx/DATAx.
Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit eb584241226958d45aa1f07f4f6a6ea9da98b29e upstream.
the CP_PG_DISABLE bit was reversed.
Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 10e2ca346bf74561ff1b7fff6287716ab976cd8c upstream.
If vBIOS noFan bit is set, the fan table parameters in thermal controller
will not get initialized. The driver should avoid to use these uninitialized
parameter to do calculation. Otherwise, it may trigger divide 0 error.Signed-off-by: Hawking Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 0a97c81a9717431e6c57ea845b59c3c345edce67 upstream.
Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels.
It turns out that N2600 and N2800 comes with 64-bit enabled. We
previously assumed there where no such systems out there.Signed-off-by: Patrik Jakobsson
Signed-off-by: Sean Paul
Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit abb2e3c1ce64c8bba678973800c34ea1dc97c42c upstream.
New variant.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 upstream.
New variant.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 6b16cf7785a4200b1bddf4f70c9dda2efc49e278 upstream.
Fixes hangs in that case under some circumstances.
v2:
* Only use non-0 x/yorigin if the cursor is (partially) outside of the
top/left edge of the total surface with AVIVO/DCEBugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000433
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit dcab0fa64e300afa18f39cd98d05e0950f652adf upstream.
The cursor size also affects the register programming.
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit b27add13f500469127afdf011dbcc9c649e16e54 upstream.
This avoids an issue that occurs when we're attempting to preempt multiple
channels simultaneously. HW seems to ignore preempt requests while it's
still processing a previous one, which, well, makes sense.Fixes random "fifo: SCHED_ERROR 0d []" + GPCCS page faults during parallel
piglit runs on (at least) GM107.Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 5b3800a6b763874e4a23702fb9628d3bd3315ce9 upstream.
DPAUX registers moved on Kepler, these chipsets were still using the
Fermi implementation for some reason.This fixes detection of hotplug/sink IRQs on DP connectors.
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 10dcab3e7f477bffee88d518aad57d06777cfdf4 upstream.
TTM was changed a while back to allow for pipelining of buffer moves, and
part of this was the removal of waiting for a BO to idle before calling
move(), placing the responsibility on the driver to do this if required.That's all well and good, except, we make use of move_notify() to handle
mapping/unmapping from the GPU VMM as move() isn't called on all paths.This commit adds a wait before unmapping from a VMM in move_notify(), to
prevent GPU page faults where a buffer is still being accessed.Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit f4e65efc88b64c1dbca275d42a188edccedb56c6 upstream.
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 5dc7f4aa9d84ea94b54a9bfcef095f0289f1ebda upstream.
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 768e847759d551c96e129e194588dbfb11a1d576 upstream.
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit e137040e0d0376b404fc5155eba44ea07126e3bd upstream.
Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path
if they cannot be found in the new, "official" path. User setups were
broken by the switch, which is bad.There are only 4 firmware files we may want to look up that way, so
hardcode them into the lookup function. All new firmware files should
use the standard "nvidia//gr/" path.Fixes: 8539b37acef7 ("drm/nouveau/gr: use NVIDIA-provided external firmwares")
Signed-off-by: Alexandre Courbot
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit dd31ae9ac933636c3712b7dd0f6152c1d71f81fe upstream.
GUI idle interrupts should be enabled only after we
have enabled coarse grain clock gating (CGCG). This
prevents GFX engine generating idle interrupt even
though CGCG is not completely enabled.Most of the time this goes un-noticed, but on some
Stoney ASICs this results in GFX engine hang after
system resumes from suspend. The issue is not
particular to Stoney though and could have occured
on any ASIC. The patch fixes this issue.Reviewed-by: Alex Deucher
Reported-by: Sunil Uttarwar
Signed-off-by: Arindam Nath
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 8b02cde994e3025b6886c82eac6cd1e7bc4d1fe9 upstream.
The cursor size also affects the register programming.
Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 8e57ec613df7d6bfa8ffe7512290c5415ebb8657 upstream.
We were storing viewport relative coordinates. However, crtc_cursor_set2
and cursor_reset pass amdgpu_crtc->cursor_x/y as the x/y parameters of
cursor_move_locked, which would break if the CRTC isn't located at
(0, 0).Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit ce66cb1e9cbf91fcb216de64a0fe65aa17f97bc1 upstream.
New variant.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 5a23f2720589ec4757bc62183902d2518f02026e upstream.
New variant.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 6276e53fa8c06a3a5cf7b95b77b079966de9ad66 upstream.
The HP Pavilion dv6 has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.Note that there are quite a few HP Pavilion dv6 variants, some
woth ATI and some with NVIDIA hybrid gfx, both seem to need this
quirk to have working backlight control. There are also some versions
with only Intel integrated gfx, these may not need this quirk, but it
should not hurt there.Link: https://bugzilla.redhat.com/show_bug.cgi?id=1204476
Link: https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1416940
Signed-off-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 350fa038c31b056fc509624efb66348ac2c1e3d0 upstream.
The Dell XPS 17 L702X has a non-working acpi_video0 backlight interface
and an intel_backlight interface which works fine. Add a force_native
quirk for it so that the non-working acpi_video0 interface does not get
registered.Note that there also is an issue with the brightnesskeys on this laptop,
they do not generate key-press events in anyway. That is not solved by
this patch.Link: https://bugzilla.redhat.com/show_bug.cgi?id=1123661
Signed-off-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 857a661020a2de3a0304edf33ad656abee100891 upstream.
Commit 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for
32-bit read") changed the type of local variable `d` from `unsigned
short` to `unsigned int` to fix a bug introduced in
commit 9c340ac934db ("staging: comedi: ni_stc.h: add read/write
callbacks to struct ni_private") when reading AI data for NI PCI-6110
and PCI-6111 cards. Unfortunately, other parts of the function rely on
the variable being `unsigned short` when an offset value in local
variable `signbits` is added to `d` before writing the value to the
`data` array:d += signbits;
data[n] = d;The `signbits` variable will be non-zero in bipolar mode, and is used to
convert the hardware's 2's complement, 16-bit numbers to Comedi's
straight binary sample format (with 0 representing the most negative
voltage). This breaks because `d` is now 32 bits wide instead of 16
bits wide, so after the addition of `signbits`, `data[n]` ends up being
set to values above 65536 for negative voltages. This affects all
supported "E series" cards except PCI-6143 (and PXI-6143). Fix it by
ANDing the value written to the `data[n]` with the mask 0xffff.Fixes: 0557344e2149 ("staging: comedi: ni_mio_common: fix local var for 32-bit read")
Signed-off-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman -
commit 655c4d442d1213b617926cc6d54e2a9a793fb46b upstream.
For NI M Series cards, the Comedi `insn_read` handler for the AI
subdevice is broken due to ANDing the value read from the AI FIFO data
register with an incorrect mask. The incorrect mask clears all but the
most significant bit of the sample data. It should preserve all the
sample data bits. Correct it.Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'")
Signed-off-by: Ian Abbott
Signed-off-by: Greg Kroah-Hartman -
commit b8cb86fd95bb461c3496e1f4b4083b198c963a9c upstream.
James Simmons reports:
> The ldlm_pool field pl_recalc_time is set to the current
> monotonic clock value but the interval period is calculated
> with the wall clock. This means the interval period will
> always be far larger than the pl_recalc_period, which is
> just a small interval time period. The correct thing to
> do is to use monotomic clock current value instead of the
> wall clocks value when calculating recalc_interval_sec.This broke when I converted the 32-bit get_seconds() into
ktime_get_{real_,}seconds() inconsistently. Either
one of those two would have worked, but mixing them
does not.Staying with the original intention of the patch, this
changes the ktime_get_seconds() calls into ktime_get_real_seconds(),
using real time instead of mononic time.Fixes: 8f83409cf238 ("staging/lustre: use 64-bit time for pl_recalc")
Reported-by: James Simmons
Signed-off-by: Arnd Bergmann
Reviewed-by: James Simmons
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit cd15dd6ef4ea11df87f717b8b1b83aaa738ec8af upstream.
I have been having a lot of unexplainable crashes in osc_lru_shrink
lately that I could not see a good explanation for and then I found
this patch that slip under the radar somehow that incorrectly
converted while loop for lru list iteration into
list_for_each_entry_safe totally ignoring that in the body of
the loop we drop spinlocks guarding this list and move list entries
around.
Not sure why it was not showing up right away, perhaps some of the
more recent LRU changes committed caused some extra pressure on this
code that finally highlighted the breakage.Reverts: 8adddc36b1fc ("staging: lustre: osc: Use list_for_each_entry_safe")
CC: Bhaktipriya Shridhar
Signed-off-by: Oleg Drokin
Signed-off-by: Greg Kroah-Hartman -
commit abd1026da4a7700a8db370947f75cd17b6ae6f76 upstream.
"kernel BUG at drivers/hv/channel_mgmt.c:350!" is observed when hv_vmbus
module is unloaded. BUG_ON() was introduced in commit 85d9aa705184
("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()") as
vmbus_free_channels() codepath was apparently forgotten.Fixes: 85d9aa705184 ("Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()")
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
commit 217e2bfab22e740227df09f22165e834cddd8a3b upstream.
In docutils 0.13, the return type of get_column_widths method of the
Table directive has changed [1], which breaks our flat-table directive
and leads to a TypeError when trying to build the docs [2].This patch adds support for the new return type, while keeping support
for older docutils versions too.[1] https://sourceforge.net/p/docutils/patches/120/
[2] https://sourceforge.net/p/docutils/bugs/303/Signed-off-by: Dmitry Shachnev
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman -
commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream.
In the critical sysfs entry the thermal hwmon was returning wrong
temperature to the user-space. It was reporting the temperature of the
first trip point instead of the temperature of critical trip point.For example:
/sys/class/hwmon/hwmon0/temp1_crit:50000
/sys/class/thermal/thermal_zone0/trip_point_0_temp:50000
/sys/class/thermal/thermal_zone0/trip_point_0_type:active
/sys/class/thermal/thermal_zone0/trip_point_3_temp:120000
/sys/class/thermal/thermal_zone0/trip_point_3_type:criticalSince commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver
have been registering a sysfs entry if get_crit_temp() callback was
provided. However when accessed, it was calling get_trip_temp() instead
of the get_crit_temp().Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F")
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Zhang Rui
Signed-off-by: Greg Kroah-Hartman
