Sync up with Linus #56
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Stopping the vb2 thread (as used by several DVB devices) can result in an 'UNBALANCED' warning such as this: vb2: counters for queue ffff880407ee9828: UNBALANCED! vb2: setup: 1 start_streaming: 1 stop_streaming: 1 vb2: wait_prepare: 249333 wait_finish: 249334 This is due to a race condition between stopping the thread and calling vb2_internal_streamoff(). While I have not been able to deduce the exact mechanism how this race condition can produce this warning, I can see that the way the stream is stopped is likely to lead to a race somewhere. This patch simplifies how this is done by first ensuring that the thread is completely stopped before cleaning up the vb2 queue. It does that by setting threadio->stop to true, followed by a call to vb2_queue_error() which will wake up the thread. The thread sees that 'stop' is true and it will exit. The call to kthread_stop() waits until the thread has exited, and only then is the queue cleaned up by calling __vb2_cleanup_fileio(). This is a much cleaner sequence and the warning has now disappeared. Reported-by: Jurgen Kramer <[email protected]> Tested-by: Jurgen Kramer <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Cc: <[email protected]> # for v3.18 and up Signed-off-by: Mauro Carvalho Chehab <[email protected]>
…rformance The burst length could be BEATS_4/8/16. Before this patch, isi use default value BEATS_4. To imporve the performance we could set it to BEATS_16. Otherwise sometime it would cause the ISI overflow error. Reported-by: Bo Shen <[email protected]> Signed-off-by: Josh Wu <[email protected]> Signed-off-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Unlike scan_async_group(), soc_of_bind() doesn't allocate its
soc_camera_async_client structure using devm_kzalloc(), but has it
embedded inside the soc_of_info structure. Hence on failure, it must
free the whole soc_of_info structure, and not just the embedded
soc_camera_async_client structure, as the latter causes a warning, and
may cause slab corruption:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/base/devres.c:887 devm_kfree+0x30/0x40()
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-shmobile-08386-g37feb0d093cb2d8e #128
Hardware name: Generic R8A7791 (Flattened Device Tree)
Backtrace:
[<c0011e7c>] (dump_backtrace) from [<c0012024>] (show_stack+0x18/0x1c)
r6:c05a923b r5:00000009 r4:00000000 r3:00204140
[<c001200c>] (show_stack) from [<c048ed30>] (dump_stack+0x78/0x94)
[<c048ecb8>] (dump_stack) from [<c002687c>] (warn_slowpath_common+0x8c/0xb8)
r4:00000000 r3:00000000
[<c00267f0>] (warn_slowpath_common) from [<c0026980>] (warn_slowpath_null+0x24/0x2c)
r8:ee7d8214 r7:ed83b810 r6:ed83bc20 r5:fffffffa r4:ed83e510
[<c002695c>] (warn_slowpath_null) from [<c025e0cc>] (devm_kfree+0x30/0x40)
[<c025e09c>] (devm_kfree) from [<c032bbf4>] (soc_of_bind.isra.14+0x194/0x1d4)
[<c032ba60>] (soc_of_bind.isra.14) from [<c032c6b8>] (soc_camera_host_register+0x208/0x31c)
r9:00000070 r8:ee7e05d0 r7:ee153210 r6:00000000 r5:ee7e0218 r4:ed83bc20
[<c032c4b0>] (soc_camera_host_register) from [<c032e80c>] (rcar_vin_probe+0x1f4/0x238)
r8:ee153200 r7:00000008 r6:ee153210 r5:ed83bc10 r4:c066319c r3:000000c0
[<c032e618>] (rcar_vin_probe) from [<c025c334>] (platform_drv_probe+0x50/0xa0)
r10:00000000 r9:c0662fa8 r8:00000000 r7:c06a3700 r6:c0662fa8 r5:ee153210
r4:00000000
[<c025c2e4>] (platform_drv_probe) from [<c025af08>] (driver_probe_device+0xc4/0x208)
r6:c06a36f4 r5:00000000 r4:ee153210 r3:c025c2e4
[<c025ae44>] (driver_probe_device) from [<c025b108>] (__driver_attach+0x70/0x94)
r9:c066f9c0 r8:c0624a98 r7:c065b790 r6:c0662fa8 r5:ee153244 r4:ee153210
[<c025b098>] (__driver_attach) from [<c025984c>] (bus_for_each_dev+0x74/0x98)
r6:c025b098 r5:c0662fa8 r4:00000000 r3:00000001
[<c02597d8>] (bus_for_each_dev) from [<c025b1dc>] (driver_attach+0x20/0x28)
r6:ed83c200 r5:00000000 r4:c0662fa8
[<c025b1bc>] (driver_attach) from [<c025a00c>] (bus_add_driver+0xdc/0x1c4)
[<c0259f30>] (bus_add_driver) from [<c025b8f4>] (driver_register+0xa4/0xe8)
r7:c0624a98 r6:00000000 r5:c060b010 r4:c0662fa8
[<c025b850>] (driver_register) from [<c025ccd0>] (__platform_driver_register+0x50/0x64)
r5:c060b010 r4:ed8394c0
[<c025cc80>] (__platform_driver_register) from [<c060b028>] (rcar_vin_driver_init+0x18/0x20)
[<c060b010>] (rcar_vin_driver_init) from [<c05edde8>] (do_one_initcall+0x108/0x1b8)
[<c05edce0>] (do_one_initcall) from [<c05edfb4>] (kernel_init_freeable+0x11c/0x1e4)
r9:c066f9c0 r8:c066f9c0 r7:c062eab0 r6:c06252c4 r5:000000ad r4:00000006
[<c05ede98>] (kernel_init_freeable) from [<c048c3d0>] (kernel_init+0x10/0xec)
r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c048c3c0 r4:00000000
[<c048c3c0>] (kernel_init) from [<c000eba0>] (ret_from_fork+0x14/0x34)
r4:00000000 r3:ee04e000
---[ end trace e3a984cc0335c8a0 ]---
rcar_vin e6ef1000.video: group probe failed: -6
Fixes: 1ddc6a6 ("[media] soc_camera: add support for dt binding soc_camera drivers")
Cc: <[email protected]> # 3.17+
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Several (15) drivers in media/usb/gspca use IF_ENABLED(CONFIG_INPUT) to decide if they should call input* interfaces, but those drivers do not build successfully when CONFIG_INPUT=m and the gspca drivers are builtin (=y). Making USB_GSPCA depend on INPUT || INPUT=n fixes the build dependencies and allows all of them to build cleanly. Fixes these build errors (selections, not all are listed): drivers/built-in.o: In function `gspca_disconnect': (.text+0x32ed0f): undefined reference to `input_unregister_device' drivers/built-in.o: In function `sd_isoc_irq': konica.c:(.text+0x333098): undefined reference to `input_event' konica.c:(.text+0x3330ab): undefined reference to `input_event' drivers/built-in.o: In function `sd_stopN': konica.c:(.text+0x3338d3): undefined reference to `input_event' konica.c:(.text+0x3338e5): undefined reference to `input_event' drivers/built-in.o: In function `ov51x_handle_button': ov519.c:(.text+0x335ddb): undefined reference to `input_event' drivers/built-in.o:ov519.c:(.text+0x335ded): more undefined references to `input_event' follow pac7302.c:(.text+0x336ea1): undefined reference to `input_event' pac7302.c:(.text+0x336eb3): undefined reference to `input_event' drivers/built-in.o: In function `sd_pkt_scan': spca561.c:(.text+0x338fd8): undefined reference to `input_event' drivers/built-in.o:spca561.c:(.text+0x338feb): more undefined references to `input_event' follow t613.c:(.text+0x33a6fd): undefined reference to `input_event' drivers/built-in.o:t613.c:(.text+0x33a70f): more undefined references to `input_event' follow Signed-off-by: Randy Dunlap <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
To avoid garbage value written into image base address planes, initialize cb and cr of structure s5p_jpeg_addr to zero. Signed-off-by: Tony K Nadackal <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Building the s5p-tv HDMI support when CONFIG_I2C is disabled gives us this build error: s5p-tv/hdmi_drv.c: In function 'hdmi_probe': s5p-tv/hdmi_drv.c:947:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration] adapter = i2c_get_adapter(pdata->hdmiphy_bus); ^ This patch changes the Kconfig description to include I2C as a dependency for this driver, so it cannot be configured incorrectly. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
The first while loop in the function exynos3250_jpeg_reset had no chance to be executed because the reg variable was initialized to 0. Initialize reg variable to 1 to fix the issue. Signed-off-by: Jacek Anaszewski <[email protected]> Reported-by: Andrzej Pietrasiewicz <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
The patch "media: s5p-mfc: use vb2_ops_wait_prepare/finish helper" (654a731) introduced a kernel panic. The q->lock was set for just one queue, the other was not set thus causing a NULL pointer dereference. Reported-by: Marek Szyprowski <[email protected]> Signed-off-by: Kamil Debski <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it to platform_driver_register(), which can use the pointer at arbitrary times in the future, even after the initdata is freed. That leads to crashes. Move spear13xx_pcie_driver and things referenced by it (spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata. [bhelgaas: changelog] Fixes: 6675ef2 ("PCI: spear: Fix Section mismatch compilation warning for probe()") Signed-off-by: Matwey V. Kornilov <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Viresh Kumar <[email protected]> CC: [email protected] # v3.17+
Commit fab4c25 ("PCI/AER: Add a TLP header print helper") introduced the helper function __print_tlp_header(), but contrary to the intention, the behaviour did change: Since we're taking the address of the parameter t, the first 4 or 8 bytes printed will be the value of the pointer t itself, and the remaining 12 or 8 bytes will be who-knows-what (something from the stack). We want to show the values of the four members of the struct aer_header_log_regs; that can be done without ugly and error-prone casts. On little-endian this should produce the same output as originally intended, and since no-one has complained about getting garbage output so far, I think big-endian should be ok too. Fixes: fab4c25 ("PCI/AER: Add a TLP header print helper") Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Borislav Petkov <[email protected]> CC: [email protected] # v3.14+
I don't have this hardware but it looks like we weren't adding bridge devices as intended. Maybe the bridge is always the last device? Fixes: 05b1250 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Yijing Wang <[email protected]> CC: [email protected] # v3.9+
We have peculiar problems with multi-path and enclosures: physically, we know each bay can only be occupied by a single disk device. However in multi-path, it appears we have many (because each path to the device appears in Linux as a different kernel device). We try to fix this by only having the last seen device show up in the bay. Sysfs gets very annoyed if we try to manipulate links when the kobject sysfs directory (kobj.sd) doesn't exist and drops a huge WARN_ON which most users panic and report an oops for. This happens on a few path removal situations and IBM reports seeing it when one of their multi-path adapters is removed. Add a check to enclosure device removal for the existence the sysfs directory containing both the forward and back links so that the remnants (if any) get removed in either direction but no scary warnings are dumped. Reported-by: Wen Xiong <[email protected]> Tested-by: Wen Xiong <[email protected]> Signed-off-by: James Bottomley <[email protected]>
The v4l2_dev field of struct video_device must be set correctly. This was never done for this driver, so no video nodes were created anymore. Signed-off-by: Hans Verkuil <[email protected]> Cc: <[email protected]> # for v3.11 and up Signed-off-by: Mauro Carvalho Chehab <[email protected]>
cap->device_caps wasn't set in cx23885-417.c causing a warning from the v4l2-core. Reported-by: Joseph Jasi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Cc: <[email protected]> # for v3.19 and up Signed-off-by: Mauro Carvalho Chehab <[email protected]>
TASK_SIZE is depends on the systems architecture (32 or 64 bits) and it should not be used for defining offset boundary for mmaping buffers for CAPTURE and OUTPUT queues. This patch fixes support for MMAP calls on the CAPTURE queue on 64bit architectures (like ARM64). Cc: [email protected] Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Kamil Debski <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Unsigned int cannot be used to store casted pointer on 64bit architecture, so correct such casts to properly use unsigned long variables. Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Kamil Debski <[email protected]> [[email protected]: removed volatile and __iomem from cast] Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Before 4.0, reading attrib/emulate_fua_write has returned 1. Saved configs created on a pre-4.0 kernel will try to write that back when restoring LIO configuration. This should succeed with no effect, and issue a warning. See https://bugzilla.redhat.com/show_bug.cgi?id=1206184 Reported-by: Yanko Kaneti <[email protected]> Reported-by: Juan Quintela <[email protected]> Signed-off-by: Andy Grover <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]>
The last argument of vb2_dc_get_user_pages() is of type enum dma_data_direction, but the caller, vb2_dc_get_userptr() passes a value which is the result of comparison dma_dir == DMA_FROM_DEVICE. This results in the write parameter to get_user_pages() being zero in all cases, i.e. that the caller has no intent to write there. This was broken by patch "vb2: replace 'write' by 'dma_dir'". Signed-off-by: Sakari Ailus <[email protected]> Cc: [email protected] # for v3.19 Acked-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Caching register reads causes some random I/O errors on channel change. Disable caching now in order to avoid those errors. Reverts partly commit dcadb82 Signed-off-by: Antti Palosaari <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Return success for FE callback on case we don't have any special implementation. fc0013 tuner driver calls that callback in order to switch antenna input, even we don't provide antenna switch. Returning error caused fc0013 driver given up tuning. Signed-off-by: Antti Palosaari <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
All CPUs leaving the first-online CPU are hotplugged out on suspend and and cpufreq core stops managing them. On resume, we need to call cpufreq_update_policy() for this CPU's policy to make sure its frequency is in sync with cpufreq's cached value, as it might have got updated by hardware during suspend/resume. The policies are always added to the top of the policy-list. So, in normal circumstances, CPU 0's policy will be the last one in the list. And so the code checks for the last policy. But there are cases where it will fail. Consider quad-core system, with policy-per core. If CPU0 is hotplugged out and added back again, the last policy will be on CPU1 :( To fix this in a proper way, always look for the policy of the first online CPU. That way we will be sure that we are calling cpufreq_update_policy() for the only CPU that wasn't hotplugged out. Cc: 3.15+ <[email protected]> # 3.15+ Fixes: 2f0aea9 ("cpufreq: suspend governors on system suspend/hibernate") Reported-by: Saravana Kannan <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Acked-by: Saravana Kannan <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Thomas Schlichter reports the following issue on his Samsung NC20: "The C-states C1 and C2 to the OS when connected to AC, and additionally provides the C3 C-state when disconnected from AC. However, the number of C-states shown in sysfs is fixed to the number of C-states present at boot. If I boot with AC connected, I always only see the C-states up to C2 even if I disconnect AC. The reason is commit 130a5f6 (ACPI / cpuidle: remove dev->state_count setting). It removes the update of dev->state_count, but sysfs uses exactly this variable to show the C-states. The fix is to use drv->state_count in sysfs. As this is currently the last user of dev->state_count, this variable can be completely removed." Remove dev->state_count as per the above. Reported-by: Thomas Schlichter <[email protected]> Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Acked-by: Daniel Lezcano <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]>
Fix a bug that leads to showing the name and description of C-state C0 as "<null>" in sysfs after the ACPI C-states changed (e.g. after AC->DC or DC->AC transition). The function poll_idle_init() in drivers/cpuidle/driver.c initializes the state 0 during cpuidle_register_driver(), so we better do not overwrite it again with '\0' during acpi_processor_cst_has_changed(). Signed-off-by: Thomas Schlichter <[email protected]> Reviewed-by: Bartlomiej Zolnierkiewicz <[email protected]> Cc: 3.13+ <[email protected]> # 3.13+ Signed-off-by: Rafael J. Wysocki <[email protected]>
Dell new platform of ALC256 audio codec. Support headset mode for Dell ALC256 platform. Signed-off-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Adding this quirk allows us to avoid the noisy "cannot get freq at ep 0x1" message in dmesg output every time playback starts. This ought to affect other Benchmark DAC1 variations using the same "Microchip Technology, Inc." chip as well, but I have only tested with the "Pre" variant. Signed-off-by: Eric Wong <[email protected]> Cc: Joe Turner <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
teach ->mremap() method to return an error and have it fail for aio mappings in process of being killed Note that in case of ->mremap() failure we need to undo move_page_tables() we'd already done; we could call ->mremap() first, but then the failure of move_page_tables() would require undoing whatever _successful_ ->mremap() has done, which would be a lot more headache in general. Signed-off-by: Al Viro <[email protected]>
If we fail past the aio_setup_ring(), we need to destroy the mapping. We don't need to care about anybody having found ctx, or added requests to it, since the last failure exit is exactly the failure to make ctx visible to lookups. Reproducer (based on one by Joe Mario <[email protected]>): void count(char *p) { char s[80]; printf("%s: ", p); fflush(stdout); sprintf(s, "/bin/cat /proc/%d/maps|/bin/fgrep -c '/[aio] (deleted)'", getpid()); system(s); } int main() { io_context_t *ctx; int created, limit, i, destroyed; FILE *f; count("before"); if ((f = fopen("/proc/sys/fs/aio-max-nr", "r")) == NULL) perror("opening aio-max-nr"); else if (fscanf(f, "%d", &limit) != 1) fprintf(stderr, "can't parse aio-max-nr\n"); else if ((ctx = calloc(limit, sizeof(io_context_t))) == NULL) perror("allocating aio_context_t array"); else { for (i = 0, created = 0; i < limit; i++) { if (io_setup(1000, ctx + created) == 0) created++; } for (i = 0, destroyed = 0; i < created; i++) if (io_destroy(ctx[i]) == 0) destroyed++; printf("created %d, failed %d, destroyed %d\n", created, limit - created, destroyed); count("after"); } } Found-by: Joe Mario <[email protected]> Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
Commit 84c91b7 (PM / hibernate: avoid unsafe pages in e820 reserved regions) is reported to make resume from hibernation on Lenovo x230 unreliable, so revert it. We will revisit the issue the commit in question was supposed to fix in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96111 Reported-by: rhn <[email protected]> Cc: 3.17+ <[email protected]> # 3.17+ Signed-off-by: Rafael J. Wysocki <[email protected]>
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <[email protected]> Tested-by: Darren Hart <[email protected]> Cc: [email protected] Reviewed-by: Imre Deak <[email protected]> Reviewed-by: Deepak S <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: Deepak S <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
* pm-sleep: Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions" * pm-cpufreq: cpufreq: Schedule work for the first-online CPU on resume * pm-cpuidle: cpuidle: ACPI: do not overwrite name and description of C0 cpuidle: remove state_count field from struct cpuidle_device
…nel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"These are stable-candidate fixes of some recently reported issues in
the cpufreq core, cpuidle core, the ACPI cpuidle driver and the
hibernate core.
Specifics:
- Revert a 3.17 hibernate commit that was supposed to fix an issue
related to e820 reserved regions, but broke resume from hibernation
on Lenovo x230 (Rafael J Wysocki).
- Prevent the ACPI cpuidle driver from overwriting the name and
description of the C0 state set by the core when the list of
C-states changes (Thomas Schlichter).
- Remove the no longer needed state_count field from struct
cpuidle_device which prevents the list of C-states shown by the
sysfs interface from becoming incorrect when the current number of
them is different from the number of C-states on boot (Bartlomiej
Zolnierkiewicz).
- The cpufreq core updates the policy object of the only online CPU
during system resume to make it reflect the current hardware state,
but it always assumes that CPU to be CPU0 which need not be the
case, so fix the code to avoid that assumption (Viresh Kumar)"
* tag 'pm+acpi-4.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
Revert "PM / hibernate: avoid unsafe pages in e820 reserved regions"
cpuidle: ACPI: do not overwrite name and description of C0
cpuidle: remove state_count field from struct cpuidle_device
cpufreq: Schedule work for the first-online CPU on resume
Remove the end address checking for flushda function. We need to flush each address line for flushda instruction, from start to end address. This is because flushda instruction only flush the cache if tag and line fields are matched. Change to use ldwio instruction (bypass cache) to load the instruction that causing trap. Our interest is the actual instruction that executed by the processor, this should be uncached. Note, EA address might be an userspace cached address. Signed-off-by: Ley Foon Tan <[email protected]>
…x-socfpga-next
Pull arch/nios2 fixes from Ley Foon Tan:
"There are 3 arch/nios2 fixes for 4.0 final:
- fix cache coherency issue when debugging with gdb
- move restart_block to struct task_struct (aligned with other
architectures)
- fix for missing registers defines for ptrace"
* tag 'nios2-fixes-v4.0-final' of git://git.rocketboards.org/linux-socfpga-next:
nios2: fix cache coherency issue when debug with gdb
nios2: add missing ptrace registers defines
nios2: signal: Move restart_block to struct task_struct
…t/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are fixes gathered for 4.0-final; one FireFire endian fix, two USB-audio quirks, and three HD-audio quirks. All relatively small and device-specific fixes, should be pretty safe to apply" * tag 'sound-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support ALSA: hda - Fix headphone pin config for Lifebook T731 ALSA: bebob: fix to processing in big-endian machine for sending cue ALSA: hda/realtek - Make more stable to get pin sense for ALC283 ALSA: usb-audio: don't try to get Benchmark DAC1 sample rate ALSA: hda/realtek - Support Dell headset mode for ALC256
This fixes a oops due to a double list add when adding a reject PDU for iscsit_allocate_iovecs allocation failures. The cmd has already been added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call iscsit_reject_cmd. Note that for ERL0 the reject PDU is not actually sent, so this patch is not completely tested. Just verified we do not oops. The problem is the add reject functions return -1 which is returned all the way up to iscsi_target_rx_thread which for ERL0 will drop the connection. Signed-off-by: Mike Christie <[email protected]> Cc: <[email protected]> # v3.10+ Signed-off-by: Nicholas Bellinger <[email protected]>
Pull SCSI target fixes from Nicholas Bellinger: "Just a few small fixes: Two from Andy, the first addresses a v4.0 target specific regression to a user visible configfs attribute, and the second adds a set of missing brackets around IPv6 discovery portal information within iscsi-target. And one from Mike that fixes an OOPs regression in traditional iscsi-target when an iovec allocation fails, that has been present since v3.10.y code. (CC'd to stable)" * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: iscsi target: fix oops when adding reject pdu iscsi-target: TargetAddress in SendTargets should bracket ipv6 addresses target: Allow userspace to write 1 to attrib/emulate_fua_write
…it/jejb/scsi Pull SCSI fixes from James Bottomley: "This is our remaining set of three fixes for 4.0: two oops fixes(one for cable pulls triggering oopses and the other be2iscsi specific) and one warn on in sysfs on multipath devices using enclosures" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: Defer processing of REQ_PREEMPT requests for blocked devices be2iscsi: Fix kernel panic when device initialization fails enclosure: fix WARN_ON removing an adapter in multi-path devices
Some BMCs don't let you clear the receive irq bit in the global enables. This is kind of silly, but they give an error if you try to clear it. Compensate for this by detecting the situation and working around it. Signed-off-by: Corey Minyard <[email protected]> Tested-by: Thomas D <[email protected]> Reviewed-by: Thomas D <[email protected]>
If ipmi_powernv_recv(...) is called without a current message it prints a warning and returns. However it fails to release the message lock causing the system to dead lock during any subsequent IPMI operations. This error path should never normally be taken unless there are bugs elsewhere in the system. Signed-off-by: Alistair Popple <[email protected]> Signed-off-by: Corey Minyard <[email protected]>
The code was using an normal completion, but that caused stuck task errors after a while. Use an interruptible one to avoid that. Signed-off-by: Corey Minyard <[email protected]>
Add missing directions, residue_granularity, srd_addr_widths and dst_addr_widths bitfields. Without those we will see a kernel WARN() when loading musb on am335x devices. Signed-off-by: Felipe Balbi <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
…-ipmi Pull late ipmi fixes from Corey Minyard: "Some annoying issues in the IPMI driver that would be good to have fixed before 4.0 is released. These got reported or discovered late, but they will avoid some situations that would cause lots of log spam and in one case a deadlock" * tag 'for-linus-4.0-1' of git://git.code.sf.net/p/openipmi/linux-ipmi: ipmi_ssif: Use interruptible completion for waiting in the thread ipmi/powernv: Fix minor locking bug ipmi: Handle BMCs that don't allow clearing the rcv irq bit
Pull dmaengine fix from Vinod Koul: "I have one more fix to fix the boot warning on cppi driver due to missing capabilities" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: cppi41: add missing bitfields
Jan Engelhardt reports a strange oops with an invalid ->sense_buffer pointer in scsi_init_cmd_errh() with the blk-mq code. The sense_buffer pointer should have been initialized by the call to scsi_init_request() from blk_mq_init_rq_map(), but there seems to be some non-repeatable memory corruptor. This patch makes sure we initialize the whole struct request allocation (and the associated 'struct scsi_cmnd' for the SCSI case) to zero, by using __GFP_ZERO in the allocation. The old code initialized a couple of individual fields, leaving the rest undefined (although many of them are then initialized in later phases, like blk_mq_rq_ctx_init() etc. It's not entirely clear why this matters, but it's the rigth thing to do regardless, and with 4.0 imminent this is the defensive "let's just make sure everything is initialized properly" patch. Tested-by: Jan Engelhardt <[email protected]> Acked-by: Jens Axboe <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
…ave caps retrieval" This reverts commit ecc19d1. It added a new warning to try to encourage driver writers to set the device capabities properly, but drivers haven't been updated and in the meantime it just generaters a scary message that users cannot actually do anything about. Warnings like these are appropriate if you actually expect to fix the code that causes them. They are not appropriate for releases. Requested-by: Peter Hurley <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Currently GPIO4 is hardcoded to output the pll-lock signal. Unfortunately this is after the pll-out GPIO is configured which is selectable in the device tree. Therefore it is not possible to use GPIO4 for pll-out. Therefore this patch removes the configuration of GPIO4. Signed-off-by: Howard Mitchell <[email protected]> Signed-off-by: Mark Brown <[email protected]>
…ernel/git/broonie/sound Pull last-minute ASoC fix from Mark Brown: "This patch backs out a change that came in during the merge window which selects a configuration for GPIO4 on pcm512x CODECs that may not be suitable for all systems using the device. Changes for v4.1 will make this properly configurable but for now it's safest to revert to the v3.19 behaviour and leave the pin configuration alone. Sorry for sending this direct at the last minute but due to the GPIO misuse it'd be really good to get it in the release and I'd not realised it hadn't been sent yet - between some travel, a job change and other non-urgent fixes coming in I'd lost track of the urgency. It's been in -next for several weeks now, is isolated to the driver and fairly clear to inspection" * tag 'asoc-fix-v4.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound: ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4
…/evalenti/linux-soc-thermal Pull last minute thermal-SoC management fixes from Eduardo Valentin: "Specifics: - Minor fixes on ST and RCAR thermal drivers. - Avoid flooding kernel log when driver returns -EAGAIN. Note: I am sending this pull on Rui's behalf while he fixes issues in his Linux box" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal: drivers: thermal: st: remove several sparse warnings thermal: constify of_device_id array thermal: Do not log an error if thermal_zone_get_temp returns -EAGAIN thermal: rcar: Fix typo in r8a73a4 SoC name
…/git/viro/vfs Pull vfs and fs fixes from Al Viro: "Several AIO and OCFS2 fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ocfs2: _really_ sync the right range ocfs2_file_write_iter: keep return value and current position update in sync [regression] ocfs2: do *not* increment ->ki_pos twice ioctx_alloc(): fix vma (and file) leak on failure fix mremap() vs. ioctx_kill() race
dabrace
pushed a commit
that referenced
this pull request
Sep 3, 2015
The problem is rcu_read_unlock_bh() which triggers a warning when irqs are disabled. ndo_poll_controller should run with irqs disabled always so we can drop the rcu_read_lock_bh. [ 98.502922] bond0: making interface eth1 the new active one [ 98.503039] ------------[ cut here ]------------ [ 98.503039] WARNING: CPU: 0 PID: 1744 at kernel/softirq.c:150 __local_bh_enable_ip+0x96/0xc0() [ 98.503039] Modules linked in: bonding(OE) rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache netconsole ppdev joydev parport_pc serio_raw parport i2c_piix4 video acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc virtio_net e1000 ata_generic pcnet32 mii virtio_pci virtio_ring virtio pata_acpi [ 98.503039] CPU: 0 PID: 1744 Comm: ifenslave Tainted: G OE 4.2.0-rc7+ #56 [ 98.503039] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 98.503039] 0000000000000000 00000000e96ba230 ffff880020c236b8 ffffffff8183f105 [ 98.503039] 0000000000000000 0000000000000000 ffff880020c236f8 ffffffff810a9496 [ 98.503039] ffff88002ea99e08 0000000000000200 ffffffffa02a8e06 ffff88002ea99e08 [ 98.503039] Call Trace: [ 98.503039] [<ffffffff8183f105>] dump_stack+0x4c/0x65 [ 98.503039] [<ffffffff810a9496>] warn_slowpath_common+0x86/0xc0 [ 98.503039] [<ffffffffa02a8e06>] ? bond_poll_controller+0x146/0x250 [bonding] [ 98.503039] [<ffffffff810a95ca>] warn_slowpath_null+0x1a/0x20 [ 98.503039] [<ffffffff810ae376>] __local_bh_enable_ip+0x96/0xc0 [ 98.503039] [<ffffffffa02a8e2f>] bond_poll_controller+0x16f/0x250 [bonding] [ 98.503039] [<ffffffffa02a8cf3>] ? bond_poll_controller+0x33/0x250 [bonding] [ 98.503039] [<ffffffff810feaed>] ? trace_hardirqs_off+0xd/0x10 [ 98.503039] [<ffffffff81848afb>] ? _raw_spin_unlock_irqrestore+0x5b/0x60 [ 98.503039] [<ffffffff816ec48e>] netpoll_poll_dev+0x6e/0x350 [ 98.503039] [<ffffffff816eb977>] ? netpoll_start_xmit+0x137/0x1d0 [ 98.503039] [<ffffffff816b2e8b>] ? __alloc_skb+0x5b/0x210 [ 98.503039] [<ffffffff816ec89d>] netpoll_send_skb_on_dev+0x12d/0x2a0 [ 98.503039] [<ffffffff816eccde>] netpoll_send_udp+0x2ce/0x430 [ 98.503039] [<ffffffffa0190850>] write_msg+0xb0/0xf0 [netconsole] [ 98.503039] [<ffffffff81116b63>] call_console_drivers.constprop.25+0x133/0x260 [ 98.503039] [<ffffffff81117934>] console_unlock+0x2f4/0x580 [ 98.503039] [<ffffffff81117ea5>] ? vprintk_emit+0x2e5/0x630 [ 98.503039] [<ffffffff81117ee5>] vprintk_emit+0x325/0x630 [ 98.503039] [<ffffffff81118379>] vprintk_default+0x29/0x40 [ 98.503039] [<ffffffff8183de4f>] printk+0x55/0x6b [ 98.503039] [<ffffffff816c754c>] __netdev_printk+0x16c/0x260 [ 98.503039] [<ffffffff816c7a12>] netdev_info+0x62/0x80 [ 98.503039] [<ffffffffa02ab464>] bond_change_active_slave+0x134/0x6a0 [bonding] [ 98.503039] [<ffffffffa02aba95>] bond_select_active_slave+0xc5/0x310 [bonding] [ 98.503039] [<ffffffffa02aeb78>] bond_enslave+0x1088/0x10c0 [bonding] [ 98.503039] [<ffffffffa02af46b>] bond_do_ioctl+0x37b/0x400 [bonding] [ 98.503039] [<ffffffff81101d8d>] ? trace_hardirqs_on+0xd/0x10 [ 98.503039] [<ffffffff816dc437>] ? rtnl_lock+0x17/0x20 [ 98.503039] [<ffffffff816e5fd1>] dev_ifsioc+0x331/0x3e0 [ 98.503039] [<ffffffff816e62dc>] dev_ioctl+0xec/0x6c0 [ 98.503039] [<ffffffff816a6c6a>] sock_do_ioctl+0x4a/0x60 [ 98.503039] [<ffffffff816a7300>] sock_ioctl+0x1c0/0x250 [ 98.503039] [<ffffffff81271bfe>] do_vfs_ioctl+0x2ee/0x540 [ 98.503039] [<ffffffff810fd943>] ? up_read+0x23/0x40 [ 98.503039] [<ffffffff81070993>] ? __do_page_fault+0x1d3/0x420 [ 98.503039] [<ffffffff8127e246>] ? __fget_light+0x66/0x90 [ 98.503039] [<ffffffff81271ec9>] SyS_ioctl+0x79/0x90 [ 98.503039] [<ffffffff8184936e>] entry_SYSCALL_64_fastpath+0x12/0x76 [ 98.503039] ---[ end trace 00cfa804b0670051 ]--- Fixes: 616f454 ("bonding: implement bond_poll_controller()") Signed-off-by: Nikolay Aleksandrov <[email protected]> Acked-by: Mahesh Bandewar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Jul 31, 2017
The following warning was triggered by missing srcu locks around the storage key handling functions. ============================= WARNING: suspicious RCU usage 4.12.0+ #56 Not tainted ----------------------------- ./include/linux/kvm_host.h:572 suspicious rcu_dereference_check() usage! rcu_scheduler_active = 2, debug_locks = 1 1 lock held by live_migration/4936: #0: (&mm->mmap_sem){++++++}, at: [<0000000000141be0>] kvm_arch_vm_ioctl+0x6b8/0x22d0 CPU: 8 PID: 4936 Comm: live_migration Not tainted 4.12.0+ #56 Hardware name: IBM 2964 NC9 704 (LPAR) Call Trace: ([<000000000011378a>] show_stack+0xea/0xf0) [<000000000055cc4c>] dump_stack+0x94/0xd8 [<000000000012ee70>] gfn_to_memslot+0x1a0/0x1b8 [<0000000000130b76>] gfn_to_hva+0x2e/0x48 [<0000000000141c3c>] kvm_arch_vm_ioctl+0x714/0x22d0 [<000000000013306c>] kvm_vm_ioctl+0x11c/0x7b8 [<000000000037e2c0>] do_vfs_ioctl+0xa8/0x6c8 [<000000000037e984>] SyS_ioctl+0xa4/0xb8 [<00000000008b20a4>] system_call+0xc4/0x27c 1 lock held by live_migration/4936: #0: (&mm->mmap_sem){++++++}, at: [<0000000000141be0>] kvm_arch_vm_ioctl+0x6b8/0x22d0 Signed-off-by: Christian Borntraeger <[email protected]> Reviewed-by: Pierre Morel<[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Sep 5, 2017
The below commit added a call to ->destroy() on init failure, but multiq still frees ->queues on error in init, but ->queues is also freed by ->destroy() thus we get double free and corrupted memory. Very easy to reproduce (eth0 not multiqueue): $ tc qdisc add dev eth0 root multiq RTNETLINK answers: Operation not supported $ ip l add dumdum type dummy (crash) Trace log: [ 3929.467747] general protection fault: 0000 [#1] SMP [ 3929.468083] Modules linked in: [ 3929.468302] CPU: 3 PID: 967 Comm: ip Not tainted 4.13.0-rc6+ #56 [ 3929.468625] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 3929.469124] task: ffff88003716a700 task.stack: ffff88005872c000 [ 3929.469449] RIP: 0010:__kmalloc_track_caller+0x117/0x1be [ 3929.469746] RSP: 0018:ffff88005872f6a0 EFLAGS: 00010246 [ 3929.470042] RAX: 00000000000002de RBX: 0000000058a59000 RCX: 00000000000002df [ 3929.470406] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff821f7020 [ 3929.470770] RBP: ffff88005872f6e8 R08: 000000000001f010 R09: 0000000000000000 [ 3929.471133] R10: ffff88005872f730 R11: 0000000000008cdd R12: ff006d75646d7564 [ 3929.471496] R13: 00000000014000c0 R14: ffff88005b403c00 R15: ffff88005b403c00 [ 3929.471869] FS: 00007f0b70480740(0000) GS:ffff88005d980000(0000) knlGS:0000000000000000 [ 3929.472286] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3929.472677] CR2: 00007ffcee4f3000 CR3: 0000000059d45000 CR4: 00000000000406e0 [ 3929.473209] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3929.474109] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3929.474873] Call Trace: [ 3929.475337] ? kstrdup_const+0x23/0x25 [ 3929.475863] kstrdup+0x2e/0x4b [ 3929.476338] kstrdup_const+0x23/0x25 [ 3929.478084] __kernfs_new_node+0x28/0xbc [ 3929.478478] kernfs_new_node+0x35/0x55 [ 3929.478929] kernfs_create_link+0x23/0x76 [ 3929.479478] sysfs_do_create_link_sd.isra.2+0x85/0xd7 [ 3929.480096] sysfs_create_link+0x33/0x35 [ 3929.480649] device_add+0x200/0x589 [ 3929.481184] netdev_register_kobject+0x7c/0x12f [ 3929.481711] register_netdevice+0x373/0x471 [ 3929.482174] rtnl_newlink+0x614/0x729 [ 3929.482610] ? rtnl_newlink+0x17f/0x729 [ 3929.483080] rtnetlink_rcv_msg+0x188/0x197 [ 3929.483533] ? rcu_read_unlock+0x3e/0x5f [ 3929.483984] ? rtnl_newlink+0x729/0x729 [ 3929.484420] netlink_rcv_skb+0x6c/0xce [ 3929.484858] rtnetlink_rcv+0x23/0x2a [ 3929.485291] netlink_unicast+0x103/0x181 [ 3929.485735] netlink_sendmsg+0x326/0x337 [ 3929.486181] sock_sendmsg_nosec+0x14/0x3f [ 3929.486614] sock_sendmsg+0x29/0x2e [ 3929.486973] ___sys_sendmsg+0x209/0x28b [ 3929.487340] ? do_raw_spin_unlock+0xcd/0xf8 [ 3929.487719] ? _raw_spin_unlock+0x27/0x31 [ 3929.488092] ? __handle_mm_fault+0x651/0xdb1 [ 3929.488471] ? check_chain_key+0xb0/0xfd [ 3929.488847] __sys_sendmsg+0x45/0x63 [ 3929.489206] ? __sys_sendmsg+0x45/0x63 [ 3929.489576] SyS_sendmsg+0x19/0x1b [ 3929.489901] entry_SYSCALL_64_fastpath+0x23/0xc2 [ 3929.490172] RIP: 0033:0x7f0b6fb93690 [ 3929.490423] RSP: 002b:00007ffcee4ed588 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 3929.490881] RAX: ffffffffffffffda RBX: ffffffff810d278c RCX: 00007f0b6fb93690 [ 3929.491198] RDX: 0000000000000000 RSI: 00007ffcee4ed5d0 RDI: 0000000000000003 [ 3929.491521] RBP: ffff88005872ff98 R08: 0000000000000001 R09: 0000000000000000 [ 3929.491801] R10: 00007ffcee4ed350 R11: 0000000000000246 R12: 0000000000000002 [ 3929.492075] R13: 000000000066f1a0 R14: 00007ffcee4f5680 R15: 0000000000000000 [ 3929.492352] ? trace_hardirqs_off_caller+0xa7/0xcf [ 3929.492590] Code: 8b 45 c0 48 8b 45 b8 74 17 48 8b 4d c8 83 ca ff 44 89 ee 4c 89 f7 e8 83 ca ff ff 49 89 c4 eb 49 49 63 56 20 48 8d 48 01 4d 8b 06 <49> 8b 1c 14 48 89 c2 4c 89 e0 65 49 0f c7 08 0f 94 c0 83 f0 01 [ 3929.493335] RIP: __kmalloc_track_caller+0x117/0x1be RSP: ffff88005872f6a0 Fixes: 87b60cf ("net_sched: fix error recovery at qdisc creation") Fixes: f07d150 ("multiq: Further multiqueue cleanup") Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Nov 13, 2017
A CDC Ethernet functional descriptor with wMaxSegmentSize = 0 will cause a divide error in usbnet_probe: divide error: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bef5c00 task.stack: ffff88006bf60000 RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355 RSP: 0018:ffff88006bf67508 EFLAGS: 00010246 RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34 RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34 RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881 R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003 R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0 Call Trace: usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x522/0x740 drivers/base/dd.c:557 Fix by simply ignoring the bogus descriptor, as it is optional for QMI devices anyway. Fixes: 423ce8c ("net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices") Reported-by: Andrey Konovalov <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Feb 27, 2018
The race is between lookup_get_idr_uobject and uverbs_idr_remove_uobj -> uverbs_uobject_put. We deliberately do not call sychronize_rcu after the idr_remove in uverbs_idr_remove_uobj for performance reasons, instead we call kfree_rcu() during uverbs_uobject_put. However, this means we can obtain pointers to uobj's that have already been released and must protect against krefing them using kref_get_unless_zero. ================================================================== BUG: KASAN: use-after-free in copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 Read of size 4 at addr ffff88005fda1ac8 by task syz-executor2/441 CPU: 1 PID: 441 Comm: syz-executor2 Not tainted 4.15.0-rc2+ #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0x8d/0xd4 print_address_description+0x73/0x290 kasan_report+0x25c/0x370 ? copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 copy_ah_attr_from_uverbs.isra.2+0x860/0xa00 ? uverbs_try_lock_object+0x68/0xc0 ? modify_qp.isra.7+0xdc4/0x10e0 modify_qp.isra.7+0xdc4/0x10e0 ib_uverbs_modify_qp+0xfe/0x170 ? ib_uverbs_query_qp+0x970/0x970 ? __lock_acquire+0xa11/0x1da0 ib_uverbs_write+0x55a/0xad0 ? ib_uverbs_query_qp+0x970/0x970 ? ib_uverbs_query_qp+0x970/0x970 ? ib_uverbs_open+0x760/0x760 ? futex_wake+0x147/0x410 ? sched_clock_cpu+0x18/0x180 ? check_prev_add+0x1680/0x1680 ? do_futex+0x3b6/0xa30 ? sched_clock_cpu+0x18/0x180 __vfs_write+0xf7/0x5c0 ? ib_uverbs_open+0x760/0x760 ? kernel_read+0x110/0x110 ? lock_acquire+0x370/0x370 ? __fget+0x264/0x3b0 vfs_write+0x18a/0x460 SyS_write+0xc7/0x1a0 ? SyS_read+0x1a0/0x1a0 ? trace_hardirqs_on_thunk+0x1a/0x1c entry_SYSCALL_64_fastpath+0x18/0x85 RIP: 0033:0x448e29 RSP: 002b:00007f443fee0c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f443fee16bc RCX: 0000000000448e29 RDX: 0000000000000078 RSI: 00000000209f8000 RDI: 0000000000000012 RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000008e98 R14: 00000000006ebf38 R15: 0000000000000000 Allocated by task 1: kmem_cache_alloc_trace+0x16c/0x2f0 mlx5_alloc_cmd_msg+0x12e/0x670 cmd_exec+0x419/0x1810 mlx5_cmd_exec+0x40/0x70 mlx5_core_mad_ifc+0x187/0x220 mlx5_MAD_IFC+0xd7/0x1b0 mlx5_query_mad_ifc_gids+0x1f3/0x650 mlx5_ib_query_gid+0xa4/0xc0 ib_query_gid+0x152/0x1a0 ib_query_port+0x21e/0x290 mlx5_port_immutable+0x30f/0x490 ib_register_device+0x5dd/0x1130 mlx5_ib_add+0x3e7/0x700 mlx5_add_device+0x124/0x510 mlx5_register_interface+0x11f/0x1c0 mlx5_ib_init+0x56/0x61 do_one_initcall+0xa3/0x250 kernel_init_freeable+0x309/0x3b8 kernel_init+0x14/0x180 ret_from_fork+0x24/0x30 Freed by task 1: kfree+0xeb/0x2f0 mlx5_free_cmd_msg+0xcd/0x140 cmd_exec+0xeba/0x1810 mlx5_cmd_exec+0x40/0x70 mlx5_core_mad_ifc+0x187/0x220 mlx5_MAD_IFC+0xd7/0x1b0 mlx5_query_mad_ifc_gids+0x1f3/0x650 mlx5_ib_query_gid+0xa4/0xc0 ib_query_gid+0x152/0x1a0 ib_query_port+0x21e/0x290 mlx5_port_immutable+0x30f/0x490 ib_register_device+0x5dd/0x1130 mlx5_ib_add+0x3e7/0x700 mlx5_add_device+0x124/0x510 mlx5_register_interface+0x11f/0x1c0 mlx5_ib_init+0x56/0x61 do_one_initcall+0xa3/0x250 kernel_init_freeable+0x309/0x3b8 kernel_init+0x14/0x180 ret_from_fork+0x24/0x30 The buggy address belongs to the object at ffff88005fda1ab0 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 24 bytes inside of 32-byte region [ffff88005fda1ab0, ffff88005fda1ad0) The buggy address belongs to the page: page:00000000d5655c19 count:1 mapcount:0 mapping: (null) index:0xffff88005fda1fc0 flags: 0x4000000000000100(slab) raw: 4000000000000100 0000000000000000 ffff88005fda1fc0 0000000180550008 raw: ffffea00017f6780 0000000400000004 ffff88006c803980 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88005fda1980: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb ffff88005fda1a00: fb fb fc fc fb fb fb fb fc fc 00 00 00 00 fc fc ffff88005fda1a80: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb ffff88005fda1b00: fc fc 00 00 00 00 fc fc fb fb fb fb fc fc fb fb ffff88005fda1b80: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc ==================================================================@ Cc: syzkaller <[email protected]> Cc: <[email protected]> # 4.11 Fixes: 3832125 ("IB/core: Add support for idr types") Reported-by: Noa Osherovich <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Jan 2, 2020
…isten() With multi-transport support, listener sockets are not bound to any transport. So, calling virtio_transport_reset(), when an error occurs, on a listener socket produces the following null-pointer dereference: BUG: kernel NULL pointer dereference, address: 00000000000000e8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.5.0-rc1-ste-00003-gb4be21f316ac-dirty #56 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport] RIP: 0010:virtio_transport_send_pkt_info+0x20/0x130 [vmw_vsock_virtio_transport_common] Code: 1f 84 00 00 00 00 00 0f 1f 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 49 89 fc 53 48 83 ec 10 44 8b 76 20 e8 c0 ba fe ff <48> 8b 80 e8 00 00 00 e8 64 e3 7d c1 45 8b 45 00 41 8b 8c 24 d4 02 RSP: 0018:ffffc900000b7d08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88807bf12728 RCX: 0000000000000000 RDX: ffff88807bf12700 RSI: ffffc900000b7d50 RDI: ffff888035c84000 RBP: ffffc900000b7d40 R08: ffff888035c84000 R09: ffffc900000b7d08 R10: ffff8880781de800 R11: 0000000000000018 R12: ffff888035c84000 R13: ffffc900000b7d50 R14: 0000000000000000 R15: ffff88807bf12724 FS: 0000000000000000(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e8 CR3: 00000000790f4004 CR4: 0000000000160ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: virtio_transport_reset+0x59/0x70 [vmw_vsock_virtio_transport_common] virtio_transport_recv_pkt+0x5bb/0xe50 [vmw_vsock_virtio_transport_common] ? detach_buf_split+0xf1/0x130 virtio_transport_rx_work+0xba/0x130 [vmw_vsock_virtio_transport] process_one_work+0x1c0/0x300 worker_thread+0x45/0x3c0 kthread+0xfc/0x130 ? current_work+0x40/0x40 ? kthread_park+0x90/0x90 ret_from_fork+0x35/0x40 Modules linked in: sunrpc kvm_intel kvm vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common irqbypass vsock virtio_rng rng_core CR2: 00000000000000e8 ---[ end trace e75400e2ea2fa824 ]--- This happens because virtio_transport_reset() calls virtio_transport_send_pkt_info() that can be used only on connecting/connected sockets. This patch fixes the issue, using virtio_transport_reset_no_sock() instead of virtio_transport_reset() when we are handling a listener socket. Fixes: c0cfa2d ("vsock: add multi-transports support") Signed-off-by: Stefano Garzarella <[email protected]> Signed-off-by: David S. Miller <[email protected]>
dabrace
pushed a commit
that referenced
this pull request
Jan 25, 2021
I was hitting the below panic continuously when attaching kprobes to scheduler functions [ 159.045212] Unexpected kernel BRK exception at EL1 [ 159.053753] Internal error: BRK handler: f2000006 [#1] PREEMPT SMP [ 159.059954] Modules linked in: [ 159.063025] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.11.0-rc4-00008-g1e2a199f6ccd #56 [rt-app] <notice> [1] Exiting.[ 159.071166] Hardware name: ARM Juno development board (r2) (DT) [ 159.079689] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO BTYPE=--) [ 159.085723] pc : 0xffff80001624501c [ 159.089377] lr : attach_entity_load_avg+0x2ac/0x350 [ 159.094271] sp : ffff80001622b640 [rt-app] <notice> [0] Exiting.[ 159.097591] x29: ffff80001622b640 x28: 0000000000000001 [ 159.105515] x27: 0000000000000049 x26: ffff000800b79980 [ 159.110847] x25: ffff00097ef37840 x24: 0000000000000000 [ 159.116331] x23: 00000024eacec1ec x22: ffff00097ef12b90 [ 159.121663] x21: ffff00097ef37700 x20: ffff800010119170 [rt-app] <notice> [11] Exiting.[ 159.126995] x19: ffff00097ef37840 x18: 000000000000000e [ 159.135003] x17: 0000000000000001 x16: 0000000000000019 [ 159.140335] x15: 0000000000000000 x14: 0000000000000000 [ 159.145666] x13: 0000000000000002 x12: 0000000000000002 [ 159.150996] x11: ffff80001592f9f0 x10: 0000000000000060 [ 159.156327] x9 : ffff8000100f6f9c x8 : be618290de0999a1 [ 159.161659] x7 : ffff80096a4b1000 x6 : 0000000000000000 [ 159.166990] x5 : ffff00097ef37840 x4 : 0000000000000000 [ 159.172321] x3 : ffff000800328948 x2 : 0000000000000000 [ 159.177652] x1 : 0000002507d52fec x0 : ffff00097ef12b90 [ 159.182983] Call trace: [ 159.185433] 0xffff80001624501c [ 159.188581] update_load_avg+0x2d0/0x778 [ 159.192516] enqueue_task_fair+0x134/0xe20 [ 159.196625] enqueue_task+0x4c/0x2c8 [ 159.200211] ttwu_do_activate+0x70/0x138 [ 159.204147] sched_ttwu_pending+0xbc/0x160 [ 159.208253] flush_smp_call_function_queue+0x16c/0x320 [ 159.213408] generic_smp_call_function_single_interrupt+0x1c/0x28 [ 159.219521] ipi_handler+0x1e8/0x3c8 [ 159.223106] handle_percpu_devid_irq+0xd8/0x460 [ 159.227650] generic_handle_irq+0x38/0x50 [ 159.231672] __handle_domain_irq+0x6c/0xc8 [ 159.235781] gic_handle_irq+0xcc/0xf0 [ 159.239452] el1_irq+0xb4/0x180 [ 159.242600] rcu_is_watching+0x28/0x70 [ 159.246359] rcu_read_lock_held_common+0x44/0x88 [ 159.250991] rcu_read_lock_any_held+0x30/0xc0 [ 159.255360] kretprobe_dispatcher+0xc4/0xf0 [ 159.259555] __kretprobe_trampoline_handler+0xc0/0x150 [ 159.264710] trampoline_probe_handler+0x38/0x58 [ 159.269255] kretprobe_trampoline+0x70/0xc4 [ 159.273450] run_rebalance_domains+0x54/0x80 [ 159.277734] __do_softirq+0x164/0x684 [ 159.281406] irq_exit+0x198/0x1b8 [ 159.284731] __handle_domain_irq+0x70/0xc8 [ 159.288840] gic_handle_irq+0xb0/0xf0 [ 159.292510] el1_irq+0xb4/0x180 [ 159.295658] arch_cpu_idle+0x18/0x28 [ 159.299245] default_idle_call+0x9c/0x3e8 [ 159.303265] do_idle+0x25c/0x2a8 [ 159.306502] cpu_startup_entry+0x2c/0x78 [ 159.310436] secondary_start_kernel+0x160/0x198 [ 159.314984] Code: d42000c0 aa1e03e9 d42000c0 aa1e03e9 (d42000c0) After a bit of head scratching and debugging it turned out that it is due to kprobe handler being interrupted by a tick that causes us to go into (I think another) kprobe handler. The culprit was kprobe_breakpoint_ss_handler() returning DBG_HOOK_ERROR which leads to the Unexpected kernel BRK exception. Reverting commit ba090f9 ("arm64: kprobes: Remove redundant kprobe_step_ctx") seemed to fix the problem for me. Further analysis showed that kcb->kprobe_status is set to KPROBE_REENTER when the error occurs. By teaching kprobe_breakpoint_ss_handler() to handle this status I can no longer reproduce the problem. Fixes: ba090f9 ("arm64: kprobes: Remove redundant kprobe_step_ctx") Signed-off-by: Qais Yousef <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.