aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-12-17Merge branch 'locking-urgent-for-linus' of ↵Linus Torvalds2-20/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: "Tone down mutex debugging complaints, and annotate/fix spinlock debugging data accesses for KCSAN" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "locking/mutex: Complain upon mutex API misuse in IRQ contexts" locking/spinlock/debug: Fix various data races
2019-12-17Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds5-68/+93
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "Protect presistent EFI memory reservations from kexec, fix EFIFB early console, EFI stub graphics output fixes and other misc fixes." * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Don't attempt to map RCI2 config table if it doesn't exist efi/earlycon: Remap entire framebuffer after page initialization efi: Fix efi_loaded_image_t::unload type efi/gop: Fix memory leak in __gop_query32/64() efi/gop: Return EFI_SUCCESS if a usable GOP was found efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs efi/memreserve: Register reservations as 'reserved' in /proc/iomem
2019-12-17random: don't forget compat_ioctl on urandomJason A. Donenfeld1-0/+1
Recently, there's been some compat ioctl cleanup, in which large hardcoded lists were replaced with compat_ptr_ioctl. One of these changes involved removing the random.c hardcoded list entries and adding a compat ioctl function pointer to the random.c fops. In the process, urandom was forgotten about, so this commit fixes that oversight. Fixes: 507e4e2b430b ("compat_ioctl: remove /dev/random commands") Cc: Arnd Bergmann <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17bpf: Fix cgroup local storage prog trackingDaniel Borkmann4-19/+18
Recently noticed that we're tracking programs related to local storage maps through their prog pointer. This is a wrong assumption since the prog pointer can still change throughout the verification process, for example, whenever bpf_patch_insn_single() is called. Therefore, the prog pointer that was assigned via bpf_cgroup_storage_assign() is not guaranteed to be the same as we pass in bpf_cgroup_storage_release() and the map would therefore remain in busy state forever. Fix this by using the prog's aux pointer which is stable throughout verification and beyond. Fixes: de9cbbaadba5 ("bpf: introduce cgroup storage maps") Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/1471c69eca3022218666f909bc927a92388fd09e.1576580332.git.daniel@iogearbox.net
2019-12-17block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAITRoman Penyaev1-4/+7
Non-mq devs do not honor REQ_NOWAIT so give a chance to the caller to repeat request gracefully on -EAGAIN error. The problem is well reproduced using io_uring: mkfs.ext4 /dev/ram0 mount /dev/ram0 /mnt # Preallocate a file dd if=/dev/zero of=/mnt/file bs=1M count=1 # Start fio with io_uring and get -EIO fio --rw=write --ioengine=io_uring --size=1M --direct=1 --name=job --filename=/mnt/file Signed-off-by: Roman Penyaev <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-12-17usbip: Fix error path of vhci_recv_ret_submit()Suwan Kim1-4/+9
If a transaction error happens in vhci_recv_ret_submit(), event handler closes connection and changes port status to kick hub_event. Then hub tries to flush the endpoint URBs, but that causes infinite loop between usb_hub_flush_endpoint() and vhci_urb_dequeue() because "vhci_priv" in vhci_urb_dequeue() was already released by vhci_recv_ret_submit() before a transmission error occurred. Thus, vhci_urb_dequeue() terminates early and usb_hub_flush_endpoint() continuously calls vhci_urb_dequeue(). The root cause of this issue is that vhci_recv_ret_submit() terminates early without giving back URB when transaction error occurs in vhci_recv_ret_submit(). That causes the error URB to still be linked at endpoint list without “vhci_priv". So, in the case of transaction error in vhci_recv_ret_submit(), unlink URB from the endpoint, insert proper error code in urb->status and give back URB. Reported-by: Marek Marczykowski-Górecki <[email protected]> Tested-by: Marek Marczykowski-Górecki <[email protected]> Signed-off-by: Suwan Kim <[email protected]> Cc: stable <[email protected]> Acked-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17usbip: Fix receive error in vhci-hcd when using scatter-gatherSuwan Kim1-0/+3
When vhci uses SG and receives data whose size is smaller than SG buffer size, it tries to receive more data even if it acutally receives all the data from the server. If then, it erroneously adds error event and triggers connection shutdown. vhci-hcd should check if it received all the data even if there are more SG entries left. So, check if it receivces all the data from the server in for_each_sg() loop. Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by: Marek Marczykowski-Górecki <[email protected]> Tested-by: Marek Marczykowski-Górecki <[email protected]> Signed-off-by: Suwan Kim <[email protected]> Acked-by: Shuah Khan <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17USB: EHCI: Do not return -EPIPE when hub is disconnectedErkka Talvitie1-1/+12
When disconnecting a USB hub that has some child device(s) connected to it (such as a USB mouse), then the stack tries to clear halt and reset device(s) which are _already_ physically disconnected. The issue has been reproduced with: CPU: IMX6D5EYM10AD or MCIMX6D5EYM10AE. SW: U-Boot 2019.07 and kernel 4.19.40. CPU: HP Proliant Microserver Gen8. SW: Linux version 4.2.3-300.fc23.x86_64 In this situation there will be error bit for MMF active yet the CERR equals EHCI_TUNE_CERR + halt. Existing implementation interprets this as a stall [1] (chapter 8.4.5). The possible conditions when the MMF will be active + halt can be found from [2] (Table 4-13). Fix for the issue is to check whether MMF is active and PID Code is IN before checking for the stall. If these conditions are true then it is not a stall. What happens after the fix is that when disconnecting a hub with attached device(s) the situation is not interpret as a stall. [1] [https://www.usb.org/document-library/usb-20-specification, usb_20.pdf] [2] [https://www.intel.com/content/dam/www/public/us/en/documents/ technical-specifications/ehci-specification-for-usb.pdf] Signed-off-by: Erkka Talvitie <[email protected]> Reviewed-by: Alan Stern <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/ef70941d5f349767f19c0ed26b0dd9eed8ad81bb.1576050523.git.erkka.talvitie@vincit.fi Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17usb: typec: fusb302: Fix an undefined reference to 'extcon_get_state'zhong jiang1-0/+1
Fixes the following compile error: drivers/usb/typec/tcpm/fusb302.o: In function `tcpm_get_current_limit': fusb302.c:(.text+0x3ee): undefined reference to `extcon_get_state' fusb302.c:(.text+0x422): undefined reference to `extcon_get_state' fusb302.c:(.text+0x450): undefined reference to `extcon_get_state' fusb302.c:(.text+0x48c): undefined reference to `extcon_get_state' drivers/usb/typec/tcpm/fusb302.o: In function `fusb302_probe': fusb302.c:(.text+0x980): undefined reference to `extcon_get_extcon_dev' make: *** [vmlinux] Error 1 It is because EXTCON is build as a module, but FUSB302 is not. Suggested-by: Heikki Krogerus <[email protected]> Signed-off-by: zhong jiang <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17intel_th: msu: Fix window switching without windowsAlexander Shishkin1-5/+9
Commit 6cac7866c2741 ("intel_th: msu: Add a sysfs attribute to trigger window switch") adds a NULL pointer dereference in the case when there are no windows allocated: > BUG: kernel NULL pointer dereference, address: 0000000000000000 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 1 SMP > CPU: 5 PID: 1110 Comm: bash Not tainted 5.5.0-rc1+ #1 > RIP: 0010:msc_win_switch+0xa/0x80 [intel_th_msu] > Call Trace: > ? win_switch_store+0x9b/0xc0 [intel_th_msu] > dev_attr_store+0x17/0x30 > sysfs_kf_write+0x3e/0x50 > kernfs_fop_write+0xda/0x1b0 > __vfs_write+0x1b/0x40 > vfs_write+0xb9/0x1a0 > ksys_write+0x67/0xe0 > __x64_sys_write+0x1a/0x20 > do_syscall_64+0x57/0x1d0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix that by disallowing window switching with multiwindow buffers without windows. Signed-off-by: Alexander Shishkin <[email protected]> Fixes: 6cac7866c274 ("intel_th: msu: Add a sysfs attribute to trigger window switch") Reviewed-by: Andy Shevchenko <[email protected]> Reported-by: Ammy Yi <[email protected]> Tested-by: Ammy Yi <[email protected]> Cc: [email protected] # v5.2+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17intel_th: Fix freeing IRQsAlexander Shishkin2-3/+6
Commit aac8da65174a ("intel_th: msu: Start handling IRQs") implicitly relies on the use of devm_request_irq() to subsequently free the irqs on device removal, but in case of the pci_free_irq_vectors() API, the handlers need to be freed before it is called. Therefore, at the moment the driver's remove path trips a BUG_ON(irq_has_action()): > kernel BUG at drivers/pci/msi.c:375! > invalid opcode: 0000 1 SMP > CPU: 2 PID: 818 Comm: rmmod Not tainted 5.5.0-rc1+ #1 > RIP: 0010:free_msi_irqs+0x67/0x1c0 > pci_disable_msi+0x116/0x150 > pci_free_irq_vectors+0x1b/0x20 > intel_th_pci_remove+0x22/0x30 [intel_th_pci] > pci_device_remove+0x3e/0xb0 > device_release_driver_internal+0xf0/0x1c0 > driver_detach+0x4c/0x8f > bus_remove_driver+0x5c/0xd0 > driver_unregister+0x31/0x50 > pci_unregister_driver+0x40/0x90 > intel_th_pci_driver_exit+0x10/0xad6 [intel_th_pci] > __x64_sys_delete_module+0x147/0x290 > ? exit_to_usermode_loop+0xd7/0x120 > do_syscall_64+0x57/0x1b0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by explicitly freeing irqs before freeing the vectors. We keep using the devm_* variants because they are still useful in early error paths. Signed-off-by: Alexander Shishkin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Fixes: aac8da65174a ("intel_th: msu: Start handling IRQs") Reported-by: Ammy Yi <[email protected]> Tested-by: Ammy Yi <[email protected]> Cc: [email protected] # v5.2+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17intel_th: pci: Add Elkhart Lake SOC supportAlexander Shishkin1-0/+5
This adds support for Intel Trace Hub in Elkhart Lake. Signed-off-by: Alexander Shishkin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17intel_th: pci: Add Comet Lake PCH-V supportAlexander Shishkin1-0/+5
This adds Intel(R) Trace Hub PCI ID for Comet Lake PCH-V. Signed-off-by: Alexander Shishkin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17Merge tag 'asoc-fix-v5.5-rc2' of ↵Takashi Iwai19-97/+158
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.5 A collection of fixes since the merge window, mostly driver specific but there's a few in the core that clean up fallout from the refactorings done in the last cycle.
2019-12-17tty/serial: atmel: fix out of range clock divider handlingDavid Engraf1-21/+22
Use MCK_DIV8 when the clock divider is > 65535. Unfortunately the mode register was already written thus the clock selection is ignored. Fix by doing the baud rate calulation before setting the mode. Fixes: 5bf5635ac170 ("tty/serial: atmel: add fractional baud rate support") Signed-off-by: David Engraf <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Acked-by: Richard Genoud <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17tty: link tty and port before configuring it as consoleSudip Mukherjee2-1/+3
There seems to be a race condition in tty drivers and I could see on many boot cycles a NULL pointer dereference as tty_init_dev() tries to do 'tty->port->itty = tty' even though tty->port is NULL. 'tty->port' will be set by the driver and if the driver has not yet done it before we open the tty device we can get to this situation. By adding some extra debug prints, I noticed that: 6.650130: uart_add_one_port 6.663849: register_console 6.664846: tty_open 6.674391: tty_init_dev 6.675456: tty_port_link_device uart_add_one_port() registers the console, as soon as it registers, the userspace tries to use it and that leads to tty_open() but uart_add_one_port() has not yet done tty_port_link_device() and so tty->port is not yet configured when control reaches tty_init_dev(). Further look into the code and tty_port_link_device() is done by uart_add_one_port(). After registering the console uart_add_one_port() will call tty_port_register_device_attr_serdev() and tty_port_link_device() is called from this. Call add tty_port_link_device() before uart_configure_port() is done and add a check in tty_port_link_device() so that it only links the port if it has not been done yet. Suggested-by: Jiri Slaby <[email protected]> Signed-off-by: Sudip Mukherjee <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17sched/cfs: fix spurious active migrationVincent Guittot1-1/+8
The load balance can fail to find a suitable task during the periodic check because the imbalance is smaller than half of the load of the waiting tasks. This results in the increase of the number of failed load balance, which can end up to start an active migration. This active migration is useless because the current running task is not a better choice than the waiting ones. In fact, the current task was probably not running but waiting for the CPU during one of the previous attempts and it had already not been selected. When load balance fails too many times to migrate a task, we should relax the contraint on the maximum load of the tasks that can be migrated similarly to what is done with cache hotness. Before the rework, load balance used to set the imbalance to the average load_per_task in order to mitigate such situation. This increased the likelihood of migrating a task but also of selecting a larger task than needed while more appropriate ones were in the list. Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17sched/fair: Fix find_idlest_group() to handle CPU affinityVincent Guittot1-0/+4
Because of CPU affinity, the local group can be skipped which breaks the assumption that statistics are always collected for local group. With uninitialized local_sgs, the comparison is meaningless and the behavior unpredictable. This can even end up to use local pointer which is to NULL in this case. If the local group has been skipped because of CPU affinity, we return the idlest group. Fixes: 57abff067a08 ("sched/fair: Rework find_idlest_group()") Reported-by: John Stultz <[email protected]> Signed-off-by: Vincent Guittot <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Tested-by: John Stultz <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2019-12-17psi: Fix a division error in psi poll()Johannes Weiner1-1/+1
The psi window size is a u64 an can be up to 10 seconds right now, which exceeds the lower 32 bits of the variable. We currently use div_u64 for it, which is meant only for 32-bit divisors. The result is garbage pressure sampling values and even potential div0 crashes. Use div64_u64. Signed-off-by: Johannes Weiner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Cc: Jingfeng Xie <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17sched/psi: Fix sampling error and rare div0 crashes with cgroups and high uptimeJohannes Weiner1-1/+2
Jingfeng reports rare div0 crashes in psi on systems with some uptime: [58914.066423] divide error: 0000 [#1] SMP [58914.070416] Modules linked in: ipmi_poweroff ipmi_watchdog toa overlay fuse tcp_diag inet_diag binfmt_misc aisqos(O) aisqos_hotfixes(O) [58914.083158] CPU: 94 PID: 140364 Comm: kworker/94:2 Tainted: G W OE K 4.9.151-015.ali3000.alios7.x86_64 #1 [58914.093722] Hardware name: Alibaba Alibaba Cloud ECS/Alibaba Cloud ECS, BIOS 3.23.34 02/14/2019 [58914.102728] Workqueue: events psi_update_work [58914.107258] task: ffff8879da83c280 task.stack: ffffc90059dcc000 [58914.113336] RIP: 0010:[] [] psi_update_stats+0x1c1/0x330 [58914.122183] RSP: 0018:ffffc90059dcfd60 EFLAGS: 00010246 [58914.127650] RAX: 0000000000000000 RBX: ffff8858fe98be50 RCX: 000000007744d640 [58914.134947] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00003594f700648e [58914.142243] RBP: ffffc90059dcfdf8 R08: 0000359500000000 R09: 0000000000000000 [58914.149538] R10: 0000000000000000 R11: 0000000000000000 R12: 0000359500000000 [58914.156837] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8858fe98bd78 [58914.164136] FS: 0000000000000000(0000) GS:ffff887f7f380000(0000) knlGS:0000000000000000 [58914.172529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [58914.178467] CR2: 00007f2240452090 CR3: 0000005d5d258000 CR4: 00000000007606f0 [58914.185765] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [58914.193061] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [58914.200360] PKRU: 55555554 [58914.203221] Stack: [58914.205383] ffff8858fe98bd48 00000000000002f0 0000002e81036d09 ffffc90059dcfde8 [58914.213168] ffff8858fe98bec8 0000000000000000 0000000000000000 0000000000000000 [58914.220951] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [58914.228734] Call Trace: [58914.231337] [] psi_update_work+0x22/0x60 [58914.237067] [] process_one_work+0x189/0x420 [58914.243063] [] worker_thread+0x4e/0x4b0 [58914.248701] [] ? process_one_work+0x420/0x420 [58914.254869] [] kthread+0xe6/0x100 [58914.259994] [] ? kthread_park+0x60/0x60 [58914.265640] [] ret_from_fork+0x39/0x50 [58914.271193] Code: 41 29 c3 4d 39 dc 4d 0f 42 dc <49> f7 f1 48 8b 13 48 89 c7 48 c1 [58914.279691] RIP [] psi_update_stats+0x1c1/0x330 The crashing instruction is trying to divide the observed stall time by the sampling period. The period, stored in R8, is not 0, but we are dividing by the lower 32 bits only, which are all 0 in this instance. We could switch to a 64-bit division, but the period shouldn't be that big in the first place. It's the time between the last update and the next scheduled one, and so should always be around 2s and comfortably fit into 32 bits. The bug is in the initialization of new cgroups: we schedule the first sampling event in a cgroup as an offset of sched_clock(), but fail to initialize the last_update timestamp, and it defaults to 0. That results in a bogusly large sampling period the first time we run the sampling code, and consequently we underreport pressure for the first 2s of a cgroup's life. But worse, if sched_clock() is sufficiently advanced on the system, and the user gets unlucky, the period's lower 32 bits can all be 0 and the sampling division will crash. Fix this by initializing the last update timestamp to the creation time of the cgroup, thus correctly marking the start of the first pressure sampling period in a new cgroup. Reported-by: Jingfeng Xie <[email protected]> Signed-off-by: Johannes Weiner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17perf/core: Add SRCU annotation for pmus list walkSebastian Andrzej Siewior1-1/+1
Since commit 28875945ba98d ("rcu: Add support for consolidated-RCU reader checking") there is an additional check to ensure that a RCU related lock is held while the RCU list is iterated. This section holds the SRCU reader lock instead. Add annotation to list_for_each_entry_rcu() that pmus_srcu must be acquired during the list traversal. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Joel Fernandes (Google) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17perf/x86/intel: Fix PT PMI handlingAlexander Shishkin1-2/+7
Commit: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") skips the PT/LBR exclusivity check on CPUs where PT and LBRs coexist, but also inadvertently skips the active_events bump for PT in that case, which is a bug. If there aren't any hardware events at the same time as PT, the PMI handler will ignore PT PMIs, as active_events reads zero in that case, resulting in the "Uhhuh" spurious NMI warning and PT data loss. Fix this by always increasing active_events for PT events. Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") Reported-by: Vitaly Slobodskoy <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Alexey Budankov <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17perf/x86/intel/bts: Fix the use of page_private()Alexander Shishkin1-5/+11
Commit 8062382c8dbe2 ("perf/x86/intel/bts: Add BTS PMU driver") brought in a warning with the BTS buffer initialization that is easily tripped with (assuming KPTI is disabled): instantly throwing: > ------------[ cut here ]------------ > WARNING: CPU: 2 PID: 326 at arch/x86/events/intel/bts.c:86 bts_buffer_setup_aux+0x117/0x3d0 > Modules linked in: > CPU: 2 PID: 326 Comm: perf Not tainted 5.4.0-rc8-00291-gceb9e77324fa #904 > RIP: 0010:bts_buffer_setup_aux+0x117/0x3d0 > Call Trace: > rb_alloc_aux+0x339/0x550 > perf_mmap+0x607/0xc70 > mmap_region+0x76b/0xbd0 ... It appears to assume (for lost raisins) that PagePrivate() is set, while later it actually tests for PagePrivate() before using page_private(). Make it consistent and always check PagePrivate() before using page_private(). Fixes: 8062382c8dbe2 ("perf/x86/intel/bts: Add BTS PMU driver") Signed-off-by: Alexander Shishkin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Vince Weaver <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17perf/x86: Fix potential out-of-bounds accessPeter Zijlstra1-2/+8
UBSAN reported out-of-bound accesses for x86_pmu.event_map(), it's arguments should be < x86_pmu.max_events. Make sure all users observe this constraint. Reported-by: Meelis Roos <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Meelis Roos <[email protected]>
2019-12-17Merge tag 'perf-urgent-for-mingo-5.5-20191216' of ↵Ingo Molnar2713-41583/+99744
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes: perf top: Arnaldo Carvalho de Melo: - Do not bail out when perf_env__read_cpuid() returns ENOSYS, which has been reported happening on aarch64. perf metricgroup: Kajol Jain: - Fix printing event names of metric group with multiple events vendor events: x86: Ravi Bangoria: - Fix Kernel_Utilization metric. s390: Ed Maste: - Fix counter long description for DTLB1_GPAGE_WRITES and L1D_RO_EXCL_WRITES. perf header: Michael Petlan: - Fix false warning when there are no duplicate cache entries libtraceevent: Sudip Mukherjee: - Allow custom libdir path API headers: Arnaldo Carvalho de Melo: - Sync linux/kvm.h with the kernel sources. Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2019-12-17iommu/vt-d: Allocate reserved region for ISA with correct permissionJerry Snitselaar1-1/+1
Currently the reserved region for ISA is allocated with no permissions. If a dma domain is being used, mapping this region will fail. Set the permissions to DMA_PTE_READ|DMA_PTE_WRITE. Cc: Joerg Roedel <[email protected]> Cc: Lu Baolu <[email protected]> Cc: [email protected] Cc: [email protected] # v5.3+ Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Signed-off-by: Jerry Snitselaar <[email protected]> Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17iommu: set group default domain before creating direct mappingsJerry Snitselaar1-2/+2
iommu_group_create_direct_mappings uses group->default_domain, but right after it is called, request_default_domain_for_dev calls iommu_domain_free for the default domain, and sets the group default domain to a different domain. Move the iommu_group_create_direct_mappings call to after the group default domain is set, so the direct mappings get associated with that domain. Cc: Joerg Roedel <[email protected]> Cc: Lu Baolu <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: 7423e01741dd ("iommu: Add API to request DMA domain for device") Signed-off-by: Jerry Snitselaar <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17iommu/vt-d: Fix dmar pte read access not set errorLu Baolu1-8/+0
If the default DMA domain of a group doesn't fit a device, it will still sit in the group but use a private identity domain. When map/unmap/iova_to_phys come through iommu API, the driver should still serve them, otherwise, other devices in the same group will be impacted. Since identity domain has been mapped with the whole available memory space and RMRRs, we don't need to worry about the impact on it. Link: https://www.spinics.net/lists/iommu/msg40416.html Cc: Jerry Snitselaar <[email protected]> Reported-by: Jerry Snitselaar <[email protected]> Fixes: 942067f1b6b97 ("iommu/vt-d: Identify default domains replaced with private") Cc: [email protected] # v5.3+ Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Tested-by: Jerry Snitselaar <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17drm/i915: Fix WARN_ON condition for cursor plane ddb allocationVandita Kulkarni1-2/+2
In some cases like latency[level]==0, wm[level].res_lines>31, min_ddb_alloc can be U16_MAX, exclude it from the WARN_ON. v2: Specify the cases in which we hit U16_MAX, indentation (Ville) Fixes: 10a7e07b68b9 ("drm/i915: Make sure cursor has enough ddb for the selected wm level") Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Vandita Kulkarni <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 4ba487019d1a196051feefab57f4a393815733b4) Signed-off-by: Joonas Lahtinen <[email protected]>
2019-12-17scripts: package: mkdebian: add missing rsync dependencyEnrico Weigelt, metux IT consult1-1/+1
We've missed the dependency to rsync, so build fails on minimal containers. Fixes: 59b2bd05f5f4 ("kbuild: add 'headers' target to build up uapi headers in usr/include") Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2019-12-17kconfig: don't crash on NULL expressions in expr_eq()Thomas Hebb1-0/+7
NULL expressions are taken to always be true, as implemented by the expr_is_yes() macro and by several other functions in expr.c. As such, they ought to be valid inputs to expr_eq(), which compares two expressions. Signed-off-by: Thomas Hebb <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2019-12-17iommu/vt-d: Set ISA bridge reserved region as relaxableAlex Williamson1-1/+1
Commit d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") created a direct-mapped reserved memory region in order to replace the static identity mapping of the ISA address space, where the latter was then removed in commit df4f3c603aeb ("iommu/vt-d: Remove static identity map code"). According to the history of this code and the Kconfig option surrounding it, this direct mapping exists for the benefit of legacy ISA drivers that are not compatible with the DMA API. In conjuntion with commit 9b77e5c79840 ("vfio/type1: check dma map request is within a valid iova range") this change introduced a regression where the vfio IOMMU backend enforces reserved memory regions per IOMMU group, preventing userspace from creating IOMMU mappings conflicting with prescribed reserved regions. A necessary prerequisite for the vfio change was the introduction of "relaxable" direct mappings introduced by commit adfd37382090 ("iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions"). These relaxable direct mappings provide the same identity mapping support in the default domain, but also indicate that the reservation is software imposed and may be relaxed under some conditions, such as device assignment. Convert the ISA bridge direct-mapped reserved region to relaxable to reflect that the restriction is self imposed and need not be enforced by drivers such as vfio. Fixes: 1c5c59fbad20 ("iommu/vt-d: Differentiate relaxable and non relaxable RMRRs") Cc: [email protected] # v5.3+ Link: https://lore.kernel.org/linux-iommu/[email protected] Reported-by: cprt <[email protected]> Tested-by: cprt <[email protected]> Signed-off-by: Alex Williamson <[email protected]> Acked-by: Lu Baolu <[email protected]> Reviewed-by: Eric Auger <[email protected]> Tested-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17tpm: selftest: cleanup after unseal with wrong auth/policy testTadeusz Struk1-0/+5
Unseal with wrong auth or wrong policy test affects DA lockout and eventually causes the tests to fail with: "ProtocolError: TPM_RC_LOCKOUT: rc=0x00000921" when the tests run multiple times. Send tpm clear command after the test to reset the DA counters. Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2019-12-17tpm: selftest: add test covering async modeTadeusz Struk3-2/+31
Add a test that sends a tpm cmd in an async mode. Currently there is a gap in test coverage with regards to this functionality. Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2019-12-17tpm: fix invalid locking in NONBLOCKING modeTadeusz Struk1-0/+8
When an application sends TPM commands in NONBLOCKING mode the driver holds chip->tpm_mutex returning from write(), which triggers: "WARNING: lock held when returning to user space". To fix this issue the driver needs to release the mutex before returning and acquire it again in tpm_dev_async_work() before sending the command. Cc: [email protected] Fixes: 9e1b74a63f776 (tpm: add support for nonblocking operation) Reported-by: Jeffrin Jose T <[email protected]> Tested-by: Jeffrin Jose T <[email protected]> Signed-off-by: Tadeusz Struk <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2019-12-17iommu/dma: Rationalise types for DMA masksRobin Murphy1-3/+3
Since iommu_dma_alloc_iova() combines incoming masks with the u64 bus limit, it makes more sense to pass them around in their native u64 rather than converting to dma_addr_t early. Do that, and resolve the remaining type discrepancy against the domain geometry with a cheeky cast to keep things simple. Signed-off-by: Robin Murphy <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Tested-by: Nathan Chancellor <[email protected]> # build Reviewed-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17iommu/iova: Init the struct iova to fix the possible memleakXiaotao Yin1-1/+1
During ethernet(Marvell octeontx2) set ring buffer test: ethtool -G eth1 rx <rx ring size> tx <tx ring size> following kmemleak will happen sometimes: unreferenced object 0xffff000b85421340 (size 64): comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s) hex dump (first 64 bytes): 80 13 42 85 0b 00 ff ff ff ff ff ff ff ff ff ff ..B............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001b204ddf>] kmem_cache_alloc+0x1b0/0x350 [<00000000d9ef2e50>] alloc_iova+0x3c/0x168 [<00000000ea30f99d>] alloc_iova_fast+0x7c/0x2d8 [<00000000b8bb2f1f>] iommu_dma_alloc_iova.isra.0+0x12c/0x138 [<000000002f1a43b5>] __iommu_dma_map+0x8c/0xf8 [<00000000ecde7899>] iommu_dma_map_page+0x98/0xf8 [<0000000082004e59>] otx2_alloc_rbuf+0xf4/0x158 [<000000002b107f6b>] otx2_rq_aura_pool_init+0x110/0x270 [<00000000c3d563c7>] otx2_open+0x15c/0x734 [<00000000a2f5f3a8>] otx2_dev_open+0x3c/0x68 [<00000000456a98b5>] otx2_set_ringparam+0x1ac/0x1d4 [<00000000f2fbb819>] dev_ethtool+0xb84/0x2028 [<0000000069b67c5a>] dev_ioctl+0x248/0x3a0 [<00000000af38663a>] sock_ioctl+0x280/0x638 [<000000002582384c>] do_vfs_ioctl+0x8b0/0xa80 [<000000004e1a2c02>] ksys_ioctl+0x84/0xb8 The reason: When alloc_iova_mem() without initial with Zero, sometimes fpn_lo will equal to IOVA_ANCHOR by chance, so when return with -ENOMEM(iova32_full) from __alloc_and_insert_iova_range(), the new_iova will not be freed in free_iova_mem(). Fixes: bb68b2fbfbd6 ("iommu/iova: Add rbtree anchor node") Signed-off-by: Xiaotao Yin <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2019-12-17security: keys: trusted: fix lost handle flushJames Bottomley4-1/+3
The original code, before it was moved into security/keys/trusted-keys had a flush after the blob unseal. Without that flush, the volatile handles increase in the TPM until it becomes unusable and the system either has to be rebooted or the TPM volatile area manually flushed. Fix by adding back the lost flush, which we now have to export because of the relocation of the trusted key code may cause the consumer to be modular. Signed-off-by: James Bottomley <[email protected]> Fixes: 2e19e10131a0 ("KEYS: trusted: Move TPM2 trusted keys code") Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2019-12-17x86/mce: Fix possibly incorrect severity calculation on AMDJan H. Schönherr1-1/+1
The function mce_severity_amd_smca() requires m->bank to be initialized for correct operation. Fix the one case, where mce_severity() is called without doing so. Fixes: 6bda529ec42e ("x86/mce: Grade uncorrected errors for SMCA-enabled systems") Fixes: d28af26faa0b ("x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out()") Signed-off-by: Jan H. Schönherr <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Tony Luck <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: linux-edac <[email protected]> Cc: <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: x86-ml <[email protected]> Cc: Yazen Ghannam <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17x86/MCE/AMD: Allow Reserved types to be overwritten in smca_banks[]Yazen Ghannam1-1/+1
Each logical CPU in Scalable MCA systems controls a unique set of MCA banks in the system. These banks are not shared between CPUs. The bank types and ordering will be the same across CPUs on currently available systems. However, some CPUs may see a bank as Reserved/Read-as-Zero (RAZ) while other CPUs do not. In this case, the bank seen as Reserved on one CPU is assumed to be the same type as the bank seen as a known type on another CPU. In general, this occurs when the hardware represented by the MCA bank is disabled, e.g. disabled memory controllers on certain models, etc. The MCA bank is disabled in the hardware, so there is no possibility of getting an MCA/MCE from it even if it is assumed to have a known type. For example: Full system: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | UMC | UMC 2 | CS | CS System with hardware disabled: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | UMC | RAZ 2 | CS | CS For this reason, there is a single, global struct smca_banks[] that is initialized at boot time. This array is initialized on each CPU as it comes online. However, the array will not be updated if an entry already exists. This works as expected when the first CPU (usually CPU0) has all possible MCA banks enabled. But if the first CPU has a subset, then it will save a "Reserved" type in smca_banks[]. Successive CPUs will then not be able to update smca_banks[] even if they encounter a known bank type. This may result in unexpected behavior. Depending on the system configuration, a user may observe issues enumerating the MCA thresholding sysfs interface. The issues may be as trivial as sysfs entries not being available, or as severe as system hangs. For example: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | RAZ | UMC 2 | CS | CS Extend the smca_banks[] entry check to return if the entry is a non-reserved type. Otherwise, continue so that CPUs that encounter a known bank type can update smca_banks[]. Fixes: 68627a697c19 ("x86/mce/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type") Signed-off-by: Yazen Ghannam <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: linux-edac <[email protected]> Cc: <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tony Luck <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-17x86/MCE/AMD: Do not use rdmsr_safe_on_cpu() in smca_configure()Konstantin Khlebnikov1-1/+1
... because interrupts are disabled that early and sending IPIs can deadlock: BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 no locks held by swapper/1/0. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffffffff8106dda9>] copy_process+0x8b9/0x1ca0 softirqs last enabled at (0): [<ffffffff8106dda9>] copy_process+0x8b9/0x1ca0 softirqs last disabled at (0): [<0000000000000000>] 0x0 Preemption disabled at: [<ffffffff8104703b>] start_secondary+0x3b/0x190 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.5.0-rc2+ #1 Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018 Call Trace: dump_stack ___might_sleep.cold.92 wait_for_completion ? generic_exec_single rdmsr_safe_on_cpu ? wrmsr_on_cpus mce_amd_feature_init mcheck_cpu_init identify_cpu identify_secondary_cpu smp_store_cpu_info start_secondary secondary_startup_64 The function smca_configure() is called only on the current CPU anyway, therefore replace rdmsr_safe_on_cpu() with atomic rdmsr_safe() and avoid the IPI. [ bp: Update commit message. ] Signed-off-by: Konstantin Khlebnikov <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Yazen Ghannam <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: linux-edac <[email protected]> Cc: <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tony Luck <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/157252708836.3876.4604398213417262402.stgit@buzz
2019-12-17staging: axis-fifo: add unspecified HAS_IOMEM dependencyBrendan Higgins1-1/+1
Currently CONFIG_XIL_AXIS_FIFO=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: ld: drivers/staging/axis-fifo/axis-fifo.o: in function `axis_fifo_probe': drivers/staging/axis-fifo/axis-fifo.c:809: undefined reference to `devm_ioremap_resource' Fix the build error by adding the unspecified dependency. Reported-by: Brendan Higgins <[email protected]> Signed-off-by: Brendan Higgins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17staging: comedi: gsc_hpdi: check dma_alloc_coherent() return valueIan Abbott1-0/+10
The "auto-attach" handler function `gsc_hpdi_auto_attach()` calls `dma_alloc_coherent()` in a loop to allocate some DMA data buffers, and also calls it to allocate a buffer for a DMA descriptor chain. However, it does not check the return value of any of these calls. Change `gsc_hpdi_auto_attach()` to return `-ENOMEM` if any of these `dma_alloc_coherent()` calls fail. This will result in the comedi core calling the "detach" handler `gsc_hpdi_detach()` as part of the clean-up, which will call `gsc_hpdi_free_dma()` to free any allocated DMA coherent memory buffers. Cc: <[email protected]> #4.6+ Signed-off-by: Ian Abbott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-17KVM: PPC: Book3S HV: Fix regression on big endian hostsMarcus Comstedt1-2/+2
VCPU_CR is the offset of arch.regs.ccr in kvm_vcpu. arch/powerpc/include/asm/kvm_host.h defines arch.regs as a struct pt_regs, and arch/powerpc/include/asm/ptrace.h defines the ccr field of pt_regs as "unsigned long ccr". Since unsigned long is 64 bits, a 64-bit load needs to be used to load it, unless an endianness specific correction offset is added to access the desired subpart. In this case there is no reason to _not_ use a 64 bit load though. Fixes: 6c85b7bc637b ("powerpc/kvm: Use UV_RETURN ucall to return to ultravisor") Cc: [email protected] # v5.4+ Signed-off-by: Marcus Comstedt <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2019-12-16Merge tag 'mac80211-for-net-2019-10-16' of ↵David S. Miller10-27/+86
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== A handful of fixes: * disable AQL on most drivers, addressing the iwlwifi issues * fix double-free on network namespace changes * fix TID field in frames injected through monitor interfaces * fix ieee80211_calc_rx_airtime() * fix NULL pointer dereference in rfkill (and remove BUG_ON) ==================== Signed-off-by: David S. Miller <[email protected]>
2019-12-16net: dsa: ocelot: add NET_VENDOR_MICROSEMI dependencyArnd Bergmann1-0/+1
Selecting MSCC_OCELOT_SWITCH is not possible when NET_VENDOR_MICROSEMI is disabled: WARNING: unmet direct dependencies detected for MSCC_OCELOT_SWITCH Depends on [n]: NETDEVICES [=y] && ETHERNET [=n] && NET_VENDOR_MICROSEMI [=n] && NET_SWITCHDEV [=y] && HAS_IOMEM [=y] Selected by [m]: - NET_DSA_MSCC_FELIX [=m] && NETDEVICES [=y] && HAVE_NET_DSA [=y] && NET_DSA [=y] && PCI [=y] Add a Kconfig dependency on NET_VENDOR_MICROSEMI, which also implies CONFIG_NETDEVICES. Depending on a vendor config violates menuconfig locality for the DSA driver, but is the smallest compromise since all other solutions are much more complicated (see [0]). https://www.spinics.net/lists/netdev/msg618808.html Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family") Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Mao Wenan <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-17drm/i915/gvt: Fix guest boot warningGao Fred1-0/+16
Simulate MIA core in reset status once GUC engine is reset. v2: 1. use vgpu_vreg_t() function, 2. clear MIA_IN_RESET after reading. (Zhenyu) v3: add comments. (Zhenyu) Signed-off-by: Gao Fred <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-12-16scsi: lpfc: fix build failure with DEBUGFS disabledArnd Bergmann1-2/+1
A recent change appears to have moved an #endif by accident: drivers/scsi/lpfc/lpfc_debugfs.c:5393:18: error: 'lpfc_debugfs_dumpHBASlim_open' undeclared here (not in a function); did you mean 'lpfc_debugfs_op_dumpHBASlim'? drivers/scsi/lpfc/lpfc_debugfs.c:5394:18: error: 'lpfc_debugfs_lseek' undeclared here (not in a function); did you mean 'lpfc_debugfs_nvme_trc'? drivers/scsi/lpfc/lpfc_debugfs.c:5395:18: error: 'lpfc_debugfs_read' undeclared here (not in a function); did you mean 'lpfc_debug_dump_q'? drivers/scsi/lpfc/lpfc_debugfs.c:5396:18: error: 'lpfc_debugfs_release' undeclared here (not in a function); did you mean 'lpfc_debugfs_terminate'? drivers/scsi/lpfc/lpfc_debugfs.c:5402:18: error: 'lpfc_debugfs_dumpHostSlim_open' undeclared here (not in a function); did you mean 'lpfc_debugfs_op_dumpHostSlim'? Move it back to where it was previously. Fixes: 95bfc6d8ad86 ("scsi: lpfc: Make FW logging dynamically configurable") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-12-16scsi: mpt3sas: Fix double free in attach error handlingDan Carpenter1-1/+0
The caller also calls _base_release_memory_pools() on error so it leads to a number of double frees: drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->chain_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->hpr_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->internal_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->pcie_sgl_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->reply_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->reply_free_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->reply_post_free_array_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->reply_post_free_dma_pool' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:7207 mpt3sas_base_attach() warn: 'ioc->sense_dma_pool' double freed Fixes: 74522a92bbf0 ("scsi: mpt3sas: Optimize I/O memory consumption in driver.") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Sreekanth Reddy <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2019-12-17tpm_tis: reserve chip for duration of tpm_tis_core_initJerry Snitselaar1-17/+18
Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when issuing commands to the tpm during initialization, just reserve the chip after wait_startup, and release it when we are ready to call tpm_chip_register. Cc: Christian Bundy <[email protected]> Cc: Dan Williams <[email protected]> Cc: Peter Huewe <[email protected]> Cc: Jarkko Sakkinen <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Stefan Berger <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's") Suggested-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.