- 14 Nov, 2014 40 commits
-
-
Jason Baron authored
commit 8030122a upstream. Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED. Signed-off-by:
Jason Baron <jbaron@akamai.com> Link: http://lkml.kernel.org/r/e6dd616f2cd51583a7e77af6f639b86313c74144.1413405053.git.jbaron@akamai.comSigned-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Baron authored
commit 8a3f075d upstream. Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED. Signed-off-by:
-
Jason Baron authored
commit ab0543de upstream. Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED. Signed-off-by:
-
Jan Kara authored
commit 84ce0f0e upstream. When sg_scsi_ioctl() fails to prepare request to submit in blk_rq_map_kern() we jump to a label where we just end up copying (luckily zeroed-out) kernel buffer to userspace instead of reporting error. Fix the problem by jumping to the right label. CC: Jens Axboe <axboe@kernel.dk> CC: linux-scsi@vger.kernel.org Coverity-id: 1226871 Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jens Axboe <axboe@fb.com>
-
Jan Kara authored
commit ea5d05b3 upstream. If __bitmap_shift_left() or __bitmap_shift_right() are asked to shift by a multiple of BITS_PER_LONG, they will try to shift a long value by BITS_PER_LONG bits which is undefined. Change the functions to avoid the undefined shift. Coverity id: 1192175 Coverity id: 1192174 Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Wang Nan authored
commit 401507d6 upstream. Commit ff7ee93f ("cgroup/kmemleak: Annotate alloc_page() for cgroup allocations") introduces kmemleak_alloc() for alloc_page_cgroup(), but corresponding kmemleak_free() is missing, which makes kmemleak be wrongly disabled after memory offlining. Log is pasted at the end of this commit message. This patch add kmemleak_free() into free_page_cgroup(). During page offlining, this patch removes corresponding entries in kmemleak rbtree. After that, the freed memory can be allocated again by other subsystems without killing kmemleak. bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak Offlined Pages 32768 kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing) CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x46/0x58 create_object+0x266/0x2c0 kmemleak_alloc+0x26/0x50 kmem_cache_alloc+0xd3/0x160 __sigqueue_alloc+0x49/0xd0 __send_signal+0xcb/0x410 send_signal+0x45/0x90 __group_send_sig_info+0x13/0x20 do_notify_parent+0x1bb/0x260 do_exit+0x767/0xa40 do_group_exit+0x44/0xa0 SyS_exit_group+0x17/0x20 system_call_fastpath+0x16/0x1b kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff880016900000 (size 524288): kmemleak: comm "swapper/0", pid 0, jiffies 4294667296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: log_early+0x63/0x77 kmemleak_alloc+0x4b/0x50 init_section_page_cgroup+0x7f/0xf5 page_cgroup_init+0xc5/0xd0 start_kernel+0x333/0x408 x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0xf5/0xfc Fixes: ff7ee93f (cgroup/kmemleak: Annotate alloc_page() for cgroup allocations) Signed-off-by:
Wang Nan <wangnan0@huawei.com> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Hans de Goede authored
commit 90a646c7 upstream. This commit fixes the following oops: [10238.622067] scsi host3: uas_eh_bus_reset_handler start [10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd [10245.779365] usb 3-4: device descriptor read/8, error -110 [10245.883331] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd [10250.897603] usb 3-4: device descriptor read/8, error -110 [10251.058200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [10251.058244] IP: [<ffffffff815ac6e1>] xhci_check_streams_endpoint+0x91/0x140 <snip> [10251.059473] Call Trace: [10251.059487] [<ffffffff815aca6c>] xhci_calculate_streams_and_bitmask+0xbc/0x130 [10251.059520] [<ffffffff815aeb5f>] xhci_alloc_streams+0x10f/0x5a0 [10251.059548] [<ffffffff810a4685>] ? check_preempt_curr+0x75/0xa0 [10251.059575] [<ffffffff810a46dc>] ? ttwu_do_wakeup+0x2c/0x100 [10251.059601] [<ffffffff810a49e6>] ? ttwu_do_activate.constprop.111+0x66/0x70 [10251.059635] [<ffffffff815779ab>] usb_alloc_streams+0xab/0xf0 [10251.059662] [<ffffffffc0616b48>] uas_configure_endpoints+0x128/0x150 [uas] [10251.059694] [<ffffffffc0616bac>] uas_post_reset+0x3c/0xb0 [uas] [10251.059722] [<ffffffff815727d9>] usb_reset_device+0x1b9/0x2a0 [10251.059749] [<ffffffffc0616f42>] uas_eh_bus_reset_handler+0xb2/0x190 [uas] [10251.059781] [<ffffffff81514293>] scsi_try_bus_reset+0x53/0x110 [10251.059808] [<ffffffff815163b7>] scsi_eh_bus_reset+0xf7/0x270 <snip> The problem is the following call sequence (simplified): 1) usb_reset_device 2) usb_reset_and_verify_device 2) hub_port_init 3) hub_port_finish_reset 3) xhci_discover_or_reset_device This frees xhci->devs[slot_id]->eps[ep_index].ring for all eps but 0 4) usb_get_device_descriptor This fails 5) hub_port_init fails 6) usb_reset_and_verify_device fails, does not restore device config 7) uas_post_reset 8) xhci_alloc_streams NULL deref on the free-ed ring This commit fixes this by not allowing usb_alloc_streams to continue if the device is not configured. Note that we do allow usb_free_streams to continue after a (logical) disconnect, as it is necessary to explicitly free the streams at the xhci controller level. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Johan Hovold authored
commit e681286d upstream. Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 0d930e51 ("USB: opticon: Add Opticon OPN2001 write support") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Alan Stern authored
commit 93c9bf4d upstream. Sometimes mass-storage devices using the Bulk-only transport will mistakenly skip the data phase of a command. Rather than sending the data expected by the host or sending a zero-length packet, they go directly to the status phase and send the CSW. This causes problems for usb-storage, for obvious reasons. The driver will interpret the CSW as a short data transfer and will wait to receive a CSW. The device won't have anything left to send, so the command eventually times out. The SCSI layer doesn't retry commands after they time out (this is a relatively recent change). Therefore we should do our best to detect a skipped data phase and handle it promptly. This patch adds code to do that. If usb-storage receives a short 13-byte data transfer from the device, and if the first four bytes of the data match the CSW signature, the driver will set the residue to the full transfer length and interpret the data as a CSW. This fixes Bugzilla #86611. Signed-off-by:
Paul Osmialowski <newchief@king.net.pl> Signed-off-by:
-
Dmitry Eremin-Solenikov authored
commit 2b9375b9 upstream. If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a505 (spi/pxa2xx: add support for runtime PM) Signed-off-by:
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by:
Andrea Adami <andrea.adami@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Ray Jui authored
commit 3ffa6158 upstream. When mapped RX DMA entries are unmapped in an error condition when DMA is firstly configured in the driver, the number of TX DMA entries was passed in, which is incorrect Signed-off-by:
Ray Jui <rjui@broadcom.com> Signed-off-by:
-
Jack Pham authored
commit 1200a82a upstream. On ISOC endpoints the last trb_pool entry used as a LINK TRB is not getting zeroed out correctly due to memset being called incorrectly and in the wrong place. If pool allocated from DMA was not zero-initialized to begin with this will result in the size and ctrl values being random garbage. Call memset correctly after assignment of the trb_link pointer. Fixes: f6bafc6a ("usb: dwc3: convert TRBs into bitshifts") Signed-off-by:
Jack Pham <jackp@codeaurora.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Cyril Brulebois authored
commit 664d6a79 upstream. 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802Reported-by:
Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Signed-off-by:
Cyril Brulebois <kibi@debian.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Dan Williams authored
commit 012eee15 upstream. Port layout: 0: QCDM/DIAG 1: NMEA 2: AT 3: AT/PPP Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Daniele Palmas authored
commit 2d0eb862 upstream. Add VID/PID for Telit LE910 modem. Interfaces description is almost the same than LE920, except that the qmi interface is number 2 (instead than 5). Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 4473d054 upstream. Make sure to only raise DTR on transitions from B0 in set_termios. Also allow set_termios to be called from open with a termios_old of NULL. Note that DTR will not be raised prematurely in this case. Signed-off-by:
-
Johan Hovold authored
commit cf84a691 upstream. Add device-id entry for GW Instek AFG-2225, which has a byte swapped bInterfaceSubClass (0x20). Reported-by:
Karl Palsson <karlp@tweak.net.au> Signed-off-by:
-
Perry Hung authored
commit 7f2719f0 upstream. An official recent Windows driver from FTDI detects counterfeit devices and reprograms the internal EEPROM containing the USB PID to 0, effectively bricking the device. Add support for this VID/PID pair to correctly bind the driver on these devices. See: http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/Signed-off-by:
Perry Hung <iperry@gmail.com> Acked-by:
-
Frans Klaver authored
commit edd74ffa upstream. Add new IDs for the Xsens Awinda Station and Awinda Dongle. While at it, order the definitions by PID and add a logical separation between devices using Xsens' VID and those using FTDI's VID. Signed-off-by:
Frans Klaver <frans.klaver@xsens.com> Signed-off-by:
-
Nathaniel Ting authored
commit 35cc83ea upstream. Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now connect to host PCs over a USB serial link. Signed-off-by:
Nathaniel Ting <nathaniel.ting@silabs.com> Signed-off-by:
-
Peter Hurley authored
commit 547039ec upstream. uart_get_baud_rate() will return baud == 0 if the max rate is set to the "magic" 38400 rate and the SPD_* flags are also specified. On the first iteration, if the current baud rate is higher than the max, the baud rate is clamped at the max (which in the degenerate case is 38400). On the second iteration, the now-"magic" 38400 baud rate selects the possibly higher alternate baud rate indicated by the SPD_* flag. Since only two loop iterations are performed, the loop is exited, a kernel WARNING is generated and a baud rate of 0 is returned. Reproducible with: setserial /dev/ttyS0 spd_hi base_baud 38400 Only perform the "magic" 38400 -> SPD_* baud transform on the first loop iteration, which prevents the degenerate case from recognizing the clamped baud rate as the "magic" 38400 value. Reported-by:
Robert Święcki <robert@swiecki.net> Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit b598aacc upstream. "raw" is a property of a channel, but should not be part of the name of channel. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit 79fa64eb upstream. We should check if a channel is enabled, not if no channels are enabled. Fixes: 550268ca ("staging:iio: scrap scan_count and ensure all drivers use active_scan_mask") Signed-off-by:
-
Lars-Peter Clausen authored
commit e1055473 upstream. In older versions of the IIO framework it was possible to pass a completely different set of channels to iio_buffer_register() as the one that is assigned to the IIO device. Commit 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") introduced a restriction that requires that the set of channels that is passed to iio_buffer_register() is a subset of the channels assigned to the IIO device as the IIO core will use the list of channels that is assigned to the device to lookup a channel by scan index in iio_compute_scan_bytes(). If it can not find the channel the function will crash. This patch fixes the issue by making sure that the same set of channels is assigned to the IIO device and passed to iio_buffer_register(). Note that we need to remove the IIO_CHAN_INFO_RAW and IIO_CHAN_INFO_SCALE info attributes from the channels since we don't actually want those to be registered. Fixes the following crash: Unable to handle kernel NULL pointer dereference at virtual address 00000016 pgd = d2094000 [00000016] *pgd=16e39831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1695 Comm: bash Not tainted 3.17.0-06329-g29461ee #9686 task: d7768040 ti: d5bd4000 task.ti: d5bd4000 PC is at iio_compute_scan_bytes+0x38/0xc0 LR is at iio_compute_scan_bytes+0x34/0xc0 pc : [<c0316de8>] lr : [<c0316de4>] psr: 60070013 sp : d5bd5ec0 ip : 00000000 fp : 00000000 r10: d769f934 r9 : 00000000 r8 : 00000001 r7 : 00000000 r6 : c8fc6240 r5 : d769f800 r4 : 00000000 r3 : d769f800 r2 : 00000000 r1 : ffffffff r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 18c5387d Table: 1209404a DAC: 00000015 Process bash (pid: 1695, stack limit = 0xd5bd4240) Stack: (0xd5bd5ec0 to 0xd5bd6000) 5ec0: d769f800 d7435640 c8fc6240 d769f984 00000000 c03175a4 d7435690 d7435640 5ee0: d769f990 00000002 00000000 d769f800 d5bd4000 00000000 000b43a8 c03177f4 5f00: d769f810 0162b8c8 00000002 c8fc7e00 d77f1d08 d77f1da8 c8fc7e00 c01faf1c 5f20: 00000002 c010694c c010690c d5bd5f88 00000002 c8fc6840 c8fc684c c0105e08 5f40: 00000000 00000000 d20d1580 00000002 000af408 d5bd5f88 c000de84 c00b76d4 5f60: d20d1580 000af408 00000002 d20d1580 d20d1580 00000002 000af408 c000de84 5f80: 00000000 c00b7a44 00000000 00000000 00000002 b6ebea78 00000002 000af408 5fa0: 00000004 c000dd00 b6ebea78 00000002 00000001 000af408 00000002 00000000 5fc0: b6ebea78 00000002 000af408 00000004 bee96a4c 000a6094 00000000 000b43a8 5fe0: 00000000 bee969cc b6e2eb77 b6e6525c 40070010 00000001 00000000 00000000 [<c0316de8>] (iio_compute_scan_bytes) from [<c03175a4>] (__iio_update_buffers+0x248/0x438) [<c03175a4>] (__iio_update_buffers) from [<c03177f4>] (iio_buffer_store_enable+0x60/0x7c) [<c03177f4>] (iio_buffer_store_enable) from [<c01faf1c>] (dev_attr_store+0x18/0x24) [<c01faf1c>] (dev_attr_store) from [<c010694c>] (sysfs_kf_write+0x40/0x4c) [<c010694c>] (sysfs_kf_write) from [<c0105e08>] (kernfs_fop_write+0x110/0x154) [<c0105e08>] (kernfs_fop_write) from [<c00b76d4>] (vfs_write+0xbc/0x170) [<c00b76d4>] (vfs_write) from [<c00b7a44>] (SyS_write+0x40/0x78) [<c00b7a44>] (SyS_write) from [<c000dd00>] (ret_fast_syscall+0x0/0x30) Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by:
-
Lars-Peter Clausen authored
commit 6822ee34 upstream. "raw" is the name of a channel property, but should not be part of the channel name itself. Signed-off-by:
-
Lars-Peter Clausen authored
commit 824269c5 upstream. In older versions of the IIO framework it was possible to pass a completely different set of channels to iio_buffer_register() as the one that is assigned to the IIO device. Commit 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") introduced a restriction that requires that the set of channels that is passed to iio_buffer_register() is a subset of the channels assigned to the IIO device as the IIO core will use the list of channels that is assigned to the device to lookup a channel by scan index in iio_compute_scan_bytes(). If it can not find the channel the function will crash. This patch fixes the issue by making sure that the same set of channels is assigned to the IIO device and passed to iio_buffer_register(). Fixes the follow NULL pointer derefernce kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 00000016 pgd = d53d0000 [00000016] *pgd=1534e831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1626 Comm: bash Not tainted 3.15.0-19969-g2a180eb-dirty #9545 task: d6c124c0 ti: d539a000 task.ti: d539a000 PC is at iio_compute_scan_bytes+0x34/0xa8 LR is at iio_compute_scan_bytes+0x34/0xa8 pc : [<c03052e4>] lr : [<c03052e4>] psr: 60070013 sp : d539beb8 ip : 00000001 fp : 00000000 r10: 00000002 r9 : 00000000 r8 : 00000001 r7 : 00000000 r6 : d6dc8800 r5 : d7571000 r4 : 00000002 r3 : d7571000 r2 : 00000044 r1 : 00000001 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 18c5387d Table: 153d004a DAC: 00000015 Process bash (pid: 1626, stack limit = 0xd539a240) Stack: (0xd539beb8 to 0xd539c000) bea0: c02fc0e4 d7571000 bec0: d76c1640 d6dc8800 d757117c 00000000 d757112c c0305b04 d76c1690 d76c1640 bee0: d7571188 00000002 00000000 d7571000 d539a000 00000000 000dd1c8 c0305d54 bf00: d7571010 0160b868 00000002 c69d3900 d7573278 d7573308 c69d3900 c01ece90 bf20: 00000002 c0103fac c0103f6c d539bf88 00000002 c69d3b00 c69d3b0c c0103468 bf40: 00000000 00000000 d7694a00 00000002 000af408 d539bf88 c000dd84 c00b2f94 bf60: d7694a00 000af408 00000002 d7694a00 d7694a00 00000002 000af408 c000dd84 bf80: 00000000 c00b32d0 00000000 00000000 00000002 b6f1aa78 00000002 000af408 bfa0: 00000004 c000dc00 b6f1aa78 00000002 00000001 000af408 00000002 00000000 bfc0: b6f1aa78 00000002 000af408 00000004 be806a4c 000a6094 00000000 000dd1c8 bfe0: 00000000 be8069cc b6e8ab77 b6ec125c 40070010 00000001 22940489 154a5007 [<c03052e4>] (iio_compute_scan_bytes) from [<c0305b04>] (__iio_update_buffers+0x248/0x438) [<c0305b04>] (__iio_update_buffers) from [<c0305d54>] (iio_buffer_store_enable+0x60/0x7c) [<c0305d54>] (iio_buffer_store_enable) from [<c01ece90>] (dev_attr_store+0x18/0x24) [<c01ece90>] (dev_attr_store) from [<c0103fac>] (sysfs_kf_write+0x40/0x4c) [<c0103fac>] (sysfs_kf_write) from [<c0103468>] (kernfs_fop_write+0x110/0x154) [<c0103468>] (kernfs_fop_write) from [<c00b2f94>] (vfs_write+0xd0/0x160) [<c00b2f94>] (vfs_write) from [<c00b32d0>] (SyS_write+0x40/0x78) [<c00b32d0>] (SyS_write) from [<c000dc00>] (ret_fast_syscall+0x0/0x30) Code: ea00000e e1a01008 e1a00005 ebfff6fc (e5d0a016) Fixes: 959d2952 ("staging:iio: make iio_sw_buffer_preenable much more general.") Signed-off-by:
-
Michal Hocko authored
commit 5695be14 upstream. PM freezer relies on having all tasks frozen by the time devices are getting frozen so that no task will touch them while they are getting frozen. But OOM killer is allowed to kill an already frozen task in order to handle OOM situtation. In order to protect from late wake ups OOM killer is disabled after all tasks are frozen. This, however, still keeps a window open when a killed task didn't manage to die by the time freeze_processes finishes. Reduce the race window by checking all tasks after OOM killer has been disabled. This is still not race free completely unfortunately because oom_killer_disable cannot stop an already ongoing OOM killer so a task might still wake up from the fridge and get killed without freeze_processes noticing. Full synchronization of OOM and freezer is, however, too heavy weight for this highly unlikely case. Introduce and check oom_kills counter which gets incremented early when the allocator enters __alloc_pages_may_oom path and only check all the tasks if the counter changes during the freezing attempt. The counter is updated so early to reduce the race window since allocator checked oom_killer_disabled which is set by PM-freezing code. A false positive will push the PM-freezer into a slow path but that is not a big deal. Changes since v1 - push the re-check loop out of freeze_processes into check_frozen_processes and invert the condition to make the code more readable as per Rafael Fixes: f660daac (oom: thaw threads if oom killed thread is frozen before deferring) Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Cong Wang authored
commit 51fae6da upstream. Since f660daac (oom: thaw threads if oom killed thread is frozen before deferring) OOM killer relies on being able to thaw a frozen task to handle OOM situation but a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) has reorganized the code and stopped clearing freeze flag in __thaw_task. This means that the target task only wakes up and goes into the fridge again because the freezing condition hasn't changed for it. This reintroduces the bug fixed by f660daac. Fix the issue by checking for TIF_MEMDIE thread flag in freezing_slow_path and exclude the task from freezing completely. If a task was already frozen it would get woken by __thaw_task from OOM killer and get out of freezer after rechecking freezing(). Changes since v1 - put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator as per Oleg - return __thaw_task into oom_scan_process_thread because oom_kill_process will not wake task in the fridge because it is sleeping uninterruptible [mhocko@suse.cz: rewrote the changelog] Fixes: a3201227 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Jan Kara authored
commit 599a9b77 upstream. When we fail to load block bitmap in __ext4_new_inode() we will dereference NULL pointer in ext4_journal_get_write_access(). So check for error from ext4_read_block_bitmap(). Coverity-id: 989065 Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Pali Rohár authored
commit 36b4bed5 upstream. Code which changes policy to powersave changes also max_policy_pct based on max_freq. Code which change max_perf_pct has upper limit base on value max_policy_pct. When policy is changing from powersave back to performance then max_policy_pct is not changed. Which means that changing max_perf_pct is not possible to high values if max_freq was too low in powersave policy. Test case: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 800000 $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3300000 $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 100 $ echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor $ echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 20 > /sys/devices/system/cpu/intel_pstate/max_perf_pct $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor powersave $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 800000 $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 20 $ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor $ echo 3300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq $ echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3300000 $ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 24 And now intel_pstate driver allows to set maximal value for max_perf_pct based on max_policy_pct which is 24 for previous powersave max_freq 800000. This patch will set default value for max_policy_pct when setting policy to performance so it will allow to set also max value for max_perf_pct. Signed-off-by:
Pali Rohár <pali.rohar@gmail.com> Acked-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
Jan Kara authored
commit 9378c676 upstream. When there are no meta block groups update_backups() will compute the backup block in 32-bit arithmetics thus possibly overflowing the block number and corrupting the filesystem. OTOH filesystems without meta block groups larger than 16 TB should be rare. Fix the problem by doing the counting in 64-bit arithmetics. Coverity-id: 741252 Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Darrick J. Wong authored
commit 813d32f9 upstream. Convert the ext4_has_group_desc_csum predicate to look for a checksum driver instead of the metadata_csum flag and change the bg checksum calculation function to look for GDT_CSUM before taking the crc16 path. Without this patch, if we mount with ^uninit_bg,^metadata_csum and later metadata_csum gets turned on by accident, the block group checksum functions will incorrectly assume that checksumming is enabled (metadata_csum) but that crc16 should be used (!s_chksum_driver). This is totally wrong, so fix the predicate and the checksum formula selection. (Granted, if the metadata_csum feature bit gets enabled on a live FS then something underhanded is going on, but we could at least avoid writing garbage into the on-disk fields.) Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Eric Sandeen authored
commit 0ff8947f upstream. Delalloc write journal reservations only reserve 1 credit, to update the inode if necessary. However, it may happen once in a filesystem's lifetime that a file will cross the 2G threshold, and require the LARGE_FILE feature to be set in the superblock as well, if it was not set already. This overruns the transaction reservation, and can be demonstrated simply on any ext4 filesystem without the LARGE_FILE feature already set: dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \ conv=notrunc of=testfile sync dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \ conv=notrunc of=testfile leads to: EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28 EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28 EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28 Adjust the number of credits based on whether the flag is already set, and whether the current write may extend past the LARGE_FILE limit. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
Andreas Dilger <adilger@dilger.ca> Signed-off-by:
-
Theodore Ts'o authored
commit f4bb2981 upstream. If there is a corrupted file system which has directory entries that point at reserved, metadata inodes, prohibit them from being used by treating them the same way we treat Boot Loader inodes --- that is, mark them to be bad inodes. This prohibits them from being opened, deleted, or modified via chmod, chown, utimes, etc. In particular, this prevents a corrupted file system which has a directory entry which points at the journal inode from being deleted and its blocks released, after which point Much Hilarity Ensues. Reported-by:
Sami Liedes <sami.liedes@iki.fi> Signed-off-by:
-
Dmitry Monakhov authored
commit 3e67cfad upstream. Otherwise this provokes complain like follows: WARNING: CPU: 12 PID: 5795 at fs/ext4/ext4_jbd2.c:48 ext4_journal_check_start+0x4e/0xa0() Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod CPU: 12 PID: 5795 Comm: python Not tainted 3.17.0-rc2-00175-gae5344f #158 Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011 0000000000000030 ffff8808116cfd28 ffffffff815c7dfc 0000000000000030 0000000000000000 ffff8808116cfd68 ffffffff8106ce8c ffff8808116cfdc8 ffff880813b16000 ffff880806ad6ae8 ffffffff81202008 0000000000000000 Call Trace: [<ffffffff815c7dfc>] dump_stack+0x51/0x6d [<ffffffff8106ce8c>] warn_slowpath_common+0x8c/0xc0 [<ffffffff81202008>] ? ext4_ioctl+0x9e8/0xeb0 [<ffffffff8106ceda>] warn_slowpath_null+0x1a/0x20 [<ffffffff8122867e>] ext4_journal_check_start+0x4e/0xa0 [<ffffffff81228c10>] __ext4_journal_start_sb+0x90/0x110 [<ffffffff81202008>] ext4_ioctl+0x9e8/0xeb0 [<ffffffff8107b0bd>] ? ptrace_stop+0x24d/0x2f0 [<ffffffff81088530>] ? alloc_pid+0x480/0x480 [<ffffffff8107b1f2>] ? ptrace_do_notify+0x92/0xb0 [<ffffffff81186545>] do_vfs_ioctl+0x4e5/0x550 [<ffffffff815cdbcb>] ? _raw_spin_unlock_irq+0x2b/0x40 [<ffffffff81186603>] SyS_ioctl+0x53/0x80 [<ffffffff815ce2ce>] tracesys+0xd0/0xd5 Reviewed-by:
-
Jan Kara authored
commit 279bf6d3 upstream. The check whether quota format is set even though there are no quota files with journalled quota is pointless and it actually makes it impossible to turn off journalled quotas (as there's no way to unset journalled quota format). Just remove the check. Signed-off-by:
-
Darrick J. Wong authored
commit a0626e75 upstream. When loading extended attributes, check each entry's value offset to make sure it doesn't collide with the entries. Without this check it is easy to crash the kernel by mounting a malicious FS containing a file with an EA wherein e_value_offs = 0 and e_value_size > 0 and then deleting the EA, which corrupts the name list. (See the f_ea_value_crash test's FS image in e2fsprogs for an example.) Signed-off-by:
-
Darrick J. Wong authored
commit 064d8389 upstream. Free the buffer head if the journal descriptor block fails checksum verification. This is the jbd2 port of the e2fsprogs patch "e2fsck: free bh on csum verify error in do_one_pass". Signed-off-by:
-
David Daney authored
commit 9e0f162a upstream. In commit 8393c524 (MIPS: tlbex: Fix a missing statement for HUGETLB), the TLB Refill handler was fixed so that non-OCTEON targets would work properly with huge pages. The change was incorrect in that it broke the OCTEON case. The problem is shown here: xxx0: df7a0000 ld k0,0(k1) . . . xxxc0: df610000 ld at,0(k1) xxxc4: 335a0ff0 andi k0,k0,0xff0 xxxc8: e825ffcd bbit1 at,0x5,0x0 xxxcc: 003ad82d daddu k1,at,k0 . . . In the non-octeon case there is a destructive test for the huge PTE bit, and then at 0, $k0 is reloaded (that is what the 8393c524 patch added). In the octeon case, we modify k1 in the branch delay slot, but we never need k0 again, so the new load is not needed, but since k1 is modified, if we do the load, we load from a garbage location and then get a nested TLB Refill, which is seen in userspace as either SIGBUS or SIGSEGV (depending on the garbage). The real fix is to only do this reloading if it is needed, and never where it is harmful. Signed-off-by:
David Daney <david.daney@cavium.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8151/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Nicholas Bellinger authored
commit e2480563 upstream. This patch fixes a bug in handling of SPC-3 PR Activate Persistence across Target Power Loss (APTPL) logic where re-creation of state for MappedLUNs from dynamically generated NodeACLs did not occur during I_T Nexus establishment. It adds the missing core_scsi3_check_aptpl_registration() call during core_tpg_check_initiator_node_acl() -> core_tpg_add_node_to_devs() in order to replay any pre-loaded APTPL metadata state associated with the newly connected SCSI Initiator Port. Cc: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
