- 26 Aug, 2017 40 commits
-
-
David Ahern authored
commit 4a6e3c5d upstream. ndisc_notify is the ipv6 equivalent to arp_notify. When arp_notify is set to 1, gratuitous arp requests are sent when the device is brought up. The same is expected when ndisc_notify is set to 1 (per ndisc_notify in Documentation/networking/ip-sysctl.txt). The NA is not sent on NETDEV_UP event; add it. Fixes: 5cb04436 ("ipv6: add knob to send unsolicited ND on link-layer address change") Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Steven Rostedt (VMware) authored
commit 82cc4fc2 upstream. When two function probes are added to set_ftrace_filter, and then one of them is removed, the update to the function locations is not performed, and the record keeping of the function states are corrupted, and causes an ftrace_bug() to occur. This is easily reproducable by adding two probes, removing one, and then adding it back again. # cd /sys/kernel/debug/tracing # echo schedule:traceoff > set_ftrace_filter # echo do_IRQ:traceoff > set_ftrace_filter # echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter # echo do_IRQ:traceoff > set_ftrace_filter Causes: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1098 at kernel/trace/ftrace.c:2369 ftrace_get_addr_curr+0x143/0x220 Modules linked in: [...] CPU: 2 PID: 1098 Comm: bash Not tainted 4.10.0-test+ #405 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 Call Trace: dump_stack+0x68/0x9f __warn+0x111/0x130 ? trace_irq_work_interrupt+0xa0/0xa0 warn_slowpath_null+0x1d/0x20 ftrace_get_addr_curr+0x143/0x220 ? __fentry__+0x10/0x10 ftrace_replace_code+0xe3/0x4f0 ? ftrace_int3_handler+0x90/0x90 ? printk+0x99/0xb5 ? 0xffffffff81000000 ftrace_modify_all_code+0x97/0x110 arch_ftrace_update_code+0x10/0x20 ftrace_run_update_code+0x1c/0x60 ftrace_run_modify_code.isra.48.constprop.62+0x8e/0xd0 register_ftrace_function_probe+0x4b6/0x590 ? ftrace_startup+0x310/0x310 ? debug_lockdep_rcu_enabled.part.4+0x1a/0x30 ? update_stack_state+0x88/0x110 ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320 ? preempt_count_sub+0x18/0xd0 ? mutex_lock_nested+0x104/0x800 ? ftrace_regex_write.isra.43.part.44+0x1d3/0x320 ? __unwind_start+0x1c0/0x1c0 ? _mutex_lock_nest_lock+0x800/0x800 ftrace_trace_probe_callback.isra.3+0xc0/0x130 ? func_set_flag+0xe0/0xe0 ? __lock_acquire+0x642/0x1790 ? __might_fault+0x1e/0x20 ? trace_get_user+0x398/0x470 ? strcmp+0x35/0x60 ftrace_trace_onoff_callback+0x48/0x70 ftrace_regex_write.isra.43.part.44+0x251/0x320 ? match_records+0x420/0x420 ftrace_filter_write+0x2b/0x30 __vfs_write+0xd7/0x330 ? do_loop_readv_writev+0x120/0x120 ? locks_remove_posix+0x90/0x2f0 ? do_lock_file_wait+0x160/0x160 ? __lock_is_held+0x93/0x100 ? rcu_read_lock_sched_held+0x5c/0xb0 ? preempt_count_sub+0x18/0xd0 ? __sb_start_write+0x10a/0x230 ? vfs_write+0x222/0x240 vfs_write+0xef/0x240 SyS_write+0xab/0x130 ? SyS_read+0x130/0x130 ? trace_hardirqs_on_caller+0x182/0x280 ? trace_hardirqs_on_thunk+0x1a/0x1c entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x7fe61c157c30 RSP: 002b:00007ffe87890258 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: ffffffff8114a410 RCX: 00007fe61c157c30 RDX: 0000000000000010 RSI: 000055814798f5e0 RDI: 0000000000000001 RBP: ffff8800c9027f98 R08: 00007fe61c422740 R09: 00007fe61ca53700 R10: 0000000000000073 R11: 0000000000000246 R12: 0000558147a36400 R13: 00007ffe8788f160 R14: 0000000000000024 R15: 00007ffe8788f15c ? trace_hardirqs_off_caller+0xc0/0x110 ---[ end trace 99fa09b3d9869c2c ]--- Bad trampoline accounting at: ffffffff81cc3b00 (do_IRQ+0x0/0x150) Fixes: 59df055f ("ftrace: trace different functions with a different tracer") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> [bwh: Backported to 3.16: - Use ftrace_run_update_code() instead of ftrace_run_modify_code(), and don't define old_hash - Adjust context] Signed-off-by:
-
Matt Ranostay authored
commit 84ca8e36 upstream. AS3935_WRITE_DATA macro bit is incorrect and the actual write sequence is two leading zeros. Cc: George McCollister <george.mccollister@gmail.com> Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Pavel Roskin authored
commit ce420fd4 upstream. realbits, storagebits and shift should be numbers, not ASCII characters. Signed-off-by:
Pavel Roskin <plroskin@gmail.com> Reviewed-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Kan Liang authored
commit fd583ad1 upstream. Spurious NMIs will be observed with the following command: while :; do perf record -bae "cpu/umask=0x01,event=0xcd,ldlat=0x80/pp" -e "cpu/umask=0x03,event=0x0/" -e "cpu/umask=0x02,event=0x0/" -e cycles,branches,cache-misses -e cache-references -- sleep 10 done The bug was introduced by commit: 8077eca0 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+") That commit clears the status bits for the counters used for PEBS events, by masking the whole 64 bits pebs_enabled. However, only the low 32 bits of both status and pebs_enabled are reserved for PEBS-able counters. For status bits 32-34 are fixed counter overflow bits. For pebs_enabled bits 32-34 are for PEBS Load Latency. In the test case, the PEBS Load Latency event and fixed counter event could overflow at the same time. The fixed counter overflow bit will be cleared by mistake. Once it is cleared, the fixed counter overflow never be processed, which finally trigger spurious NMI. Correct the PEBS enabled mask by ignoring the non-PEBS bits. Signed-off-by:
Kan Liang <kan.liang@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: 8077eca0 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+") Link: http://lkml.kernel.org/r/1491333246-3965-1-git-send-email-kan.liang@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.16: - Drop change in get_next_pebs_record_by_bit() - Adjust filenames] Signed-off-by:
-
Stephane Eranian authored
commit daa864b8 upstream. This patch solves a race condition between PEBS and the PMU handler. In case multiple PEBS events are sampled at the same time, it is possible to have GLOBAL_STATUS bit 62 set indicating PEBS buffer overflow and also seeing at most 3 PEBS counters having their bits set in the status register. This is a sign that there was at least one PEBS record pending at the time of the PMU interrupt. PEBS counters must only be processed via the drain_pebs() calls, and not via the regular sample processing loop coming after that the function, otherwise phony regular samples may be generated in the sampling buffer not marked with the EXACT tag. Another possibility is to have one PEBS event and at least one non-PEBS event whic hoverflows while PEBS has armed. In this case, bit 62 of GLOBAL_STATUS will not be set, yet the overflow status bit for the PEBS counter will be on Skylake. To avoid this problem, we systematically ignore the PEBS-enabled counters from the GLOBAL_STATUS mask and we always process PEBS events via drain_pebs(). The problem manifested itself by having non-exact samples when sampling only PEBS events, i.e., the PERF_SAMPLE_RECORD would not have the EXACT flag set. Note that this problem is only present on Skylake processor. This fix is harmless on older processors. Reported-by:
Stephane Eranian <eranian@google.com> Signed-off-by:
-
Ludovic Desroches authored
commit d3df1ec0 upstream. Remove ADC channels that are not available by default on the sama5d3_xplained board (resistor not populated) in order to not create confusion. Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Ludovic Desroches authored
commit 9cdd31e5 upstream. The voltage reference for the ADC is not 3V but 3.3V since it is connected to VDDANA. Signed-off-by:
-
Giedrius Statkevičius authored
commit bdd9968d upstream. val might become 7 in which case stime[7] (array of length 7) would be accessed during the scnprintf call later and that will cause issues. Obviously, string concatenation is not intended here so just a comma needs to be added to fix the issue. Fixes: 98a27664 ("power_supply: Add new lp8788 charger driver") Signed-off-by:
Giedrius Statkevičius <giedrius.statkevicius@gmail.com> Acked-by:
Milo Kim <milo.kim@ti.com> Signed-off-by:
Sebastian Reichel <sre@kernel.org> [bwh: Backported to 3.16: adjust filename] Signed-off-by:
-
Alex Williamson authored
commit 0cfef2b7 upstream. If the mmap_sem is contented then the vfio type1 IOMMU backend will defer locked page accounting updates to a workqueue task. This has a few problems and depending on which side the user tries to play, they might be over-penalized for unmaps that haven't yet been accounted or race the workqueue to enter more mappings than they're allowed. The original intent of this workqueue mechanism seems to be focused on reducing latency through the ioctl, but we cannot do so at the cost of correctness. Remove this workqueue mechanism and update the callers to allow for failure. We can also now recheck the limit under write lock to make sure we don't exceed it. vfio_pin_pages_remote() also now necessarily includes an unwind path which we can jump to directly if the consecutive page pinning finds that we're exceeding the user's memory limits. This avoids the current lazy approach which does accounting and mapping up to the fault, only to return an error on the next iteration to unwind the entire vfio_dma. Reviewed-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Kirti Wankhede <kwankhede@nvidia.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> [bwh: Backported to 3.16: - vfio_lock_acct() always operates on current->mm - Drop changes to vfio_{,un}pin_page_external() and vfio_iommu_unmap_unpin_reaccount() - Drop test of rsvd flag - Fix up the disable_hugepages case in vfio_pin_pages() - Use down_write() instead of down_write_killable() - Adjust context] Signed-off-by:
-
David Woodhouse authored
commit 6bccc7f4 upstream. In the PCI_MMAP_PROCFS case when the address being passed by the user is a 'user visible' resource address based on the bus window, and not the actual contents of the resource, that's what we need to be checking it against. Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Johan Hovold authored
commit 77e6fe7f upstream. Make sure to actually suspend the device before returning after a failed (or deferred) probe. Note that autosuspend must be disabled before runtime pm is disabled in order to balance the usage count due to a negative autosuspend delay as well as to make the final put suspend the device synchronously. Fixes: 388bc262 ("omap-serial: Fix the error handling in the omap_serial probe") Cc: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johan Hovold authored
commit 099bd73d upstream. An unbalanced and misplaced synchronous put was used to suspend the device on driver unbind, something which with a likewise misplaced pm_runtime_disable leads to external aborts when an open port is being removed. Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa024010 ... [<c046e760>] (serial_omap_set_mctrl) from [<c046a064>] (uart_update_mctrl+0x50/0x60) [<c046a064>] (uart_update_mctrl) from [<c046a400>] (uart_shutdown+0xbc/0x138) [<c046a400>] (uart_shutdown) from [<c046bd2c>] (uart_hangup+0x94/0x190) [<c046bd2c>] (uart_hangup) from [<c045b760>] (__tty_hangup+0x404/0x41c) [<c045b760>] (__tty_hangup) from [<c045b794>] (tty_vhangup+0x1c/0x20) [<c045b794>] (tty_vhangup) from [<c046ccc8>] (uart_remove_one_port+0xec/0x260) [<c046ccc8>] (uart_remove_one_port) from [<c046ef4c>] (serial_omap_remove+0x40/0x60) [<c046ef4c>] (serial_omap_remove) from [<c04845e8>] (platform_drv_remove+0x34/0x4c) Fix this up by resuming the device before deregistering the port and by suspending and disabling runtime pm only after the port has been removed. Also make sure to disable autosuspend before disabling runtime pm so that the usage count is balanced and device actually suspended before returning. Note that due to a negative autosuspend delay being set in probe, the unbalanced put would actually suspend the device on first driver unbind, while rebinding and again unbinding would result in a negative power.usage_count. Fixes: 7e9c8e7d ("serial: omap: make sure to suspend device before remove") Cc: Felipe Balbi <balbi@kernel.org> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
David Carrillo-Cisneros authored
commit bb8d521f upstream. All paths following perf_session__process_event() in __cmd_inject() are useless if __cmd_inject() is to fail, some depend on a correct session->evlist. First commit to add code that depends on session->evlist without checking error was commmit e558a5bd ("perf inject: Work with files"). It has grown since then. Change __cmd_inject() to fail immediately after perf_session__process_event() fails. Signed-off-by:
David Carrillo-Cisneros <davidcc@google.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andrew Vagin <avagin@openvz.org> Cc: He Kuang <hekuang@huawei.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Simon Que <sque@chromium.org> Cc: Stephane Eranian <eranian@google.com> Cc: Wang Nan <wangnan0@huawei.com> Fixes: e558a5bd ("perf inject: Work with files") Link: http://lkml.kernel.org/r/20170410201432.24807-2-davidcc@google.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Jason A. Donenfeld authored
commit 07a77929 upstream. The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Kieran Bingham authored
commit 360a3a90 upstream. The frame counters are inadvertently counting packets with content as empty. Fix it by correcting the logic expression Fixes: 7bc5edb0 [media] uvcvideo: Extract video stream statistics Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Johan Hovold authored
commit 65f92164 upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Johan Hovold authored
commit fff1abc4 upstream. Make sure to release the snd_card also on a late allocation error. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
-
Johan Hovold authored
commit 0cd273bb upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: e0d3bafd ("V4L/DVB (10954): Add cx231xx USB driver") Cc: Sri Deevi <Srinivasa.Deevi@conexant.com> Signed-off-by:
-
Johan Hovold authored
commit eacb975b upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 2a9f8b5d ("V4L/DVB (5206): Usbvision: set alternate interface modification") Cc: Thierry MERLE <thierry.merle@free.fr> Signed-off-by:
-
Johan Hovold authored
commit d5823511 upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: c4018fa2 ("[media] dib0700: fix RC support on Hauppauge Nova-TD") Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by:
-
Hannes Reinecke authored
commit 7a38dc0b upstream. The current medium access timeout counter will be increased for each command, so if there are enough failed commands we'll hit the medium access timeout for even a single device failure and the following kernel message is displayed: sd H:C:T:L: [sdXY] Medium access timeout failure. Offlining disk! Fix this by making the timeout per EH run, ie the counter will only be increased once per device and EH run. Fixes: 18a4d0a2 ("[SCSI] Handle disk devices which can not process medium access commands") Cc: Ewan Milne <emilne@redhat.com> Cc: Lawrence Obermann <loberman@redhat.com> Cc: Benjamin Block <bblock@linux.vnet.ibm.com> Cc: Steffen Maier <maier@linux.vnet.ibm.com> Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> [bwh: Backported to 3.16: - Open-code blk_rq_is_passthrough() - Adjust context] Signed-off-by:
-
Marek Szyprowski authored
commit a5cb00eb upstream. Clock should be turned off after calling s5p_mfc_init_hw() from the watchdog worker, like it is already done in the s5p_mfc_open() which also calls this function. Fixes: af935746 ("[media] MFC: Add MFC 5.1 V4L2 driver") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Johan Hovold authored
commit aa58fedb upstream. Make sure to check the number of endpoints to avoid accessing memory beyond the endpoint array should a device lack the expected endpoints. Note that, as far as I can tell, the gspca framework has already made sure there is at least one endpoint in the current alternate setting so there should be no risk for a NULL-pointer dereference here. Fixes: b517af72 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Hans Verkuil <hansverk@cisco.com> Signed-off-by:
-
Shamir Rabinovitch authored
commit 771a5258 upstream. When udev renames the netdev devices, ipoib debugfs entries does not get renamed. As a result, if subsequent probe of ipoib device reuse the name then creating a debugfs entry for the new device would fail. Also, moved ipoib_create_debug_files and ipoib_delete_debug_files as part of ipoib event handling in order to avoid any race condition between these. Fixes: 1732b0ef ([IPoIB] add path record information in debugfs) Signed-off-by:
Vijay Kumar <vijay.ac.kumar@oracle.com> Signed-off-by:
Shamir Rabinovitch <shamir.rabinovitch@oracle.com> Reviewed-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Fabian Frederick authored
commit e42fa209 upstream. Fix checkpatch warning: WARNING: debugfs_remove(NULL) is safe this check is probably not required Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Johan Hovold authored
commit ebeb3667 upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 36bcce43 ("ath9k_htc: Handle storage devices") Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Dan Carpenter authored
commit 1b497e64 upstream. The bug is that "val" is unsigned long but we only initialize 32 bits of it. Then we test "if (val)" and that might be true not because we set the bits but because some were never initialized. Fixes: f342d940 ("PCI: exynos: Add support for MSI") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Bjorn Helgaas authored
commit dbe4a09e upstream. Use "continue" to skip rest of the loop when possible to save an indent level. No functional change intended. Suggested-by:
walter harms <wharms@bfs.de> Signed-off-by:
-
Sergei Shtylyov authored
commit 0cbdc114 upstream. The IPSR field names in the comments have been fat-fingered in a couple places -- fix those silly typos... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Sergei Shtylyov authored
commit 58439280 upstream. PINMUX_IPSR_MSEL() macro invocation for the TX2 signal has apparently wrong 1st argument -- most probably a result of cut&paste programming... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit 3908632f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the DVC_MUTE signal altogether in the PFC section. The modern manual has the signal described, so just add the necassary data to the driver... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit da7a692f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the HSCIF1 group E signals in the IPSR4 register description. This would cause HSCIF1's probe to fail with the messages like below: sh-pfc e6060000.pfc: cannot locate data/mark enum_id for mark 1989 sh-sci e62c8000.serial: Error applying setting, reverse things back sh-sci: probe of e62c8000.serial failed with error -22 Add the neceassary PINMUX_IPSR_MSEL() invocations for the HSCK1_E, HCTS1#_E, and HRTS1#_E signals... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Tobias Herzog authored
commit 1bb9914e upstream. Notifications may only be 8 bytes long. Accessing the 9th and 10th byte of unimplemented/unknown notifications may be insecure. Also check the length of known notifications before accessing anything behind the 8th byte. Signed-off-by:
Tobias Herzog <t-herzog@gmx.de> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Ajay Kaher authored
USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously commit 2f86a96b upstream. There is race condition when two USB class drivers try to call init_usb_class at the same time and leads to crash. code path: probe->usb_register_dev->init_usb_class To solve this, mutex locking has been added in init_usb_class() and destroy_usb_class(). As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class() because usb_class can never be NULL there. Signed-off-by:
Ajay Kaher <ajay.kaher@samsung.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Eva Rachel Retuya authored
commit cf6c7732 upstream. Standard deviation is calculated as the square root of the variance where variance is the mean of sample_sum and length. Correct the computation of statP->stddev in accordance to the proper calculation. Fixes: 3c97c08b ("staging: iio: add TAOS tsl2x7x driver") Reported-by:
Abhiram Balasubramanian <abhiram@cs.utah.edu> Signed-off-by:
Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by:
-
Johan Hovold authored
commit 03eb2a55 upstream. Make sure to check for the required out endpoint to avoid dereferencing a NULL-pointer in mce_request_packet should a malicious device lack such an endpoint. Note that this path is hit during probe. Fixes: 66e89522 ("V4L/DVB: IR: add mceusb IR receiver driver") Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
commit 069f3b10 upstream. This has been broken for a long time, so presumably it is not used. I have no hardware to test this on. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61401 Fixes: 90ab5ee9 ("module_param: make bool parameters really bool") Signed-off-by:
-
Thomas Petazzoni authored
commit ee56874f upstream. In commit eea62819 ("mtd: Add device-tree support to fsmc_nand"), Device Tree support was added to the fmsc_nand driver. However, this code has a bug in how it handles the bank-width DT property to set the bus width. Indeed, in the function fsmc_nand_probe_config_dt() that parses the Device Tree, it sets pdata->width to either 8 or 16 depending on the value of the bank-width DT property. Then, the ->probe() function will test if pdata->width is equal to FSMC_NAND_BW16 (which is 2) to set NAND_BUSWIDTH_16 in nand->options. Therefore, with the DT probing, this condition will never match. This commit fixes that by removing the "width" field from fsmc_nand_platform_data and instead have the fsmc_nand_probe_config_dt() function directly set the appropriate nand->options value. It is worth mentioning that if this commit gets backported to older kernels, prior to the drop of non-DT probing, then non-DT probing will be broken because nand->options will no longer be set to NAND_BUSWIDTH_16. Fixes: eea62819 ("mtd: Add device-tree support to fsmc_nand") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> [bwh: Backported to 3.16: keep fsmc_and_platform_data::width and the test in fsmc_nand_probe()] Signed-off-by:
-
Guenter Roeck authored
commit f5cccf49 upstream. While running a bind/unbind stress test with the dwc3 usb driver on rk3399, the following crash was observed. Unable to handle kernel NULL pointer dereference at virtual address 00000218 pgd = ffffffc00165f000 [00000218] *pgd=000000000174f003, *pud=000000000174f003, *pmd=0000000001750003, *pte=00e8000001751713 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async ppp_generic slhc tun CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507 Hardware name: Google Kevin (DT) Workqueue: pm pm_runtime_work task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000 PC is at autosuspend_check+0x74/0x174 LR is at autosuspend_check+0x70/0x174 ... Call trace: [<ffffffc00080dcc0>] autosuspend_check+0x74/0x174 [<ffffffc000810500>] usb_runtime_idle+0x20/0x40 [<ffffffc000785ae0>] __rpm_callback+0x48/0x7c [<ffffffc000786af0>] rpm_idle+0x1e8/0x498 [<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc [<ffffffc000249bb8>] process_one_work+0x390/0x6b8 [<ffffffc00024abcc>] worker_thread+0x480/0x610 [<ffffffc000251a80>] kthread+0x164/0x178 [<ffffffc0002045d0>] ret_from_fork+0x10/0x40 Source: (gdb) l *0xffffffc00080dcc0 0xffffffc00080dcc0 is in autosuspend_check (drivers/usb/core/driver.c:1778). 1773 /* We don't need to check interfaces that are 1774 * disabled for runtime PM. Either they are unbound 1775 * or else their drivers don't support autosuspend 1776 * and so they are permanently active. 1777 */ 1778 if (intf->dev.power.disable_depth) 1779 continue; 1780 if (atomic_read(&intf->dev.power.usage_count) > 0) 1781 return -EBUSY; 1782 w |= intf->needs_remote_wakeup; Code analysis shows that intf is set to NULL in usb_disable_device() prior to setting actconfig to NULL. At the same time, usb_runtime_idle() does not lock the usb device, and neither does any of the functions in the traceback. This means that there is no protection against a race condition where usb_disable_device() is removing dev->actconfig->interface[] pointers while those are being accessed from autosuspend_check(). To solve the problem, synchronize and validate device state between autosuspend_check() and usb_disconnect(). Acked-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
