- 22 Mar, 2018 40 commits
-
-
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:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Laurent Pinchart authored
[ Upstream commit 6dd47cfd ] The driver currently handles vblank events only when updating planes on a CRTC. The atomic update API however allows requesting an event when disabling a CRTC. This currently leads to event objects being leaked in the kernel and to events not being sent out. Fix it. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Petr Mladek authored
[ Upstream commit 257ab443 ] Some console drivers code calls console_conditional_schedule() that looks at @console_may_schedule. The value must be cleared when the drivers are called from console_unlock() with interrupts disabled. But rescheduling is fine when the same code is called, for example, from tty operations where the console semaphore is taken via console_lock(). This is why @console_may_schedule is cleared before calling console drivers. The original value is stored to decide if we could sleep between lines. Now, @console_may_schedule is not cleared when we call console_trylock() and jump back to the "again" goto label. This has become a problem, since the commit 6b97a20d ("printk: set may_schedule for some of console_trylock() callers"). @console_may_schedule might get enabled now. There is also the opposite problem. console_lock() can be called only from preemptive context. It can always enable scheduling in the console code. But console_trylock() is not able to detect it when CONFIG_PREEMPT_COUNT is disabled. Therefore we should use the original @console_may_schedule value after re-acquiring the console semaphore in console_unlock(). This patch solves both problems by moving the "again" goto label. Alternative solution was to clear and restore the value around call_console_drivers(). Then console_conditional_schedule() could be used also inside console_unlock(). But there was a potential race with console_flush_on_panic() as reported by Sergey Senozhatsky. That function should be called only where there is only one CPU and with interrupts disabled. But better be on the safe side because stopping CPUs might fail. Fixes: 6b97a20d ("printk: set may_schedule for some of console_trylock() callers") Link: http://lkml.kernel.org/r/1490372045-22288-1-git-send-email-pmladek@suse.comSuggested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.cz> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit e0aad5b4 ] rt_mutex_waiter::prio is a copy of task_struct::prio which is updated during the PI chain walk, such that the PI chain order isn't messed up by (asynchronous) task state updates. Currently rt_mutex_waiter_less() uses task state for deadline tasks; this is broken, since the task state can, as said above, change asynchronously, causing the RB tree order to change without actual tree update -> FAIL. Fix this by also copying the deadline into the rt_mutex_waiter state and updating it along with its prio field. Ideally we would also force PI chain updates whenever DL tasks update their deadline parameter, but for first approximation this is less broken than it was. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170323150216.403992539@infradead.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Michal Kalderon authored
[ Upstream commit 44531ba4 ] When configuring the HW timers block we should set the number of CIDs up until the last CID that require timers, instead of only those CIDs whose protocol needs timers support. Today, the protocols that require HW timers' support have their CIDs before any other protocol, but that would change in future [when we add iWARP support]. Signed-off-by:
Michal Kalderon <Michal.Kalderon@cavium.com> Signed-off-by:
Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net> 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:
-
lipeng authored
[ Upstream commit 64ec10dc ] This patch fixes below ethtool configuration error: localhost:~ # ethtool -X eth0 hkey XX:XX:XX... Cannot set Rx flow hash configuration: Operation not supported Signed-off-by:
lipeng <lipeng321@huawei.com> Reviewed-by:
Yisen Zhuang <yisen.zhuang@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> 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 1cd90280 ] 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: 072d3265 ("ARM: dts: r8a7793: add MSTP10 clocks to device tree") 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:
-
Chris Brandt authored
[ Upstream commit 91a7c50c ] Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not the 33MHz Peripheral 0 (P0) clock. Fixes: 969244f9 ("ARM: dts: r7s72100: add ethernet clock to device tree") Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
-
Andrey Rusalin authored
[ Upstream commit 068a496c ] Change order of free_irq and dev unregistration. It fixes situation when device already unregistered and an interrupt happens and nobody can handle it. Signed-off-by:
Andrey Rusalin <arusalin@dev.rtsoft.ru> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> 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:
-
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:
-
Aneesh Kumar K.V authored
[ Upstream commit a525108c ] Without this if firmware reports 1MB page size support we will crash trying to use 1MB as hugetlb page size. echo 300 > /sys/kernel/mm/hugepages/hugepages-1024kB/nr_hugepages kernel BUG at ./arch/powerpc/include/asm/hugetlb.h:19! ..... .... [c0000000e2c27b30] c00000000029dae8 .hugetlb_fault+0x638/0xda0 [c0000000e2c27c30] c00000000026fb64 .handle_mm_fault+0x844/0x1d70 [c0000000e2c27d70] c00000000004805c .do_page_fault+0x3dc/0x7c0 [c0000000e2c27e30] c00000000000ac98 handle_page_fault+0x10/0x30 With fix, we don't enable 1MB as hugepage size. bash-4.2# cd /sys/kernel/mm/hugepages/ bash-4.2# ls hugepages-16384kB hugepages-16777216kB Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Manish Jaggi authored
[ Upstream commit b77d537d ] Only apply the Cavium ACS quirk to devices with ID in the range 0xa000-0xa0ff. These are the on-chip PCI devices for CN81xx/CN83xx/CN88xx. Fixes: b404bcfb ("PCI: Add ACS quirk for all Cavium devices") Reported-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Manish Jaggi <mjaggi@cavium.com> Acked-by:
David Daney <david.daney@cavium.com> Acked-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:
-
Nicolai Hähnle authored
[ Upstream commit c2c139cf ] Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to global list anyway Task 2: grabs hold of the BO, waits on its reservation lock Task 1: releases its reference of the BO; never gives up the reservation lock The patch "drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()" attempts to fix that by releasing the reservation lock in amdgpu code; unfortunately, it introduces a use-after-free when this race _doesn't_ happen. This patch should fix the race properly by never adding the BO to the global list in the first place. Cc: zhoucm1 <david1.zhou@amd.com> Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Tested-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.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:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit fd2b2975 ] Which may happen when we start a tracing session and a thread is waiting for something like "poll" to return, in which case we better print "?" both for the syscall entry timestamp and for the duration. E.g.: Tracing existing mutt session: # perf trace -p `pidof mutt` ? ( ? ): mutt/17135 ... [continued]: poll()) = 1 0.027 ( 0.013 ms): mutt/17135 read(buf: 0x7ffcb3c42cef, count: 1) = 1 0.047 ( 0.008 ms): mutt/17135 poll(ufds: 0x7ffcb3c42c50, nfds: 1, timeout_msecs: 1000) = 1 0.059 ( 0.008 ms): mutt/17135 read(buf: 0x7ffcb3c42cef, count: 1) = 1 <SNIP> Before it would print a large number because we'd do: ttrace->entry_time - trace->base_time And entry_time would be 0, while base_time would be the timestamp for the first event 'perf trace' reads, oops. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Luis Claudio Gonçalves <lclaudio@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-wbcb93ofva2qdjd5ltn5eeqq@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Matthias Kaehlcke authored
[ Upstream commit fd086045 ] Commit 26988efe ("regulator: core: Allow to get voltage count and list from parent") introduces the propagation of the parent voltage count and list for regulators that don't provide this information themselves. The goal is to support simple switch regulators, however as a side effect normal continuous regulators can leak details of their supplies and provide consumers with inconsistent information. Limit the propagation of the voltage count and list to switch regulators. Fixes: 26988efe ("regulator: core: Allow to get voltage count and list from parent") Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Javier Martinez Canillas <javier@osg.samsung.com> Tested-by:
Mark Brown <broonie@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:
Shaohua Li <shli@fb.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 403fe77e ] The second channel of the display unit uses a different module clock than the first channel. Fixes: 84e734f4 ("ARM: dts: silk: add DU DT support") Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 89675f36 ] The second channel of the display unit uses a different module clock than the first channel. Fixes: 46c4f13d ("ARM: shmobile: r8a7794: Add DU node to device tree") Signed-off-by:
-
Geert Uytterhoeven authored
commit 1764f808 upstream. Add the missing module clock for the second channel of the display unit. Signed-off-by:
-
Takashi Sakamoto authored
[ Upstream commit 2128f78f ] In IEC 61883-1, when two quadlets CIP header is used, the most significant bit in second CIP header stands. However, packets from units with MOTU protocol version 3 have a quirk without this flag. Current packet streaming layer handles this as protocol error. This commit adds a new enumeration constant for this quirk, to handle MOTU protocol version 3. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> 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:
-
Mahesh Bandewar authored
[ Upstream commit c4adfc82 ] bond_update_speed_duplex() retrieves speed and duplex settings. There is a possibility of failure in retrieving these values but caller has to assume it's always successful. This leads to having inconsistent slave link settings. If these (speed, duplex) values cannot be retrieved, then keeping the link UP causes problems. The updated bond_update_speed_duplex() returns 0 on success if it retrieves sane values for speed and duplex. On failure it returns 1 and marks the link down. Signed-off-by:
Mahesh Bandewar <maheshb@google.com> 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:
-
Jitendra Bhivare authored
[ Upstream commit eb419229 ] scsi host12: BS_1377 : mgmt_invalidate_connection Failed for cid=256 BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff81332ebf>] __list_add+0xf/0xc0 PGD 0 Oops: 0000 [#1] SMP Modules linked in: ... CPU: 9 PID: 1542 Comm: iscsid Tainted: G ------------ T 3.10.0-514.el7.x86_64 #1 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9, BIOS P89 09/12/2016 task: ffff88076f310fb0 ti: ffff88076bba8000 task.ti: ffff88076bba8000 RIP: 0010:[<ffffffff81332ebf>] [<ffffffff81332ebf>] __list_add+0xf/0xc0 RSP: 0018:ffff88076bbab8e8 EFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff88076bbab990 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880468badf58 RDI: ffff88076bbab990 RBP: ffff88076bbab900 R08: 0000000000000246 R09: 00000000000020de R10: 0000000000000000 R11: ffff88076bbab5be R12: 0000000000000000 R13: ffff880468badf58 R14: 000000000001adb0 R15: ffff88076f310fb0 FS: 00007f377124a880(0000) GS:ffff88046fa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000771318000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff88076bbab990 ffff880468badf50 0000000000000001 ffff88076bbab938 ffffffff810b128b 0000000000000246 00000000cf9b7040 ffff880468bac7a0 0000000000000000 ffff880468bac7a0 ffff88076bbab9d0 ffffffffa05a6ea3 Call Trace: [<ffffffff810b128b>] prepare_to_wait+0x7b/0x90 [<ffffffffa05a6ea3>] beiscsi_mccq_compl_wait+0x153/0x330 [be2iscsi] [<ffffffff810b1600>] ? wake_up_atomic_t+0x30/0x30 [<ffffffffa05981b1>] beiscsi_ep_disconnect+0x91/0x2d0 [be2iscsi] [<ffffffffa0202ffa>] iscsi_if_ep_disconnect.isra.14+0x5a/0x70 [scsi_transport_iscsi] [<ffffffffa02042fb>] iscsi_if_recv_msg+0x113b/0x14a0 [scsi_transport_iscsi] [<ffffffff811dffd8>] ? __kmalloc_node_track_caller+0x58/0x290 [<ffffffffa02046ee>] iscsi_if_rx+0x8e/0x1f0 [scsi_transport_iscsi] [<ffffffff815a351d>] netlink_unicast+0xed/0x1b0 [<ffffffff815a38fe>] netlink_sendmsg+0x31e/0x690 [<ffffffff815a03e4>] ? netlink_rcv_wake+0x44/0x60 [<ffffffff815a19e3>] ? netlink_recvmsg+0x1e3/0x450 beiscsi_mccq_compl_wait gets called even when MCC tag allocation failed for mgmt_invalidate_connection. mcc_wait is not initialized for tag 0 so causes crash in prepare_to_wait. Signed-off-by:
Jitendra Bhivare <jitendra.bhivare@broadcom.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
Chris Leech <cleech@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Alexander Duyck authored
[ Upstream commit 741b8b83 ] We need to reset skb back to NULL when we have freed it in the Rx cleanup path. I found one spot where this wasn't occurring so this patch fixes it. Change-ID: Iaca68934200732cd4a63eb0bd83b539c95f8c4dd Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Tommi Rantala authored
[ Upstream commit 5a234211 ] Valgrind was complaining: $ valgrind ./perf list >/dev/null ==11643== Memcheck, a memory error detector ==11643== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==11643== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==11643== Command: ./perf list ==11643== ==11643== Conditional jump or move depends on uninitialised value(s) ==11643== at 0x4C30620: rindex (vg_replace_strmem.c:199) ==11643== by 0x49DAA9: build_id_cache__origname (build-id.c:198) ==11643== by 0x49E1C7: build_id_cache__valid_id (build-id.c:222) ==11643== by 0x49E1C7: build_id_cache__list_all (build-id.c:507) ==11643== by 0x4B9C8F: print_sdt_events (parse-events.c:2067) ==11643== by 0x4BB0B3: print_events (parse-events.c:2313) ==11643== by 0x439501: cmd_list (builtin-list.c:53) ==11643== by 0x497150: run_builtin (perf.c:359) ==11643== by 0x428CE0: handle_internal_command (perf.c:421) ==11643== by 0x428CE0: run_argv (perf.c:467) ==11643== by 0x428CE0: main (perf.c:614) [...] Additionally, a zero length result from readlink() is not very interesting. Signed-off-by:
Tommi Rantala <tommi.t.rantala@nokia.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20170322130624.21881-3-tommi.t.rantala@nokia.comSigned-off-by:
-
Taeung Song authored
[ Upstream commit 6ebd2547 ] It is wrong way to read link name from a build-id file. Because a build-id file is not anymore a symbolic link but build-id directory of it is symbolic link, so fix it. For example, if build-id file name gotten from dso__build_id_filename() is as below, /root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1/elf To correctly read link name of build-id, use the build-id dir path that is a symbolic link, instead of the above build-id file name like below. /root/.debug/.build-id/4f/75c7d197c951659d1c1b8b5fd49bcdf8f3f8b1 Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1490598638-13947-2-git-send-email-treeze.taeung@gmail.com Fixes: 01412261 ("perf buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid") Signed-off-by:
-
Baruch Siach authored
[ Upstream commit 10b6c0c2 ] An alias name should have an index number even when it is the only of its type. This allows U-Boot to add the local-mac-address property. Otherwise U-Boot skips the alias. Fixes: 6a937927 ("ARM: bcm2835: dt: Add the ethernet to the device trees") Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Acked-by:
Lubomir Rintel <lkundrak@v3.sk> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 1966b865 ] This bit is only supposed to be used with known buggy PHYs, however some platforms might erroneously set it. In order to avoid it, let's make sure this bit is always cleared. If some PHY needs this, we will need to add a quirk flag. Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
