- 24 Aug, 2018 40 commits
-
-
Nicholas Mc Guire authored
[ Upstream commit 342639d9 ] The call to of_get_next_child() returns a node pointer with refcount incremented thus it must be explicitly decremented here after the last usage. Fixes: ab597d35 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nicholas Mc Guire authored
[ Upstream commit 8c3f9bd8 ] The call to of_get_next_child() returns a node pointer with refcount incremented thus it must be explicitly decremented here after the last usage. Fixes: 8961def5 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver") Signed-off-by:
-
Daniel Borkmann authored
[ Upstream commit f605ce5e ] If we would ever fail in the bpf_jit_prog() pass that writes the actual insns to the image after we got header via bpf_jit_binary_alloc() then we also need to make sure to free it through bpf_jit_binary_free() again when bailing out. Given we had prior bpf_jit_prog() passes to initially probe for clobbered registers, program size and to fill in addrs arrray for jump targets, this is more of a theoretical one, but at least make sure this doesn't break with future changes. Fixes: 05462310 ("s390/bpf: Add s390x eBPF JIT compiler backend") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit fad2d4ef ] Fix the test that verifies whether bio_op(bio) represents a discard or write zeroes operation. Compile-tested only. Cc: Philipp Reisner <philipp.reisner@linbit.com> Cc: Lars Ellenberg <lars.ellenberg@linbit.com> Fixes: 7435e901 ("drbd: zero-out partial unaligned discards on local backend") Signed-off-by:
Bart Van Assche <bart.vanassche@wdc.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 7b7aa62c ] The only bits that should be preserved in decon_win_set_fmt() is WINCONx_ENWIN_F. All other bits depends on the selected pixel formats and are set by the mentioned function. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit ab337fc2 ] Set per-plane global alpha to maximum value to get proper blending of XRGB and ARGB planes. This fixes the strange order of overlapping planes. Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit dd209ef8 ] Fix following issues related to planar YUV pixel format configuration: - NV16/61 modes were incorrectly programmed as NV12/21, - YVU420 was programmed as YUV420 on source, - YVU420 and YUV422 were programmed as YUV420 on output. Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 95bca62f ] At the very least we should check the return value if nla_parse_nested() is called with a non-NULL policy. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Bob Copeland authored
[ Upstream commit 188f60ab ] Commit 9757235f, "nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value") relaxed the range for the HT operation field in meshconf, while also adding checks requiring the non-greenfield and non-ht-sta bits to be set in certain circumstances. The latter bit is actually reserved for mesh BSSes according to Table 9-168 in 802.11-2016, so in fact it should not be set. wpa_supplicant sets these bits because the mesh and AP code share the same implementation, but authsae does not. As a result, some meshconf updates from authsae which set only the NONHT_MIXED protection bits were being rejected. In order to avoid breaking userspace by changing the rules again, simply accept the values with or without the bits set, and mask off the reserved bit to match the spec. While in here, update the 802.11-2012 reference to 802.11-2016. Fixes: 9757235f ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value") Cc: Masashi Honma <masashi.honma@gmail.com> Signed-off-by:
Bob Copeland <bobcopeland@fb.com> Reviewed-by:
Masashi Honma <masashi.honma@gmail.com> Reviewed-by:
-
Jeff Moyer authored
[ Upstream commit 5a14e91d ] This is easily triggered from userspace, so let's ratelimit the messages. Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
BingJing Chang authored
[ Upstream commit bda31539 ] During assemble, the spare marked for replacement is not checked. conf->fullsync cannot be updated to be 1. As a result, recovery will treat it as a clean array. All recovering sectors are skipped. Original device is replaced with the not-recovered spare. mdadm -C /dev/md0 -l10 -n4 -pn2 /dev/loop[0123] mdadm /dev/md0 -a /dev/loop4 mdadm /dev/md0 --replace /dev/loop0 mdadm -S /dev/md0 # stop array during recovery mdadm -A /dev/md0 /dev/loop[01234] After reassemble, you can see recovery go on, but it completes immediately. In fact, recovery is not actually processed. To solve this problem, we just add the missing logics for replacment spares. (In raid1.c or raid5.c, they have already been checked.) Reported-by:
Alex Chen <alexchen@synology.com> Reviewed-by:
Alex Wu <alexwu@synology.com> Reviewed-by:
Chung-Chiang Cheng <cccheng@synology.com> Signed-off-by:
BingJing Chang <bingjingc@synology.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Ryan Hsu authored
[ Upstream commit 9191fc2a ] In the case of Station connects to AP with narrower bandwidth at beginning. And later the AP changes the bandwidth to winder bandwidth, the AP will beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80. Since the supported BANDWIDTH will be limited by the PHYMODE, so while Station receives the bandwidth change request, it will also need to reconfigure the PHYMODE setting to firmware instead of just configuring the BANDWIDTH info, otherwise it'll trigger a firmware crash with non-support bandwidth. The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with below scenario: AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz) disconnect from AP xxx for new auth to yyy RX ReassocResp from xxx (capab=0x1111 status=0 aid=102) associated .... AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz) AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz) .... firmware register dump: [00]: 0x05030000 0x000015B3 0x00987291 0x00955B31 [04]: 0x00987291 0x00060730 0x00000004 0x00000001 [08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000 [12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6 [16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D [20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C [24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291 [28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4 [32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8 [36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001 [40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554 [44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001 [48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0 [52]: 0x80911154 0x0040EB28 0x00400000 0x00000000 [56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600 Reported-by:
Rouven Czerwinski <rouven@czerwinskis.de> Tested-by:
Timur Kristóf <timur.kristof@gmail.com> Signed-off-by:
Ryan Hsu <ryanhsu@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit c4c2b764 ] The d->chans[] array has d->dma_requests elements so the > should be >= here. Fixes: 8e6152bc ("dmaengine: Add hisilicon k3 DMA engine driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit e3f329c6 ] The reported residue is already calculated in BURST unit granularity, so advertise this capability properly to other devices in the system. Fixes: aee4d1fa ("dmaengine: pl330: improve pl330_tx_status() function") Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit 1c38f4af ] meson-gxl-mali.dtsi is only used on GXL SoCs. Thus it should use the GXL specific compatible string instead of the GXBB one. For now this is purely cosmetic since the (out-of-tree) lima driver for this GPU currently uses the "arm,mali-450" match instead of the SoC specific one. However, update the .dts to match the documentation since this driver behavior might change in the future. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Keerthy authored
[ Upstream commit 3eb1b955 ] The intc #interrupt-cells is equal to 1. Currently gpio node has 2 cells per IRQ which is wrong. Remove the additional cell for each of the interrupts. Signed-off-by:
Keerthy <j-keerthy@ti.com> Fixes: 2e38b946 ("ARM: davinci: da850: add GPIO DT node") Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Andy Lutomirski authored
[ Upstream commit e8a445de ] We have short names for the requested and resulting register values. Use them instead of spelling out the whole register entry for each case. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/bb3bc1f923a2f6fe7912d22a1068fe29d6033d38.1530076529.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
[ Upstream commit ec348020 ] When I wrote the sigreturn test, I didn't realize that AMD's busted IRET behavior was different from Intel's busted IRET behavior: On AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer to certain userspace contexts. Gee, thanks. There's very little the kernel can do about it. Modify the test so it passes. Signed-off-by:
-
Chengguang Xu authored
[ Upstream commit 2d259571 ] sizeof() will return unsigned value so in the error check negative error code will be always larger than sizeof(). Fixes: a0d8e02c ("nfp: add support for reading nffw info") Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eli Cohen authored
[ Upstream commit a8d70a05 ] In smartnic env, if the host (PF) driver is not an e-switch manager, we are not allowed to apply eswitch ports setups such as vlan (VST), spoof-checks, min/max rate or state. Make sure we are eswitch manager when coming to issue these callbacks and err otherwise. Also fix the definition of ESW_ALLOWED to rely on eswitch_manager capability and on the vport_group_manger. Operations on the VF nic vport context, such as setting a mac or reading the vport counters are allowed to the PF in this scheme. The modify nic vport guid code was modified to omit checking the nic_vport_node_guid_modify eswitch capability. The reason for doing so is that modifying node guid requires vport group manager capability, and there's no need to check further capabilities. 1. set_vf_vlan - disallowed 2. set_vf_spoofchk - disallowed 3. set_vf_mac - allowed 4. get_vf_config - allowed 5. set_vf_trust - disallowed 6. set_vf_rate - disallowed 7. get_vf_stat - allowed 8. set_vf_link_state - disallowed Fixes: f942380c ('net/mlx5: E-Switch, Vport ingress/egress ACLs rules for spoofchk') Signed-off-by:
Eli Cohen <eli@mellanox.com> Reviewed-by:
Or Gerlitz <ogerlitz@mellanox.com> Tested-by:
-
Yan, Zheng authored
[ Upstream commit 8b8f53af ] In any case, d_splice_alias() does not drop reference of original dentry. Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Jann Horn authored
[ Upstream commit dffd22ae ] When proc_dostring() is called with a non-zero offset in strict mode, it doesn't just write to the ->data buffer, it also reads. Make sure it doesn't read uninitialized data. Fixes: c6ac37d8 ("netfilter: nf_log: fix error on write NONE to [...]") Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 1b6fe979 ] When booting from MMC/SD in rw mode on DA850 EVM, the system crashes because the write protect pin should be active high and not active low. This patch fixes the polarity of the WP pin. Fixes: bdf0e836 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins") Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 98310707 ] Currently we can hit following assert when running numa bench: $ perf bench numa mem -p 3 -t 1 -P 512 -s 100 -zZ0cm --thp 1 perf: bench/numa.c:1577: __bench_numa: Assertion `!(!(((wait_stat) & 0x7f) == 0))' failed. The assertion is correct, because we hit the SIGFPE in following line: Thread 2.2 "thread 0/0" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7fffd28c6700 (LWP 11750)] 0x000.. in worker_thread (__tdata=0x7.. ) at bench/numa.c:1257 1257 td->speed_gbs = bytes_done / (td->runtime_ns / NSEC_PER_SEC) / 1e9; We don't check if the runtime is actually bigger than 1 second, and thus this might end up with zero division within FPU. Adding the check to prevent this. Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180620094036.17278-1-jolsa@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Yonghong Song authored
[ Upstream commit c6555c14 ] Arnaldo reported the perf build failure with latest llvm/clang compiler (7.0). $ make LIBCLANGLLVM=1 -C tools/perf/ <SNIP> CC /tmp/tmp.t53Qo38zci/tests/kmod-path.o util/c++/clang.cpp: In function ‘std::unique_ptr<llvm::SmallVectorImpl<char> > perf::getBPFObjectFromModule(llvm::Module*)’: util/c++/clang.cpp:150:43: error: no matching function for call to ‘llvm::TargetMachine::addPassesToEmitFile(llvm::legacy::PassManager&, llvm::raw_svector_ostream&, llvm::TargetMachine::CodeGenFileType)’ TargetMachine::CGFT_ObjectFile)) { ^ In file included from util/c++/clang.cpp:25:0: /usr/local/include/llvm/Target/TargetMachine.h:254:16: note: candidate: virtual bool llvm::TargetMachine::addPassesToEmitFile( llvm::legacy::PassManagerBase&, llvm::raw_pwrite_stream&, llvm::raw_pwrite_stream*, llvm::TargetMachine::CodeGenFileType, bool, llvm::MachineModuleInfo*) virtual bool addPassesToEmitFile(PassManagerBase &, raw_pwrite_stream &, ^~~~~~~~~~~~~~~~~~~ /usr/local/include/llvm/Target/TargetMachine.h:254:16: note: candidate expects 6 arguments, 3 provided mv: cannot stat '/tmp/tmp.t53Qo38zci/util/c++/.clang.o.tmp': No such file or directory make[7]: *** [/home/acme/git/perf/tools/build/Makefile.build:101: /tmp/tmp.t53Qo38zci/util/c++/clang.o] Error 1 make[6]: *** [/home/acme/git/perf/tools/build/Makefile.build:139: c++] Error 2 make[5]: *** [/home/acme/git/perf/tools/build/Makefile.build:139: util] Error 2 make[5]: *** Waiting for unfinished jobs.... CC /tmp/tmp.t53Qo38zci/tests/thread-map.o The function addPassesToEmitFile signature changed in llvm 7.0 and such a change caused the failure. This patch fixed the issue with using proper function signatures under different compiler versions. Reported-by:
Yonghong Song <yhs@fb.com> Tested-by:
-
Sandipan Das authored
[ Upstream commit 143c99f6 ] For some cases, the callchain provided by the kernel may be empty. So, the callchain ip filtering code will cause a crash if we do not check whether the struct ip_callchain pointer is NULL before accessing any members. This can be observed on a powerpc64le system running Fedora 27 as shown below. # perf record -b -e cycles:u ls Before: # perf report --branch-history perf: Segmentation fault -------- backtrace -------- perf[0x1027615c] linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x7fff856304d8] perf(arch_skip_callchain_idx+0x44)[0x10257c58] perf[0x1017f2e4] perf(thread__resolve_callchain+0x124)[0x1017ff5c] perf(sample__resolve_callchain+0xf0)[0x10172788] ... After: # perf report --branch-history Samples: 25 of event 'cycles:u', Event count (approx.): 2306870 Overhead Source:Line Symbol Shared Object + 11.60% _init+35736 [.] _init ls + 9.84% strcoll_l.c:137 [.] __strcoll_l libc-2.26.so + 9.16% memcpy.S:175 [.] __memcpy_power7 libc-2.26.so + 9.01% gconv_charset.h:54 [.] _nl_find_locale libc-2.26.so + 8.87% dl-addr.c:52 [.] _dl_addr libc-2.26.so + 8.83% _init+236 [.] _init ls ... Reported-by:
Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by:
Sandipan Das <sandipan@linux.ibm.com> Acked-by:
-
Thomas Richter authored
[ Upstream commit b930e62e ] On s390 this test case fails because the socket identifiction numbers assigned to the CPU are higher than the CPU identification numbers. F/ix this by adding the platform architecture into the perf data header flag information. This helps identifiing the test platform and handles s390 specifics in process_cpu_topology(). Before: [root@p23lp27 perf]# perf test -vvvvv -F 39 39: Session topology : --- start --- templ file: /tmp/perf-test-iUv755 socket_id number is too big.You may need to upgrade the perf tool. ---- end ---- Session topology: Skip [root@p23lp27 perf]# After: [root@p23lp27 perf]# perf test -vvvvv -F 39 39: Session topology : --- start --- templ file: /tmp/perf-test-8X8VTs CPU 0, core 0, socket 6 CPU 1, core 1, socket 3 ---- end ---- Session topology: Ok [root@p23lp27 perf]# Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Reviewed-by:
Hendrik Brueckner <brueckner@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Fixes: c84974ed ("perf test: Add entry to test cpu topology") Link: http://lkml.kernel.org/r/20180611073153.15592-2-tmricht@linux.ibm.comSigned-off-by:
-
Thomas Richter authored
[ Upstream commit 01766229 ] On s390 the socket identifier assigned to a CPU identifier is random and (depending on the configuration of the LPAR) may be higher than the CPU identifier. This is currently not supported. Fix this by allowing arbitrary socket identifiers being assigned to CPU id. Output before: [root@p23lp27 perf]# ./perf report --header -I -v ... socket_id number is too big.You may need to upgrade the perf tool. Error: The perf.data file has no samples! # ======== # captured on : Tue May 29 09:29:57 2018 # header version : 1 ... # Core ID and Socket ID information is not available ... [root@p23lp27 perf]# Output after: [root@p23lp27 perf]# ./perf report --header -I -v ... Error: The perf.data file has no samples! # ======== # captured on : Tue May 29 09:29:57 2018 # header version : 1 ... # CPU 0: Core ID 0, Socket ID 6 # CPU 1: Core ID 1, Socket ID 3 # CPU 2: Core ID -1, Socket ID -1 ... [root@p23lp27 perf]# Signed-off-by:
-
Dirk Gouders authored
[ Upstream commit b2d00d7c ] The line numers for if-entries in the menu tree are off by one or more lines which is confusing when debugging for correctness of unrelated changes. According to the git log, commit a02f0570 (kconfig: improve error handling in the parser) was the last one that changed that part of the parser and replaced "if_entry: T_IF expr T_EOL" by "if_entry: T_IF expr nl" but the commit message does not state why this has been done. When reverting that part of the commit, only the line numers are corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise the menu tree remains unchanged (checked with zconfdump() enabled in conf.c). An example for the corrected line numbers: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:4:if drivers/soc/tegra/Kconfig:6:if changes to: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:1:if drivers/soc/tegra/Kconfig:4:if Signed-off-by:
Dirk Gouders <dirk@gouders.net> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 9578bcd0 ] The tcpm_set_state() function take msecs not jiffies. Fixes: f0690a25 ("staging: typec: USB Type-C Port Manager (tcpm)") Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit ecc443c0 ] pn533_recv_response() is an urb completion handler, so it must use GFP_ATOMIC. pn533_usb_send_frame() OTOH runs from a regular sleeping context, so the pn533_submit_urb_for_response() there (and only there) can use the regular GFP_KERNEL flags. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514134 Fixes: 9815c7cf ("NFC: pn533: Separate physical layer from ...") Cc: Michael Thalmeier <michael.thalmeier@hale.at> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Ajay Gupta authored
[ Upstream commit 305886ca ] Some controllers take almost 55ms to complete controller restore state (CRS). There is no timeout limit mentioned in xhci specification so fixing the issue by increasing the timeout limit to 100ms [reformat code comment -Mathias] Signed-off-by:
Ajay Gupta <ajaykuee@gmail.com> Signed-off-by:
Nagaraj Annaiah <naga.annaiah@gmail.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Dongjiu Geng authored
[ Upstream commit 36eb9350 ] Initialize the 'err' variate to remove the build warning, the warning is shown as below: drivers/usb/host/xhci-tegra.c: In function 'tegra_xusb_mbox_thread': drivers/usb/host/xhci-tegra.c:552:6: warning: 'err' may be used uninitialized in this function [-Wuninitialized] drivers/usb/host/xhci-tegra.c:482:6: note: 'err' was declared here Fixes: e84fce0f ("usb: xhci: Add NVIDIA Tegra XUSB controller driver") Signed-off-by:
Dongjiu Geng <gengdongjiu@huawei.com> Acked-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit c9a4c638 ] The kernel may spew a WARNING with UBSAN undefined behavior at handling ALSA sequencer ioctl SNDRV_SEQ_IOCTL_QUERY_NEXT_CLIENT: UBSAN: Undefined behaviour in sound/core/seq/seq_clientmgr.c:2007:14 signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x122/0x1c8 lib/dump_stack.c:113 ubsan_epilogue+0x12/0x86 lib/ubsan.c:159 handle_overflow+0x1c2/0x21f lib/ubsan.c:190 __ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198 snd_seq_ioctl_query_next_client+0x1ac/0x1d0 sound/core/seq/seq_clientmgr.c:2007 snd_seq_ioctl+0x264/0x3d0 sound/core/seq/seq_clientmgr.c:2144 .... It happens only when INT_MAX is passed there, as we're incrementing it unconditionally. So the fix is trivial, check the value with INT_MAX. Although the bug itself is fairly harmless, it's better to fix it so that fuzzers won't hit this again later. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200211Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Daniel Mack authored
[ Upstream commit 49a6ec5b ] The touchscreen driver no longer configures the device as wakeup source by default. A "wakeup-source" property is needed. Signed-off-by:
Daniel Mack <daniel@zonque.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Michael Trimarchi authored
[ Upstream commit 373c83a8 ] Using built-in in kernel image without a firmware in filesystem or in the kernel image can lead to a kernel NULL pointer deference. Watchdog need to be stopped in brcmf_sdio_remove The system is going down NOW! [ 1348.110759] Unable to handle kernel NULL pointer dereference at virtual address 000002f8 Sent SIGTERM to all processes [ 1348.121412] Mem abort info: [ 1348.126962] ESR = 0x96000004 [ 1348.130023] Exception class = DABT (current EL), IL = 32 bits [ 1348.135948] SET = 0, FnV = 0 [ 1348.138997] EA = 0, S1PTW = 0 [ 1348.142154] Data abort info: [ 1348.145045] ISV = 0, ISS = 0x00000004 [ 1348.148884] CM = 0, WnR = 0 [ 1348.151861] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____) [ 1348.158475] [00000000000002f8] pgd=0000000000000000 [ 1348.163364] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 1348.168927] Modules linked in: ipv6 [ 1348.172421] CPU: 3 PID: 1421 Comm: brcmf_wdog/mmc0 Not tainted 4.17.0-rc5-next-20180517 #18 [ 1348.180757] Hardware name: Amarula A64-Relic (DT) [ 1348.185455] pstate: 60000005 (nZCv daif -PAN -UAO) [ 1348.190251] pc : brcmf_sdiod_freezer_count+0x0/0x20 [ 1348.195124] lr : brcmf_sdio_watchdog_thread+0x64/0x290 [ 1348.200253] sp : ffff00000b85be30 [ 1348.203561] x29: ffff00000b85be30 x28: 0000000000000000 [ 1348.208868] x27: ffff00000b6cb918 x26: ffff80003b990638 [ 1348.214176] x25: ffff0000087b1a20 x24: ffff80003b94f800 [ 1348.219483] x23: ffff000008e620c8 x22: ffff000008f0b660 [ 1348.224790] x21: ffff000008c6a858 x20: 00000000fffffe00 [ 1348.230097] x19: ffff80003b94f800 x18: 0000000000000001 [ 1348.235404] x17: 0000ffffab2e8a74 x16: ffff0000080d7de8 [ 1348.240711] x15: 0000000000000000 x14: 0000000000000400 [ 1348.246018] x13: 0000000000000400 x12: 0000000000000001 [ 1348.251324] x11: 00000000000002c4 x10: 0000000000000a10 [ 1348.256631] x9 : ffff00000b85bc40 x8 : ffff80003be11870 [ 1348.261937] x7 : ffff80003dfc7308 x6 : 000000078ff08b55 [ 1348.267243] x5 : 00000139e1058400 x4 : 0000000000000000 [ 1348.272550] x3 : dead000000000100 x2 : 958f2788d6618100 [ 1348.277856] x1 : 00000000fffffe00 x0 : 0000000000000000 Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Tested-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Tomasz Duszynski authored
[ Upstream commit 13399ff2 ] According to IIO ABI relative humidity reading should be returned in milli percent. This patch addresses that by applying proper scaling and returning integer instead of fractional format type specifier. Note that the fixes tag is before the driver was heavily refactored to introduce spi support, so the patch won't apply that far back. Signed-off-by:
Tomasz Duszynski <tduszyns@gmail.com> Fixes: 14beaa8f ("iio: pressure: bmp280: add humidity support") Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Ganesh Goudar authored
[ Upstream commit 5ce36338 ] When we are disabling DCB, store "0" in txq->dcb_prio since that's used for future TX Work Request "OVLAN_IDX" values. Setting non zero priority upon disabling DCB would halt the traffic. Reported-by:
AMG Zollner Robert <robert@cloudmedia.eu> CC: David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
Casey Leedom <leedom@chelsio.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Linus Lüssing authored
[ Upstream commit a44ebeff ] When a (broken) node wrongly sends multicast TT entries with a ROAM flag then this causes any receiving node to drop all entries for the same multicast MAC address announced by other nodes, leading to packet loss. Fix this DoS vector by only storing TT sync flags. For multicast TT non-sync'ing flag bits like ROAM are unused so far anyway. Fixes: 1d8ab8d3 ("batman-adv: Modified forwarding behaviour for multicast packets") Reported-by:
Leonardo Mörlein <me@irrelefant.net> Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Linus Lüssing authored
[ Upstream commit 4a519b83 ] Since commit 54e22f26 ("batman-adv: fix TT sync flag inconsistencies") TT sync flags and TT non-sync'd flags are supposed to be stored separately. The previous patch missed to apply this separation on a TT entry with only a single TT orig entry. This is a minor fix because with only a single TT orig entry the DDoS issue the former patch solves does not apply. Fixes: 54e22f26 ("batman-adv: fix TT sync flag inconsistencies") Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
