- 21 7月, 2019 17 次提交
-
-
由 Sergej Benilov 提交于
[ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ] Since commit 605ad7f1 "tcp: refine TSO autosizing", outbound throughput is dramatically reduced for some connections, as sis900 is doing TX completion within idle states only. Make TX completion happen after every transmitted packet. Test: netperf before patch: > netperf -H remote -l -2000000 -- -s 1000000 MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 327680 327680 253.44 0.06 after patch: > netperf -H remote -l -10000000 -- -s 1000000 MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 327680 327680 5.38 14.89 Thx to Dave Miller and Eric Dumazet for helpful hints Signed-off-by: NSergej Benilov <sergej.benilov@googlemail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Takashi Iwai 提交于
[ Upstream commit aad1dcc4f011ea409850e040363dff1e59aa4175 ] The arc4 crypto is mandatory at ppp_mppe probe time, so let's put a softdep line, so that the corresponding module gets prepared gracefully. Without this, a simple inclusion to initrd via dracut failed due to the missing dependency, for example. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Petr Oros 提交于
[ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ] Certain cards in conjunction with certain switches need a little more time for link setup that results in ethtool link test failure after offline test. Patch adds a loop that waits for a link setup finish. Changes in v2: - added fixes header Fixes: 4276e47e ("be2net: Add link test to list of ethtool self tests.") Signed-off-by: NPetr Oros <poros@redhat.com> Reviewed-by: NIvan Vecera <ivecera@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Colin Ian King 提交于
[ Upstream commit ea136a112d89bade596314a1ae49f748902f4727 ] The left shift of unsigned int cpu_khz will overflow for large values of cpu_khz, so cast it to a long long before shifting it to avoid overvlow. For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 8c3ba8d0 ("x86, apic: ack all pending irqs when crashed/on kexec") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Borislav Petkov <bp@alien8.de> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20190619181446.13635-1-colin.king@canonical.comSigned-off-by: NSasha Levin <sashal@kernel.org>
-
由 David Howells 提交于
[ Upstream commit 90fa9b64523a645a97edc0bdcf2d74759957eeee ] Fix the cb_break_lock spinlock in afs_volume struct by initialising it when the volume record is allocated. Also rename the lock to cb_v_break_lock to distinguish it from the lock of the same name in the afs_server struct. Without this, the following trace may be observed when a volume-break callback is received: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 50 Comm: kworker/2:1 Not tainted 5.2.0-rc1-fscache+ #3045 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Workqueue: afs SRXAFSCB_CallBack Call Trace: dump_stack+0x67/0x8e register_lock_class+0x23b/0x421 ? check_usage_forwards+0x13c/0x13c __lock_acquire+0x89/0xf73 lock_acquire+0x13b/0x166 ? afs_break_callbacks+0x1b2/0x3dd _raw_write_lock+0x2c/0x36 ? afs_break_callbacks+0x1b2/0x3dd afs_break_callbacks+0x1b2/0x3dd ? trace_event_raw_event_afs_server+0x61/0xac SRXAFSCB_CallBack+0x11f/0x16c process_one_work+0x2c5/0x4ee ? worker_thread+0x234/0x2ac worker_thread+0x1d8/0x2ac ? cancel_delayed_work_sync+0xf/0xf kthread+0x11f/0x127 ? kthread_park+0x76/0x76 ret_from_fork+0x24/0x30 Fixes: 68251f0a ("afs: Fix whole-volume callback handling") Signed-off-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Arnd Bergmann 提交于
[ Upstream commit 27e23d8975270df6999f8b5b3156fc0c04927451 ] omap3xxx_prm_enable_io_wakeup() is marked __init, but its caller is not, so we get a warning with clang-8: WARNING: vmlinux.o(.text+0x343c8): Section mismatch in reference from the function omap3xxx_prm_late_init() to the function .init.text:omap3xxx_prm_enable_io_wakeup() The function omap3xxx_prm_late_init() references the function __init omap3xxx_prm_enable_io_wakeup(). This is often because omap3xxx_prm_late_init lacks a __init annotation or the annotation of omap3xxx_prm_enable_io_wakeup is wrong. When building with gcc, omap3xxx_prm_enable_io_wakeup() is always inlined, so we never noticed in the past. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Acked-by: NTony Lindgren <tony@atomide.com> Reviewed-by: NAndrew Murray <andrew.murray@arm.com> Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Linus Walleij 提交于
[ Upstream commit 36558020128b1a48b7bddd5792ee70e3f64b04b0 ] It's a simple typo in the DNS file, which was pretty serious. No scripts were working properly. Fix it up. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Peter Zijlstra 提交于
[ Upstream commit 085ebfe937d7a7a5df1729f35a12d6d655fea68c ] perf_sample_regs_user() uses 'current->mm' to test for the presence of userspace, but this is insufficient, consider use_mm(). A better test is: '!(current->flags & PF_KTHREAD)', exec() clears PF_KTHREAD after it sets the new ->mm but before it drops to userspace for the first time. Possibly obsoletes: bf05fc25 ("powerpc/perf: Fix oops when kthread execs user process") Reported-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Reported-by: NYoung Xiao <92siuyang@gmail.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NWill Deacon <will.deacon@arm.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 4018994f ("perf: Add ability to attach user level registers dump to sample") Signed-off-by: NIngo Molnar <mingo@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Hans de Goede 提交于
[ Upstream commit a483fcab38b43fb34a7f12ab1daadd3907f150e2 ] Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed. The first device using these bits has now shown up (the GPD MicroPC) and the reserved bits check causes us to reject the valid BGRT table on this device. Rather then changing the reserved bits check, allowing only the 2 new bits, instead just completely remove it so that we do not end up with a similar problem when more bits are added in the future. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Tony Lindgren 提交于
[ Upstream commit 41b3588dba6ef4b7995735a97e47ff0aeea6c276 ] If we do a clk_get() for a clock that does not exists, we have _ti_omap4_clkctrl_xlate() return uninitialized data if no match is found. This can be seen in some cases with SLAB_DEBUG enabled: Unable to handle kernel paging request at virtual address 5a5a5a5a ... clk_hw_create_clk.part.33 sysc_notifier_call notifier_call_chain blocking_notifier_call_chain device_add Let's fix this by setting a found flag only when we find a match. Reported-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks") Signed-off-by: NTony Lindgren <tony@atomide.com> Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: NStephen Boyd <sboyd@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Heyi Guo 提交于
[ Upstream commit a050fa5476d418fc16b25abe168b3d38ba11e13c ] When we run several VMs with PCI passthrough and GICv4 enabled, not pinning vCPUs, we will occasionally see below warnings in dmesg: ITS queue timeout (65440 65504 480) ITS cmd its_build_vmovp_cmd failed The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC: 1. Post the write command. 2. Release the lock. 3. Start to read GITS_CREADR to get the reader pointer. 4. Compare the reader pointer to the target pointer. 5. If reader pointer does not reach the target, sleep 1us and continue to try. If we have several processors running the above concurrently, other CPUs will post write commands while the 1st CPU is waiting the completion. So we may have below issue: phase 1: ---rd_idx-----from_idx-----to_idx--0--------- wait 1us: phase 2: --------------from_idx-----to_idx--0-rd_idx-- That is the rd_idx may fly ahead of to_idx, and if in case to_idx is near the wrap point, rd_idx will wrap around. So the below condition will not be met even after 1s: if (from_idx < to_idx && rd_idx >= to_idx) There is another theoretical issue. For a slow and busy ITS, the initial rd_idx may fall behind from_idx a lot, just as below: ---rd_idx---0--from_idx-----to_idx----------- This will cause the wait function exit too early. Actually, it does not make much sense to use from_idx to judge if to_idx is wrapped, but we need a initial rd_idx when lock is still acquired, and it can be used to judge whether to_idx is wrapped and the current rd_idx is wrapped. We switch to a method of calculating the delta of two adjacent reads and accumulating it to get the sum, so that we can get the real rd_idx from the wrapped value even when the queue is almost full. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by: NHeyi Guo <guoheyi@huawei.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org>
-
由 Sven Van Asbroeck 提交于
commit 2472d64af2d3561954e2f05365a67692bb852f2a upstream. The firmware loader queries if LSM/IMA permits it to load firmware via the sysfs fallback. Unfortunately, the code does the opposite: it expressly permits sysfs fw loading if security_kernel_load_data( LOADING_FIRMWARE) returns -EACCES. This happens because a zero-on-success return value is cast to a bool that's true on success. Fix the return value handling so we get the correct behaviour. Fixes: 6e852651 ("firmware: add call to LSM hook before firmware sysfs fallback") Cc: Stable <stable@vger.kernel.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Kees Cook <keescook@chromium.org> To: Luis Chamberlain <mcgrof@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com> Reviewed-by: NMimi Zohar <zohar@linux.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 James Morse 提交于
commit 83b44fe343b5abfcb1b2261289bd0cfcfcfd60a8 upstream. The cacheinfo structures are alloced/freed by cpu online/offline callbacks. Originally these were only used by sysfs to expose the cache topology to user space. Without any in-kernel dependencies CPUHP_AP_ONLINE_DYN was an appropriate choice. resctrl has started using these structures to identify CPUs that share a cache. It updates its 'domain' structures from cpu online/offline callbacks. These depend on the cacheinfo structures (resctrl_online_cpu()->domain_add_cpu()->get_cache_id()-> get_cpu_cacheinfo()). These also run as CPUHP_AP_ONLINE_DYN. Now that there is an in-kernel dependency, move the cacheinfo work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN work runs. Fixes: 2264d9c7 ("x86/intel_rdt: Build structures for each resource based on cache topology") Cc: <stable@vger.kernel.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJames Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20190624173656.202407-1-james.morse@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Masahiro Yamada 提交于
commit c32cc30c0544f13982ee0185d55f4910319b1a79 upstream. cpu_to_le32/le32_to_cpu is defined in include/linux/byteorder/generic.h, which is not exported to user-space. UAPI headers must use the ones prefixed with double-underscore. Detected by compile-testing exported headers: include/linux/nilfs2_ondisk.h: In function `nilfs_checkpoint_set_snapshot': include/linux/nilfs2_ondisk.h:536:17: error: implicit declaration of function `cpu_to_le32' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h:536:29: error: implicit declaration of function `le32_to_cpu' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h: In function `nilfs_segment_usage_set_clean': include/linux/nilfs2_ondisk.h:622:19: error: implicit declaration of function `cpu_to_le64' [-Werror=implicit-function-declaration] su->su_lastmod = cpu_to_le64(0); ^~~~~~~~~~~ Link: http://lkml.kernel.org/r/20190605053006.14332-1-yamada.masahiro@socionext.com Fixes: e63e88bc ("nilfs2: move ioctl interface and disk layout to uapi separately") Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NRyusuke Konishi <konishi.ryusuke@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Joe Perches <joe@perches.com> Cc: <stable@vger.kernel.org> [4.9+] Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Cole Rogers 提交于
commit abbe3acd7d72ab4633ade6bd24e8306b67e0add3 upstream. Thinkpad t480 laptops had some touchpad features disabled, resulting in the loss of pinch to activities in GNOME, on wayland, and other touch gestures being slower. This patch adds the touchpad of the t480 to the smbus_pnp_ids whitelist to enable the extra features. In my testing this does not break suspend (on fedora, with wayland, and GNOME, using the rc-6 kernel), while also fixing the feature on a T480. Signed-off-by: NCole Rogers <colerogers@disroot.org> Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Konstantin Khlebnikov 提交于
commit d17ba0f616a08f597d9348c372d89b8c0405ccf3 upstream. Driver does not want to keep packets in Tx queue when link is lost. But present code only reset NIC to flush them, but does not prevent queuing new packets. Moreover reset sequence itself could generate new packets via netconsole and NIC falls into endless reset loop. This patch wakes Tx queue only when NIC is ready to send packets. This is proper fix for problem addressed by commit 0f9e980bf5ee ("e1000e: fix cyclic resets at link up with active tx"). Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Suggested-by: NAlexander Duyck <alexander.duyck@gmail.com> Tested-by: NJoseph Yasi <joe.yasi@gmail.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Tested-by: NOleksandr Natalenko <oleksandr@redhat.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Konstantin Khlebnikov 提交于
commit caff422ea81e144842bc44bab408d85ac449377b upstream. This reverts commit 0f9e980bf5ee1a97e2e401c846b2af989eb21c61. That change cased false-positive warning about hardware hang: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean]: time_stamp <fffba7a7> next_to_watch <0> jiffies <fffbb140> next_to_watch.status <0> MAC Status <40080080> PHY Status <7949> PHY 1000BASE-T Status <0> PHY Extended Status <3000> PCI Status <10> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Besides warning everything works fine. Original issue will be fixed property in following patch. Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru> Reported-by: NJoseph Yasi <joe.yasi@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203175Tested-by: NJoseph Yasi <joe.yasi@gmail.com> Tested-by: NAaron Brown <aaron.f.brown@intel.com> Tested-by: NOleksandr Natalenko <oleksandr@redhat.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 14 7月, 2019 23 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
由 Arnd Bergmann 提交于
commit fbd6b25009ac76b2034168cd21d5e01f8c2d83d1 upstream. An earlier patch I sent reduced the stack usage enough to get below the warning limit, and I could show this was safe, but with GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, it gets worse again because large stack variables in the same function no longer overlap: drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function 'translate_scan.isra.2': drivers/staging/rtl8712/rtl871x_ioctl_linux.c:322:1: error: the frame size of 1200 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Split out the largest two blocks in the affected function into two separate functions and mark those noinline_for_stack. Fixes: 8c5af16f ("staging: rtl8712: reduce stack usage") Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dave Stevenson 提交于
commit a26be06d6d96c10a9ab005e99d93fbb5d3babd98 upstream. The change to mapping V4L2 to MMAL buffers 1:1 didn't handle the condition we get with raw pixel buffers (eg YUV and RGB) direct from the camera's stills port. That sends the pixel buffer and then an empty buffer with the EOS flag set. The EOS buffer wasn't handled and returned an error up the stack. Handle the condition correctly by returning it to the component if streaming, or returning with an error if stopping streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dave Stevenson 提交于
commit bb8e97006d701ae725a177f8f322e5a75fa761b7 upstream. Before commit "staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping" there was a need to ensure that there were sufficient buffers supplied from the user to cover those being sent to the VPU (always 1). Now the buffers are linked 1:1 between MMAL and V4L2, therefore there is no need for that check, and indeed it is wrong as there is no need to submit all the buffers before starting streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dave Stevenson 提交于
commit 70ec64ccdaac5d8f634338e33b016c1c99831499 upstream. With the recent change to match MMAL and V4L2 buffers there is a need to wait for all MMAL buffers to be returned during stop_streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Dave Stevenson 提交于
commit 8dedab2903f152aa3cee9ae3d57c828dea0d356e upstream. The commit "staging: bcm2835-camera: Replace open-coded idr with a struct idr." replaced an internal implementation of an idr with the standard functions and a spinlock. idr_alloc(GFP_KERNEL) can sleep whilst calling kmem_cache_alloc to allocate the new node, but this is not valid whilst in an atomic context due to the spinlock. There is no need for this to be a spinlock as a standard mutex is sufficient. Fixes: 950fd867 ("staging: bcm2835-camera: Replace open-coded idr with a struct idr.") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by: NStefan Wahren <wahrenst@gmx.net> Acked-by: NHans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Colin Ian King 提交于
commit 5555ebbbac822b4fa28db2be15aaf98b3c21af26 upstream. In the default event case switchdev_work is being leaked because nothing is queued for work. Fix this by kfree'ing switchdev_work before returning NOTIFY_DONE. Addresses-Coverity: ("Resource leak") Fixes: 44baaa43 ("staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sean Young 提交于
commit 1287533d3d95d5ad8b02773733044500b1be06bc upstream. When building BPF code using "clang -target bpf -c", clang does not define __linux__. To build BPF IR decoders the include linux/lirc.h is needed which includes linux/types.h. Currently this workaround is needed: https://git.linuxtv.org/v4l-utils.git/commit/?id=dd3ff81f58c4e1e6f33765dc61ad33c48ae6bb07 This check might otherwise be useful to stop users from using a non-linux compiler, but if you're doing that you are going to have a lot more trouble anyway. Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NPaul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21149/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Vishnu DASA 提交于
commit 1c2eb5b2853c9f513690ba6b71072d8eb65da16a upstream. The VMCI handle array has an integer overflow in vmci_handle_arr_append_entry when it tries to expand the array. This can be triggered from a guest, since the doorbell link hypercall doesn't impose a limit on the number of doorbell handles that a VM can create in the hypervisor, and these handles are stored in a handle array. In this change, we introduce a mandatory max capacity for handle arrays/lists to avoid excessive memory usage. Signed-off-by: NVishnu Dasa <vdasa@vmware.com> Reviewed-by: NAdit Ranadive <aditr@vmware.com> Reviewed-by: NJorgen Hansen <jhansen@vmware.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Christian Lamparter 提交于
commit feb09b2933275a70917a869989ea2823e7356be8 upstream. This patch follows Alan Stern's recent patch: "p54: Fix race between disconnect and firmware loading" that overhauled carl9170 buggy firmware loading and driver unbinding procedures. Since the carl9170 code was adapted from p54 it uses the same functions and is likely to have the same problem, but it's just that the syzbot hasn't reproduce them (yet). a summary from the changes (copied from the p54 patch): * Call usb_driver_release_interface() rather than device_release_driver(). * Lock udev (the interface's parent) before unbinding the driver instead of locking udev->parent. * During the firmware loading process, take a reference to the USB interface instead of the USB device. * Don't take an unnecessary reference to the device during probe (and then don't drop it during disconnect). and * Make sure to prevent use-after-free bugs by explicitly setting the driver context to NULL after signaling the completion. Cc: <stable@vger.kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NChristian Lamparter <chunkeey@gmail.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Todd Kjos 提交于
commit 1909a671dbc3606685b1daf8b22a16f65ea7edda upstream. syzkallar found a 32-byte memory leak in a rarely executed error case. The transaction complete work item was not freed if put_user() failed when writing the BR_TRANSACTION_COMPLETE to the user command buffer. Fixed by freeing it before put_user() is called. Reported-by: syzbot+182ce46596c3f2e1eb24@syzkaller.appspotmail.com Signed-off-by: NTodd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nick Desaulniers 提交于
commit e9e08a07385e08f1a7f85c5d1e345c21c9564963 upstream. With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors: llvm-objcopy: error: --set-section-flags=.text conflicts with --rename-section=.text=.rodata Rather than support setting flags then renaming sections vs renaming then setting flags, it's simpler to just change both at the same time via --rename-section. Adding the load flag is required for GNU objcopy to mark .rodata Type as PROGBITS after the rename. This can be verified with: $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o ... Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [ 1] .rodata PROGBITS 0000000000000000 00000040 0000000000000004 0000000000000000 A 0 0 4 ... Which shows that .text is now renamed .rodata, the alloc flag A is set, the type is PROGBITS, and the section is not flagged as writeable W. Cc: stable@vger.kernel.org Link: https://sourceware.org/bugzilla/show_bug.cgi?id=24554 Link: https://github.com/ClangBuiltLinux/linux/issues/448Reported-by: NNathan Chancellor <natechancellor@gmail.com> Suggested-by: NAlan Modra <amodra@gmail.com> Suggested-by: NJordan Rupprect <rupprecht@google.com> Suggested-by: NKees Cook <keescook@chromium.org> Acked-by: NKees Cook <keescook@chromium.org> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Signed-off-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sebastian Parschauer 提交于
commit 4c12954965fdf33d8ae3883c1931fc29ca023cfb upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this Alienware branded Primax mouse as well. Daniel Schepler (@dschepler) reported and tested the quirk. Reference: https://github.com/sriemer/fix-linux-mouse/issues/15Signed-off-by: NSebastian Parschauer <s.parschauer@gmx.de> CC: stable@vger.kernel.org Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ian Abbott 提交于
commit 7379e6baeddf580d01feca650ec1ad508b6ea8ee upstream. The interrupt handler `pci230_interrupt()` causes a null pointer dereference for a PCI260 card. There is no analog output subdevice for a PCI260. The `dev->write_subdev` subdevice pointer and therefore the `s_ao` subdevice pointer variable will be `NULL` for a PCI260. The following call near the end of the interrupt handler results in the null pointer dereference for a PCI260: comedi_handle_events(dev, s_ao); Fix it by only calling the above function if `s_ao` is valid. Note that the other uses of `s_ao` in the calls `pci230_handle_ao_nofifo(dev, s_ao);` and `pci230_handle_ao_fifo(dev, s_ao);` will never be reached for a PCI260, so they are safe. Fixes: 39064f23 ("staging: comedi: amplc_pci230: use comedi_handle_events()") Cc: <stable@vger.kernel.org> # v3.19+ Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ian Abbott 提交于
commit b8336be66dec06bef518030a0df9847122053ec5 upstream. The interrupt handler `dt282x_interrupt()` causes a null pointer dereference for those supported boards that have no analog output support. For these boards, `dev->write_subdev` will be `NULL` and therefore the `s_ao` subdevice pointer variable will be `NULL`. In that case, the following call near the end of the interrupt handler results in a null pointer dereference: comedi_handle_events(dev, s_ao); Fix it by only calling the above function if `s_ao` is valid. (There are other uses of `s_ao` by the interrupt handler that may or may not be reached depending on values of hardware registers. Trust that they are reliable for now.) Note: commit 4f6f009b ("staging: comedi: dt282x: use comedi_handle_events()") propagates an earlier error from commit f21c74fa ("staging: comedi: dt282x: use cfc_handle_events()"). Fixes: 4f6f009b ("staging: comedi: dt282x: use comedi_handle_events()") Cc: <stable@vger.kernel.org> # v3.19+ Signed-off-by: NIan Abbott <abbotti@mev.co.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nikolaus Voss 提交于
commit 2681795b5e7a5bf336537661010072f4c22cea31 upstream. Writing 4CC commands with tps6598x_write_4cc() already has a pointer arg, don't reference it when using as arg to tps6598x_block_write(). Correcting this enforces the constness of the pointer to propagate to tps6598x_block_write(), so add the const qualifier there to avoid the warning. Fixes: 0a4c005b ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Signed-off-by: NNikolaus Voss <nikolaus.voss@loewensteinmedical.de> Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nikolaus Voss 提交于
commit 05da75fc651138e51ff74ace97174349910463f5 upstream. Portinfo bit field is 3 bits wide, not 2 bits. This led to a wrong driver configuration for some tps6598x configurations. Fixes: 0a4c005b ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Signed-off-by: NNikolaus Voss <nikolaus.voss@loewensteinmedical.de> Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Yoshihiro Shimoda 提交于
commit b2357839c56ab7d06bcd4e866ebc2d0e2b7997f3 upstream. The old commit 6e4b74e4 ("usb: renesas: fix scheduling in atomic context bug") fixed an atomic issue by using workqueue for the shdmac dmaengine driver. However, this has a potential race condition issue between the work pending and usbhsg_ep_free_request() in gadget mode. When usbhsg_ep_free_request() is called while pending the queue, since the work_struct will be freed and then the work handler is called, kernel panic happens on process_one_work(). To fix the issue, if we could call cancel_work_sync() at somewhere before the free request, it could be easy. However, the usbhsg_ep_free_request() is called on atomic (e.g. f_ncm driver calls free request via gether_disconnect()). For now, almost all users are having "USB-DMAC" and the DMAengine driver can be used on atomic. So, this patch adds a workaround for a race condition to call the DMAengine APIs without the workqueue. This means we still have TODO on shdmac environment (SH7724), but since it doesn't have SMP, the race condition might not happen. Fixes: ab330cf3 ("usb: renesas_usbhs: add support for USB-DMAC") Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Martin Blumenstingl 提交于
commit dfc4fdebc5d62ac4e2fe5428e59b273675515fb2 upstream. Use a 10000us AHB idle timeout in dwc2_core_reset() and make it consistent with the other "wait for AHB master IDLE state" ocurrences. This fixes a problem for me where dwc2 would not want to initialize when updating to 4.19 on a MIPS Lantiq VRX200 SoC. dwc2 worked fine with 4.14. Testing on my board shows that it takes 180us until AHB master IDLE state is signalled. The very old vendor driver for this SoC (ifxhcd) used a 1 second timeout. Use the same timeout that is used everywhere when polling for GRSTCTL_AHBIDLE instead of using a timeout that "works for one board" (180us in my case) to have consistent behavior across the dwc2 driver. Cc: linux-stable <stable@vger.kernel.org> # 4.19+ Acked-by: NMinas Harutyunyan <hminas@synopsys.com> Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Kiruthika Varadarajan 提交于
commit d29fcf7078bc8be2b6366cbd4418265b53c94fac upstream. On spin lock release in rx_submit, gether_disconnect get a chance to run, it makes port_usb NULL, rx_submit access NULL port USB, hence null pointer crash. Fixed by releasing the lock in rx_submit after port_usb is used. Fixes: 2b3d942c ("usb ethernet gadget: split out network core") Cc: <stable@vger.kernel.org> Signed-off-by: NKiruthika Varadarajan <Kiruthika.Varadarajan@harman.com> Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
commit 6e41e2257f1094acc37618bf6c856115374c6922 upstream. The syzbot fuzzer found a bug in the p54 USB wireless driver. The issue involves a race between disconnect and the firmware-loader callback routine, and it has several aspects. One big problem is that when the firmware can't be loaded, the callback routine tries to unbind the driver from the USB _device_ (by calling device_release_driver) instead of from the USB _interface_ to which it is actually bound (by calling usb_driver_release_interface). The race involves access to the private data structure. The driver's disconnect handler waits for a completion that is signalled by the firmware-loader callback routine. As soon as the completion is signalled, you have to assume that the private data structure may have been deallocated by the disconnect handler -- even if the firmware was loaded without errors. However, the callback routine does access the private data several times after that point. Another problem is that, in order to ensure that the USB device structure hasn't been freed when the callback routine runs, the driver takes a reference to it. This isn't good enough any more, because now that the callback routine calls usb_driver_release_interface, it has to ensure that the interface structure hasn't been freed. Finally, the driver takes an unnecessary reference to the USB device structure in the probe function and drops the reference in the disconnect handler. This extra reference doesn't accomplish anything, because the USB core already guarantees that a device structure won't be deallocated while a driver is still bound to any of its interfaces. To fix these problems, this patch makes the following changes: Call usb_driver_release_interface() rather than device_release_driver(). Don't signal the completion until after the important information has been copied out of the private data structure, and don't refer to the private data at all thereafter. Lock udev (the interface's parent) before unbinding the driver instead of locking udev->parent. During the firmware loading process, take a reference to the USB interface instead of the USB device. Don't take an unnecessary reference to the device during probe (and then don't drop it during disconnect). Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Acked-by: NChristian Lamparter <chunkeey@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Oliver Barta 提交于
commit 3f2640ed7be838c3f05c0d2b0f7c7508e7431e48 upstream. This reverts commit 2e9fe539. Reading LSR unconditionally but processing the error flags only if UART_IIR_RDI bit was set before in IIR may lead to a loss of transmission error information on UARTs where the transmission error flags are cleared by a read of LSR. Information are lost in case an error is detected right before the read of LSR while processing e.g. an UART_IIR_THRI interrupt. Signed-off-by: NOliver Barta <o.barta89@gmail.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: 2e9fe539 ("serial: 8250: Don't service RX FIFO if interrupts are disabled") Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jörgen Storvist 提交于
commit aed2a26283528fb69c38e414f649411aa48fb391 upstream. Added USB IDs for GosunCn ME3630 cellular module in RNDIS mode. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=03 Dev#= 18 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=0601 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=b950269c C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option Signed-off-by: NJörgen Storvist <jorgen.storvist@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-