- 22 Mar, 2018 40 commits
-
-
Yuyang Du authored
[ Upstream commit 9f20dfb4 ] This fixes the commit: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support"). In the case of ClearPortFeature and USB_PORT_FEAT_POWER, simply clear the right bit regardless of what the wValue is. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Yuyang Du <yuyang.du@intel.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
John Stultz authored
[ Upstream commit dad3f793 ] I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not being clear. Ends up if we don't disconnect the gadget state, the fifo-map doesn't get cleared properly, which causes WARN_ON messages and also results in the device not properly being setup as a gadget every other time the OTG port is connected. So this patch adds a call to dwc2_hsotg_disconnect() in the reset path so the state is properly cleared. With it, the gadget interface initializes properly on every plug in. Cc: Wei Xu <xuwei5@hisilicon.com> Cc: Guodong Xu <guodong.xu@linaro.org> Cc: Amit Pundir <amit.pundir@linaro.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: John Youn <johnyoun@synopsys.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Chen Yu <chenyu56@huawei.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Acked-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
NeilBrown authored
[ Upstream commit 7471fb77 ] When recoverying a single missing/failed device in a RAID6, those stripes where the Q block is on the missing device are handled a bit differently. In these cases it is easy to check that the P block is correct, so we do. This results in the P block be destroy. Consequently the P block needs to be read a second time in order to compute Q. This causes lots of seeks and hurts performance. It shouldn't be necessary to re-read P as it can be computed from the DATA. But we only compute blocks on missing devices, since c337869d ("md: do not compute parity unless it is on a failed drive"). So relax the change made in that commit to allow computing of the P block in a RAID6 which it is the only missing that block. This makes RAID6 recovery run much faster as the disk just "before" the recovering device is no longer seeking back-and-forth. Reported-by-tested-by:
Brad Campbell <lists2009@fnarfbargle.com> Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Vincent Stehlé authored
[ Upstream commit 0c08aaf8 ] ISL9305_MAX_REGULATOR is the last index used to access the init_data[] array, so we need to add one to this last index to obtain the necessary array size. This fixes the following smatch error: drivers/regulator/isl9305.c:160 isl9305_i2c_probe() error: buffer overflow 'pdata->init_data' 3 <= 3 Fixes: dec38b5c ("regulator: isl9305: Add Intersil ISL9305/H driver") Signed-off-by:
Vincent Stehlé <vincent.stehle@laposte.net> Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Aleksandar Markovic authored
[ Upstream commit 411dac79 ] Add missing clearing of BLTZALL and BGEZALL emulation counters in function mipsr2_stats_clear_show(). Previously, it was not possible to reset BLTZALL and BGEZALL emulation counters - their value remained the same even after explicit request via debugfs. As far as other related counters are concerned, they all seem to be properly cleared. This change affects debugfs operation only, core R2 emulation functionality is not affected. Signed-off-by:
Aleksandar Markovic <aleksandar.markovic@imgtec.com> Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Cc: james.hogan@imgtec.com Cc: leonid.yegoshin@imgtec.com Cc: douglas.leung@imgtec.com Cc: petar.jovanovic@imgtec.com Cc: miodrag.dinic@imgtec.com Cc: goran.ferenc@imgtec.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15517/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Leonid Yegoshin authored
[ Upstream commit 5bba7aa4 ] Fix the problem of inaccurate identification of instructions BLEZL and BGTZL in R2 emulation code by making sure all necessary encoding specifications are met. Previously, certain R6 instructions could be identified as BLEZL or BGTZL. R2 emulation routine didn't take into account that both BLEZL and BGTZL instructions require their rt field (bits 20 to 16 of instruction encoding) to be 0, and that, at same time, if the value in that field is not 0, the encoding may represent a legitimate MIPS R6 instruction. This means that a problem could occur after emulation optimization, when emulation routine tried to pipeline emulation, picked up a next candidate, and subsequently misrecognized an R6 instruction as BLEZL or BGTZL. It should be said that for single pass strategy, the problem does not happen because CPU doesn't trap on branch-compacts which share opcode space with BLEZL/BGTZL (but have rt field != 0, of course). Signed-off-by:
Leonid Yegoshin <leonid.yegoshin@imgtec.com> Signed-off-by:
Miodrag Dinic <miodrag.dinic@imgtech.com> Signed-off-by:
Aleksandar Markovic <aleksandar.markovic@imgtech.com> Reported-by:
Douglas Leung <douglas.leung@imgtec.com> Reviewed-by:
-
David Daney authored
[ Upstream commit a81507c7 ] o Socket data is unsigned, so use unsigned accessors instructions. o Fix path result pointer generation arithmetic. o Fix half-word byte swapping code for unsigned semantics. Signed-off-by:
David Daney <david.daney@cavium.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Steven J. Hill <steven.hill@cavium.com> Cc: linux-mips@linux-mips.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15747/Signed-off-by:
-
David Daney authored
[ Upstream commit 1ef0910c ] If bpf_needs_clear_a() returns true, only actually clear it if it is ever used. If it is not used, we don't save and restore it, so the clearing has the nasty side effect of clobbering caller state. Also, don't emit stack pointer adjustment instructions if the adjustment amount is zero. Signed-off-by:
-
Mike Leach authored
[ Upstream commit eeedc542 ] Corrected to get the port numbering to allow programmable replicator driver to operate correctly. By convention, CoreSight devices number ports, not endpoints in the .dts files:- port { reg<N> endpoint { } } Existing code read endpoint number - always 0x0, rather than the correct port number. Signed-off-by:
Mike Leach <mike.leach@linaro.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Christopher James Halse Rogers authored
[ Upstream commit 1769152a ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Christopher James Halse Rogers <christopher.halse.rogers@canonical.com> CC: amd-gfx@lists.freedesktop.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christopher James Halse Rogers authored
[ Upstream commit a294043b ] Any use of the framebuffer will migrate it to VRAM, which is not sensible for an imported dma-buf. v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg. Reviewed-by:
-
Liam Beguin authored
[ Upstream commit 9a1c779e ] This patch forces the frambuffer size to be aligned on kernel pages. During the board startup, the splash screed did appear; the "ts_test" program or our application were not able to start. The following error message was reported: error: failed to map framebuffer device to memory. LinuxFB: driver cannot connect The issue was discovered, on the LPC32xx platform, during the migration of the LCD definition from the board file to the device tree. Signed-off-by:
Liam Beguin <lbeguin@tycoint.com> Signed-off-by:
Sylvain Lemieux <slemieux@tycoint.com> Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Russell King <linux@armlinux.org.uk> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Nate Watterson authored
[ Upstream commit 5016bdb7 ] Normally, calling alloc_iova() using an iova_domain with insufficient pfns remaining between start_pfn and dma_limit will fail and return a NULL pointer. Unexpectedly, if such a "full" iova_domain contains an iova with pfn_lo == 0, the alloc_iova() call will instead succeed and return an iova containing invalid pfns. This is caused by an underflow bug in __alloc_and_insert_iova_range() that occurs after walking the "full" iova tree when the search ends at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just below that (-1). This (now huge) limit_pfn gives the impression that a vast amount of space is available between it and start_pfn and thus a new iova is allocated with the invalid pfn_hi value, 0xFFF.... . To rememdy this, a check is introduced to ensure that adjustments to limit_pfn will not underflow. This issue has been observed in the wild, and is easily reproduced with the following sample code. struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL); struct iova *rsvd_iova, *good_iova, *bad_iova; unsigned long limit_pfn = 3; unsigned long start_pfn = 1; unsigned long va_size = 2; init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn); rsvd_iova = reserve_iova(iovad, 0, 0); good_iova = alloc_iova(iovad, va_size, limit_pfn, true); bad_iova = alloc_iova(iovad, va_size, limit_pfn, true); Prior to the patch, this yielded: *rsvd_iova == {0, 0} /* Expected */ *good_iova == {2, 3} /* Expected */ *bad_iova == {-2, -1} /* Oh no... */ After the patch, bad_iova is NULL as expected since inadequate space remains between limit_pfn and start_pfn after allocating good_iova. Signed-off-by:
Nate Watterson <nwatters@codeaurora.org> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
John Johansen authored
[ Upstream commit 622f6e32 ] The path_max parameter determines the max size of buffers allocated but it should not be setable at run time. If can be used to cause an oops root@ubuntu:~# echo 16777216 > /sys/module/apparmor/parameters/path_max root@ubuntu:~# cat /sys/module/apparmor/parameters/path_max Killed [ 122.141911] BUG: unable to handle kernel paging request at ffff880080945fff [ 122.143497] IP: [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.144742] PGD 220c067 PUD 0 [ 122.145453] Oops: 0002 [#1] SMP [ 122.146204] Modules linked in: vmw_vsock_vmci_transport vsock ppdev vmw_balloon snd_ens1371 btusb snd_ac97_codec gameport snd_rawmidi btrtl snd_seq_device ac97_bus btbcm btintel snd_pcm input_leds bluetooth snd_timer snd joydev soundcore serio_raw coretemp shpchp nfit parport_pc i2c_piix4 8250_fintek vmw_vmci parport mac_hid ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd vmwgfx psmouse mptspi ttm mptscsih drm_kms_helper mptbase syscopyarea scsi_transport_spi sysfillrect [ 122.163365] ahci sysimgblt e1000 fb_sys_fops libahci drm pata_acpi fjes [ 122.164747] CPU: 3 PID: 1501 Comm: bash Not tainted 4.4.0-59-generic #80-Ubuntu [ 122.166250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 [ 122.168611] task: ffff88003496aa00 ti: ffff880076474000 task.ti: ffff880076474000 [ 122.170018] RIP: 0010:[<ffffffff81228844>] [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.171525] RSP: 0018:ffff880076477b90 EFLAGS: 00010206 [ 122.172462] RAX: ffff880080945fff RBX: 0000000000000000 RCX: 0000000001000000 [ 122.173709] RDX: 0000000000ffffff RSI: ffff880080946000 RDI: ffff8800348a1010 [ 122.174978] RBP: ffff880076477bb8 R08: ffff880076477c80 R09: 0000000000000000 [ 122.176227] R10: 00007ffffffff000 R11: ffff88007f946000 R12: ffff88007f946000 [ 122.177496] R13: ffff880076477c80 R14: ffff8800348a1010 R15: ffff8800348a2400 [ 122.178745] FS: 00007fd459eb4700(0000) GS:ffff88007b6c0000(0000) knlGS:0000000000000000 [ 122.180176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 122.181186] CR2: ffff880080945fff CR3: 0000000073422000 CR4: 00000000001406e0 [ 122.182469] Stack: [ 122.182843] 00ffffff00000001 ffff880080946000 0000000000000000 0000000000000000 [ 122.184409] 00000000570f789c ffff880076477c30 ffffffff81385671 ffff88007a2e7a58 [ 122.185810] 0000000000000000 ffff880076477c88 01000000008a1000 0000000000000000 [ 122.187231] Call Trace: [ 122.187680] [<ffffffff81385671>] aa_path_name+0x81/0x370 [ 122.188637] [<ffffffff813875dd>] profile_transition+0xbd/0xb80 [ 122.190181] [<ffffffff811af9bc>] ? zone_statistics+0x7c/0xa0 [ 122.191674] [<ffffffff81389b20>] apparmor_bprm_set_creds+0x9b0/0xac0 [ 122.193288] [<ffffffff812e1971>] ? ext4_xattr_get+0x81/0x220 [ 122.194793] [<ffffffff812e800c>] ? ext4_xattr_security_get+0x1c/0x30 [ 122.196392] [<ffffffff813449b9>] ? get_vfs_caps_from_disk+0x69/0x110 [ 122.198004] [<ffffffff81232d4f>] ? mnt_may_suid+0x3f/0x50 [ 122.199737] [<ffffffff81344b03>] ? cap_bprm_set_creds+0xa3/0x600 [ 122.201377] [<ffffffff81346e53>] security_bprm_set_creds+0x33/0x50 [ 122.203024] [<ffffffff81214ce5>] prepare_binprm+0x85/0x190 [ 122.204515] [<ffffffff81216545>] do_execveat_common.isra.33+0x485/0x710 [ 122.206200] [<ffffffff81216a6a>] SyS_execve+0x3a/0x50 [ 122.207615] [<ffffffff81838795>] stub_execve+0x5/0x5 [ 122.208978] [<ffffffff818384f2>] ? entry_SYSCALL_64_fastpath+0x16/0x71 [ 122.210615] Code: f8 31 c0 48 63 c2 83 ea 01 48 c7 45 e8 00 00 00 00 48 01 c6 85 d2 48 c7 45 f0 00 00 00 00 48 89 75 e0 89 55 dc 78 0c 48 8d 46 ff <c6> 46 ff 00 48 89 45 e0 48 8d 55 e0 48 8d 4d dc 48 8d 75 e8 e8 [ 122.217320] RIP [<ffffffff81228844>] d_absolute_path+0x44/0xa0 [ 122.218860] RSP <ffff880076477b90> [ 122.219919] CR2: ffff880080945fff [ 122.220936] ---[ end trace 506cdbd85eb6c55e ]--- Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
[ Upstream commit 75106523 ] The commit 08024885 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Fixes: 08024885 ("ses: Add power_status to SES device slot") Reviewed-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Phil Turnbull authored
[ Upstream commit 540fca35 ] FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'. Fixes: 5cb8db4a ("fm10k: Add support for VF") Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Takashi Sakamoto authored
[ Upstream commit 8820a4cf ] At a commit 9dc5d31c ("ALSA: firewire-digi00x: handle MIDI messages in isochronous packets"), a functionality to handle MIDI messages on isochronous packet was supported. But this includes some of my misunderstanding. This commit is to fix them. For digi00x series, first data channel of data blocks in rx/tx packet includes MIDI messages. The data channel has 0x80 in 8 bit of its MSB, however it's against IEC 61883-6. Unique data format is applied: - Upper 4 bits of LSB represent port number. - 0x0: port 1. - 0x2: port 2. - 0xe: console port. - Lower 4 bits of LSB represent the number of included MIDI message bytes; 0x0/0x1/0x2. - Two bytes of middle of this data channel have MIDI bytes. Especially, MIDI messages from/to console surface are also transferred by isochronous packets, as well as physical MIDI ports. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jan Kara authored
[ Upstream commit 71b0576b ] Currently canceling of delayed work that flushes old data using cancel_old_flush() does not prevent work from being requeued. Thus in theory new work can be queued after cancel_old_flush() from reiserfs_freeze() has run. This will become larger problem once flush_old_commits() can requeue the work itself. Fix the problem by recording in sbi->work_queue that flushing work is canceled and should not be requeued. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit ebf06af5 ] The X2 crystal oscillator on the Koelsch development board provides a 74.25 MHz clock, not a 148.5 MHz clock. Fixes: cd21cb46 ("ARM: shmobile: koelsch: Add DU external pixel clocks to DT") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Andrew Lunn authored
[ Upstream commit d39004ab ] Breaking the include loop netdevice.h, dsa.h, devlink.h broke this driver, it depends on includes brought in by these headers. Adding linux/of.h fixes it. Fixes: ed0e39e97d34 ("net: break include loop netdevice.h, dsa.h, devlink.h") Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit a7a9dcd8 ] Early on in do_page_fault() we call store_updates_sp(), regardless of the type of exception. For an instruction miss this doesn't make sense, because we only use this information to detect if a data miss is the result of a stack expansion instruction or not. Worse still, it results in a data miss within every userspace instruction miss handler, because we try and load the very instruction we are about to install a pte for! A simple exec microbenchmark runs 6% faster on POWER8 with this fix: #include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(int argc, char *argv[]) { unsigned long left = atol(argv[1]); char leftstr[16]; if (left-- == 0) return 0; sprintf(leftstr, "%ld", left); execlp(argv[0], argv[0], leftstr, NULL); perror("exec failed\n"); return 0; } Pass the number of iterations on the command line (eg 10000) and time how long it takes to execute. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 16fe68dc ] The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: ee914152 ("ARM: shmobile: r8a7791: add MSTP10 support on DTSI") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit d13d4e06 ] The SSI-ALL gate clock is located in between the P clock and the individual SSI[0-9] clocks, hence the former should be listed as their parent. Fixes: bcde3722 ("ARM: shmobile: r8a7790: add MSTP10 support on DTSI") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ca42fb9e ] The nci_spi_send() function calls kfree_skb(skb) on both error and success so this extra kfree_skb() is a double free. Fixes: caf6e49b ("NFC: nfcmrvl: add spi driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Tobias Klauser authored
[ Upstream commit d916d923 ] Including linux/unaligned/access_ok.h causes the allmodconfig build on ia64 (and maybe others) to fail with the following warnings: include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16' include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32' include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64' include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16' include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32' include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64' include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32' include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64' Fix these by including asm/unaligned.h instead and leave it up to the architecture to decide how to implement unaligned accesses. Fixes: 3194c687 ("NFC: nfcmrvl: add firmware download support") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Link: https://lkml.org/lkml/2016/10/22/247 Cc: Vincent Cuissard <cuissard@marvell.com> Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Felix Manlunas authored
[ Upstream commit d6acfeb1 ] vxlan dev currently ignores lowerdev's gso_max_size, which adversely affects TSO performance of liquidio if it's the lowerdev. Egress TCP packets' skb->len often exceed liquidio's advertised gso_max_size. This may happen on other NIC drivers. Fix it by assigning lowerdev's gso_max_size to that of vxlan dev. Might as well do likewise for gso_max_segs. Single flow TSO throughput of liquidio as lowerdev (using iperf3): Before the patch: 139 Mbps After the patch : 8.68 Gbps Percent increase: 6,144 % Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
Satanand Burla <satananda.burla@cavium.com> Signed-off-by:
-
Sinclair Yeh authored
[ Upstream commit aa74f068 ] 1. When unsetting a mode, num_connector should be set to zero 2. The pixel_format field needs to be initialized as newer DRM internal functions checks this field 3. Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can change current mode Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Samuel Thibault authored
[ Upstream commit 2ed2b862 ] commit bbeddf52 ("printk: move braille console support into separate braille.[ch] files") introduced _braille_console_setup() to outline the braille initialization code. There was however some confusion over the value it was supposed to return. commit 2cfe6c4a ("printk: Fix return of braille_register_console()") tried to fix it but failed to. This fixes and documents the returned value according to the use in printk.c: non-zero return means a parsing error, and thus this console configuration should be ignored. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Aleksey Makarov <aleksey.makarov@linaro.org> Cc: Joe Perches <joe@perches.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Steven Rostedt <rostedt@goodmis.org> Acked-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 142c6594 ] Some device drivers reset their stats at down/up events, possibly fooling bonding stats, since they operate with relative deltas. It is nearly not possible to fix drivers, since some of them compute the tx/rx counters based on per rx/tx queue stats, and the queues can be reconfigured (ethtool -L) between the down/up sequence. Lets avoid accumulating 'negative' values that render bonding stats useless. It is better to lose small deltas, assuming the bonding stats are fetched at a reasonable frequency. Fixes: 5f0c5f73 ("bonding: make global bonding stats more reliable") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jaegeuk Kim authored
[ Upstream commit c13ff37e ] - has_not_enough_free_secs node_secs: 0 dent_secs: 0 freed:0 free_segments:103 reserved:104 - f2fs_gc - get_victim_by_default alloc_mode 0, gc_mode 1, max_search 2672, offset 4654, ofs_unit 1 - do_garbage_collect start_segno 3976, end_segno 3977 type 0 - is_alive nid 22797, blkaddr 2131882, ofs_in_node 0, version 0x8/0x0 - gc_data_segment 766, segno 3976, block 512/426 not alive So, this patch fixes subtle corrupted case where node version does not match to summary version which results in infinite loop by gc. Reported-by:
Yunlei He <heyunlei@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Shaohua Li authored
[ Upstream commit 06cceedc ] cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger current downgrade/upgrade logic. To fix this issue, we could either set up a timer to wakeup the cgroup if other cgroups are idle or make sure this cgroup doesn't sleep too long. Setting up a timer means we must change the timer very frequently. This patch chooses the latter. Making cgroup sleep time not too big wouldn't change cgroup bps/iops, but could make it wakeup more frequently, which isn't a big issue because throtl_slice * 8 is already quite big. Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Kirill A. Shutemov authored
[ Upstream commit 591a3d7c ] 0day testing by Fengguang Wu triggered this crash while running Trinity: kernel BUG at include/linux/pagemap.h:151! ... CPU: 0 PID: 458 Comm: trinity-c0 Not tainted 4.11.0-rc2-00251-g2947ba05 #1 ... Call Trace: __get_user_pages_fast() get_user_pages_fast() get_futex_key() futex_requeue() do_futex() SyS_futex() do_syscall_64() entry_SYSCALL64_slow_path() It' VM_BUG_ON() due to false-negative in_atomic(). We call page_cache_get_speculative() with disabled local interrupts. It should be atomic enough. So let's check for disabled interrupts in the VM_BUG_ON() condition too, to resolve this. ( This got triggered by the conversion of the x86 GUP code to the generic GUP code. ) Reported-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: LKP <lkp@01.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20170324114709.pcytvyb3d6ajux33@black.fi.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Shikhar Dogra authored
[ Upstream commit 6faecba0 ] Seems like coefficient values for m, b and R under power have been put in the wrong order. Rearranging them properly to get correct values of coefficients for power. For specs, please refer to table 7 (page 35) on http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.pdf Fixes: 904b296f ("hwmon: (adm1275) Introduce configuration data structure for coeffcients") Signed-off-by:
Shikhar Dogra <shidogra@cisco.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jiada Wang authored
[ Upstream commit 7f3ff14b ] sdma_disable_channel() cannot ensure dma is stopped to access module's FIFOs. There is chance SDMA core is running and accessing BD when disable of corresponding channel, this may cause sometimes even after call of .sdma_disable_channel(), SDMA core still be running and accessing module's FIFOs. According to NXP R&D team a delay of one BD SDMA cost time (maximum is 1ms) should be added after disable of the channel bit, to ensure SDMA core has really been stopped after SDMA clients call .device_terminate_all. This patch introduces adds a new function sdma_disable_channel_with_delay() which simply adds 1ms delay after call sdma_disable_channel(), and set it as .device_terminate_all. Signed-off-by:
Jiada Wang <jiada_wang@mentor.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Gao Feng authored
[ Upstream commit c4836742 ] Because sysctl_tcp_adv_win_scale could be changed any time, so there is one race in tcp_win_from_space. For example, 1.sysctl_tcp_adv_win_scale<=0 (sysctl_tcp_adv_win_scale is negative now) 2.space>>(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now) As a result, tcp_win_from_space returns 0. It is unexpected. Certainly if the compiler put the sysctl_tcp_adv_win_scale into one register firstly, then use the register directly, it would be ok. But we could not depend on the compiler behavior. Signed-off-by:
Gao Feng <fgao@ikuai8.com> Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit 81261359 ] When running the spi-loopback-test with slower clock rate like 10 KHz, the test for 251 bytes transfer was failed. This failure triggered an spi-omap2-mcspi's error message "DMA RX last word empty". This message means that PIO for reading the remaining bytes due to the DMA transfer length reduction is failed. This problem can be fixed by polling OMAP2_MCSPI_CHSTAT_RXS bit in channel status register to wait until the receive buffer register is filled. Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Kuninori Morimoto authored
[ Upstream commit 6b8530cc ] R-Car Datasheet is indicating "SSICR.CKDV = 000 is invalid when SSIWSR.WS_MODE = 1 or SSIWSR.CONT = 1". Current driver will set CONT, thus, we shouldn't use CKDV = 000. This patch fixup it. Reported-by:
Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by:
-
Davide Caratti authored
[ Upstream commit add641e7 ] after act_csum computes the checksum on skbs carrying GSO TCP/UDP packets, subsequent segmentation fails because skb_needs_check(skb, true) returns true. Because of that, skb_warn_bad_offload() is invoked and the following message is displayed: WARNING: CPU: 3 PID: 28 at net/core/dev.c:2553 skb_warn_bad_offload+0xf0/0xfd <...> [<ffffffff8171f486>] skb_warn_bad_offload+0xf0/0xfd [<ffffffff8161304c>] __skb_gso_segment+0xec/0x110 [<ffffffff8161340d>] validate_xmit_skb+0x12d/0x2b0 [<ffffffff816135d2>] validate_xmit_skb_list+0x42/0x70 [<ffffffff8163c560>] sch_direct_xmit+0xd0/0x1b0 [<ffffffff8163c760>] __qdisc_run+0x120/0x270 [<ffffffff81613b3d>] __dev_queue_xmit+0x23d/0x690 [<ffffffff81613fa0>] dev_queue_xmit+0x10/0x20 Since GSO is able to compute checksum on individual segments of such skbs, we can simply skip mangling the packet. Signed-off-by:
Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Javier Martinez Canillas authored
[ Upstream commit cf5cd9d4 ] The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. The compatible strings don't have a vendor prefix because that's how it's used currently, and changing this will be a Device Tree ABI break. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Tom Hromatka authored
[ Upstream commit 01070427 ] On systems with a large number of CPUs, running sysrq-<q> can cause watchdog timeouts. There are two slow sections of code in the sysrq-<q> path in timer_list.c. 1. print_active_timers() - This function is called by print_cpu() and contains a slow goto loop. On a machine with hundreds of CPUs, this loop took approximately 100ms for the first CPU in a NUMA node. (Subsequent CPUs in the same node ran much quicker.) The total time to print all of the CPUs is ultimately long enough to trigger the soft lockup watchdog. 2. print_tickdevice() - This function outputs a large amount of textual information. This function also took approximately 100ms per CPU. Since sysrq-<q> is not a performance critical path, there should be no harm in touching the nmi watchdog in both slow sections above. Touching it in just one location was insufficient on systems with hundreds of CPUs as occasional timeouts were still observed during testing. This issue was observed on an Oracle T7 machine with 128 CPUs, but I anticipate it may affect other systems with similarly large numbers of CPUs. Signed-off-by:
Tom Hromatka <tom.hromatka@oracle.com> Reviewed-by:
Rob Gardner <rob.gardner@oracle.com> Signed-off-by:
-
