Merge pull request #1 from torvalds/master #41

Open
wants to merge 12 commits into
from

1 participant

@moonlinux

pull-linuxmaster

@dsahern dsahern pushed a commit to dsahern/linux that referenced this pull request Aug 2, 2013
@aakoskin aakoskin staging: MIPS: add Octeon USB HCD support
Add support for Octeon USB HCD. Tested on EdgeRouter Lite with USB
mass storage.

The driver has been extracted from GPL sources of EdgeRouter Lite firmware
(based on Linux 2.6.32.13). Some minor fixes and cleanups have been done
to make it work with 3.10-rc3.

$ uname -a
Linux (none) 3.10.0-rc3-edge-00005-g86cb5bc #41 SMP PREEMPT Sat Jun 1 20:41:46 EEST 2013 mips64 GNU/Linux
$ modprobe octeon-usb
[   37.971683] octeon_usb: module is from the staging directory, the quality is unknown, you have been warned.
[   37.983649] OcteonUSB: Detected 1 ports
[   37.999360] OcteonUSB OcteonUSB.0: Octeon Host Controller
[   38.004847] OcteonUSB OcteonUSB.0: new USB bus registered, assigned bus number 1
[   38.012332] OcteonUSB OcteonUSB.0: irq 122, io mem 0x00000000
[   38.019970] hub 1-0:1.0: USB hub found
[   38.023851] hub 1-0:1.0: 1 port detected
[   38.028101] OcteonUSB: Registered HCD for port 0 on irq 122
[   38.391443] usb 1-1: new high-speed USB device number 2 using OcteonUSB
[   38.586922] usb-storage 1-1:1.0: USB Mass Storage device detected
[   38.597375] scsi0 : usb-storage 1-1:1.0
[   39.604111] scsi 0:0:0:0: Direct-Access              USB DISK 2.0     PMAP PQ: 0 ANSI: 4
[   39.619113] sd 0:0:0:0: [sda] 7579008 512-byte logical blocks: (3.88 GB/3.61 GiB)
[   39.630696] sd 0:0:0:0: [sda] Write Protect is off
[   39.635945] sd 0:0:0:0: [sda] No Caching mode page present
[   39.641464] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   39.651341] sd 0:0:0:0: [sda] No Caching mode page present
[   39.656917] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   39.664296]  sda: sda1 sda2
[   39.675574] sd 0:0:0:0: [sda] No Caching mode page present
[   39.681093] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   39.687223] sd 0:0:0:0: [sda] Attached SCSI removable disk

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: David Daney <ddaney.cavm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
b164935
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
Borislav Petkov x86: Improve the printout of the SMP bootup CPU table
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

Fix padding to a right-hand alignment, cleanup code and bind
reporting width to the max number of supported CPUs on the
system, like this:

 [    0.074509] smpboot: Booting Node   0, Processors:      #1  #2  #3  #4  #5  #6  #7 OK
 [    0.644008] smpboot: Booting Node   1, Processors:  #8  #9 #10 #11 #12 #13 #14 #15 OK
 [    1.245006] smpboot: Booting Node   2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK
 [    1.864005] smpboot: Booting Node   3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK
 [    2.489005] smpboot: Booting Node   4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK
 [    3.093005] smpboot: Booting Node   5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK
 [    3.698005] smpboot: Booting Node   6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK
 [    4.304005] smpboot: Booting Node   7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK
 [    4.961413] Brought up 64 CPUs

and this:

 [    0.072367] smpboot: Booting Node   0, Processors:    #1 #2 #3 #4 #5 #6 #7 OK
 [    0.686329] Brought up 8 CPUs

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Libin <huawei.libin@huawei.com>
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
646e29a
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
Borislav Petkov x86/boot: Further compress CPUs bootup message
Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   #6   #7
[    0.603005] .... node   #1, CPUs:     #8   #9  #10  #11  #12  #13  #14  #15
[    1.200005] .... node   #2, CPUs:    #16  #17  #18  #19  #20  #21  #22  #23
[    1.796005] .... node   #3, CPUs:    #24  #25  #26  #27  #28  #29  #30  #31
[    2.393005] .... node   #4, CPUs:    #32  #33  #34  #35  #36  #37  #38  #39
[    2.996005] .... node   #5, CPUs:    #40  #41  #42  #43  #44  #45  #46  #47
[    3.600005] .... node   #6, CPUs:    #48  #49  #50  #51  #52  #53  #54  #55
[    4.202005] .... node   #7, CPUs:    #56  #57  #58  #59  #60  #61  #62  #63
[    4.811005] .... node   #8, CPUs:    #64  #65  #66  #67  #68  #69  #70  #71
[    5.421006] .... node   #9, CPUs:    #72  #73  #74  #75  #76  #77  #78  #79
[    6.032005] .... node  #10, CPUs:    #80  #81  #82  #83  #84  #85  #86  #87
[    6.648006] .... node  #11, CPUs:    #88  #89  #90  #91  #92  #93  #94  #95
[    7.262005] .... node  #12, CPUs:    #96  #97  #98  #99 #100 #101 #102 #103
[    7.865005] .... node  #13, CPUs:   #104 #105 #106 #107 #108 #109 #110 #111
[    8.466005] .... node  #14, CPUs:   #112 #113 #114 #115 #116 #117 #118 #119
[    9.073006] .... node  #15, CPUs:   #120 #121 #122 #123 #124 #125 #126 #127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@eegorov eegorov referenced this pull request in eegorov/zen-kernel Jan 16, 2014
@zonque zonque connection: make locking for fine-graded
Fixes:

[   23.580615] ======================================================
[   23.580909] [ INFO: possible circular locking dependency detected ]
[   23.581136] 3.12.2+ #41 Tainted: GF          O
[   23.581136] -------------------------------------------------------
[   23.581136] systemctl/494 is trying to acquire lock:
[   23.581136]  (&r->entries_lock){+.+.+.}, at: [<ffffffffa01f2fad>] kdbus_name_lookup+0x3d/0x70 [kdbus]
[   23.581136]
but task is already holding lock:
[   23.581136]  (&b->lock){+.+.+.}, at: [<ffffffffa01ee7bf>] kdbus_conn_kmsg_send+0x3f/0x3c0 [kdbus]
[   23.581136]
which lock already depends on the new lock.

[   23.581136]
the existing dependency chain (in reverse order) is:
[   23.581136]
-> #1 (&b->lock){+.+.+.}:
[   23.581136]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[   23.581136]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[   23.581136]        [<ffffffffa01ee8b5>] kdbus_conn_kmsg_send+0x135/0x3c0 [kdbus]
[   23.581136]        [<ffffffffa01f3d18>] kdbus_notify_name_change+0xa8/0xd0 [kdbus]
[   23.581136]        [<ffffffffa01f32e6>] kdbus_name_acquire+0x276/0x2f0 [kdbus]
[   23.581136]        [<ffffffffa01f34c7>] kdbus_cmd_name_acquire+0x167/0x1e0 [kdbus]
[   23.581136]        [<ffffffffa01f0163>] kdbus_handle_ioctl+0x413/0x930 [kdbus]
[   23.581136]        [<ffffffff811d09d5>] do_vfs_ioctl+0x305/0x530
[   23.581136]        [<ffffffff811d0c81>] SyS_ioctl+0x81/0xa0
[   23.581136]        [<ffffffff8168d9a9>] system_call_fastpath+0x16/0x1b
[   23.581136]
-> #0 (&r->entries_lock){+.+.+.}:
[   23.581136]        [<ffffffff810d5014>] __lock_acquire+0x1944/0x1c20
[   23.581136]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[   23.581136]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[   23.581136]        [<ffffffffa01f2fad>] kdbus_name_lookup+0x3d/0x70 [kdbus]
[   23.581136]        [<ffffffffa01ee7df>] kdbus_conn_kmsg_send+0x5f/0x3c0 [kdbus]
[   23.581136]        [<ffffffffa01f040c>] kdbus_handle_ioctl+0x6bc/0x930 [kdbus]
[   23.581136]        [<ffffffff811d09d5>] do_vfs_ioctl+0x305/0x530
[   23.581136]        [<ffffffff811d0c81>] SyS_ioctl+0x81/0xa0
[   23.581136]        [<ffffffff8168d9a9>] system_call_fastpath+0x16/0x1b
[   23.581136]
other info that might help us debug this:

[   23.581136]  Possible unsafe locking scenario:

[   23.581136]        CPU0                    CPU1
[   23.581136]        ----                    ----
[   23.581136]   lock(&b->lock);
[   23.581136]                                lock(&r->entries_lock);
[   23.581136]                                lock(&b->lock);
[   23.581136]   lock(&r->entries_lock);
[   23.581136]
 *** DEADLOCK ***
b95afd3
@eegorov eegorov referenced this pull request in eegorov/zen-kernel Jan 16, 2014
@zonque zonque connection: fix another lock warning
[   42.633403] =============================================
[   42.633665] [ INFO: possible recursive locking detected ]
[   42.633935] 3.12.2+ #41 Tainted: GF          O
[   42.634057] ---------------------------------------------
[   42.634057] systemd-logind/544 is trying to acquire lock:
[   42.634057]  (&conn->lock/1){+.+...}, at: [<ffffffffa010cc09>]
kdbus_conn_move_messages+0x59/0x140 [kdbus]
[   42.634057]
but task is already holding lock:
[   42.634057]  (&conn->lock/1){+.+...}, at: [<ffffffffa010cbf4>]
kdbus_conn_move_messages+0x44/0x140 [kdbus]
[   42.634057]
other info that might help us debug this:
[   42.634057]  Possible unsafe locking scenario:

[   42.634057]        CPU0
[   42.634057]        ----
[   42.634057]   lock(&conn->lock/1);
[   42.634057]   lock(&conn->lock/1);
[   42.634057]
 *** DEADLOCK ***
f82d227
@eegorov eegorov referenced this pull request in eegorov/zen-kernel Jan 16, 2014
@zonque zonque connection: check for disconnect flag of messages when broadcasting
Fixes:

[   56.219032] ======================================================
[   56.219032] [ INFO: possible circular locking dependency detected ]
[   56.219032] 3.12.2+ #41 Tainted: GF          O
[   56.219032] -------------------------------------------------------
[   56.219032] systemd/512 is trying to acquire lock:
[   56.219032]  (&b->lock){+.+.+.}, at: [<ffffffffa01ef9e5>] kdbus_conn_kmsg_send+0x265/0x3b0 [kdbus]
[   56.219032]
but task is already holding lock:
[   56.219032]  (&conn->names_lock){+.+.+.}, at: [<ffffffffa01f3ec0>] kdbus_name_remove_by_conn+0x40/0xe0 [kdbus]
[   56.219032]
which lock already depends on the new lock.

[   56.219032]
the existing dependency chain (in reverse order) is:
[   56.219032]
-> #1 (&conn->names_lock){+.+.+.}:
[   56.219032]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[   56.219032]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[   56.219032]        [<ffffffffa01f34a0>] kdbus_meta_append+0x320/0x8f0 [kdbus]
[   56.219032]        [<ffffffffa01efa5c>] kdbus_conn_kmsg_send+0x2dc/0x3b0 [kdbus]
[   56.219032]        [<ffffffffa01f13fc>] kdbus_handle_ioctl+0x6bc/0x930 [kdbus]
[   56.219032]        [<ffffffff811d09d5>] do_vfs_ioctl+0x305/0x530
[   56.219032]        [<ffffffff811d0c81>] SyS_ioctl+0x81/0xa0
[   56.219032]        [<ffffffff8168d9a9>] system_call_fastpath+0x16/0x1b
[   56.219032]
-> #0 (&b->lock){+.+.+.}:
[   56.219032]        [<ffffffff810d5014>] __lock_acquire+0x1944/0x1c20
[   56.219032]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[   56.219032]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[   56.219032]        [<ffffffffa01ef9e5>] kdbus_conn_kmsg_send+0x265/0x3b0 [kdbus]
[   56.219032]        [<ffffffffa01f4d08>] kdbus_notify_name_change+0xa8/0xd0 [kdbus]
[   56.219032]        [<ffffffffa01f3d1f>] kdbus_name_entry_release+0xdf/0xf0 [kdbus]
[   56.219032]        [<ffffffffa01f3f2b>] kdbus_name_remove_by_conn+0xab/0xe0 [kdbus]
[   56.219032]        [<ffffffffa01ef6e5>] kdbus_conn_disconnect+0x1f5/0x270 [kdbus]
[   56.219032]        [<ffffffffa01f0c31>] kdbus_handle_release+0xa1/0xb0 [kdbus]
[   56.219032]        [<ffffffff811bf204>] __fput+0xf4/0x250
[   56.219032]        [<ffffffff811bf3ae>] ____fput+0xe/0x10
[   56.219032]        [<ffffffff81088d1c>] task_work_run+0xac/0xe0
[   56.219032]        [<ffffffff8106ae40>] do_exit+0x2d0/0xa80
[   56.219032]        [<ffffffff8106b679>] do_group_exit+0x49/0xc0
[   56.219032]        [<ffffffff8107b0e1>] get_signal_to_deliver+0x2d1/0x6e0
[   56.219032]        [<ffffffff810143e8>] do_signal+0x48/0x580
[   56.219032]        [<ffffffff81014990>] do_notify_resume+0x70/0xa0
[   56.219032]        [<ffffffff8168dce2>] int_signal+0x12/0x17
[   56.219032]
other info that might help us debug this:

[   56.219032]  Possible unsafe locking scenario:

[   56.219032]        CPU0                    CPU1
[   56.219032]        ----                    ----
[   56.219032]   lock(&conn->names_lock);
[   56.219032]                                lock(&b->lock);
[   56.219032]                                lock(&conn->names_lock);
[   56.219032]   lock(&b->lock);
[   56.219032]
 *** DEADLOCK ***
6b6bb49
@eegorov eegorov referenced this pull request in eegorov/zen-kernel Jan 16, 2014
@zonque zonque name: free items outside of locks
Fixes:

[  359.222058] ======================================================
[  359.222058] [ INFO: possible circular locking dependency detected ]
[  359.222058] 3.12.2+ #41 Tainted: GF          O
[  359.222058] -------------------------------------------------------
[  359.222058] systemd/579 is trying to acquire lock:
[  359.222058]  (&conn->names_lock){+.+.+.}, at: [<ffffffffa014e4c0>] kdbus_meta_append+0x320/0x8f0 [kdbus]
[  359.222058]
but task is already holding lock:
[  359.222058]  (&b->lock){+.+.+.}, at: [<ffffffffa014a9d5>] kdbus_conn_kmsg_send+0x265/0x3e0 [kdbus]
[  359.222058]
which lock already depends on the new lock.

[  359.222058]
the existing dependency chain (in reverse order) is:
[  359.222058]
-> #1 (&b->lock){+.+.+.}:
[  359.222058]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[  359.222058]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[  359.222058]        [<ffffffffa014a9d5>] kdbus_conn_kmsg_send+0x265/0x3e0 [kdbus]
[  359.222058]        [<ffffffffa014fd28>] kdbus_notify_name_change+0xa8/0xd0 [kdbus]
[  359.222058]        [<ffffffffa014ed3f>] kdbus_name_entry_release+0xdf/0xf0 [kdbus]
[  359.222058]        [<ffffffffa014ef4b>] kdbus_name_remove_by_conn+0xab/0xe0 [kdbus]
[  359.222058]        [<ffffffffa014a6d9>] kdbus_conn_disconnect+0x1e9/0x260 [kdbus]
[  359.222058]        [<ffffffffa014bc51>] kdbus_handle_release+0xa1/0xb0 [kdbus]
[  359.222058]        [<ffffffff811bf204>] __fput+0xf4/0x250
[  359.222058]        [<ffffffff811bf3ae>] ____fput+0xe/0x10
[  359.222058]        [<ffffffff81088d1c>] task_work_run+0xac/0xe0
[  359.222058]        [<ffffffff8106ae40>] do_exit+0x2d0/0xa80
[  359.222058]        [<ffffffff8106b679>] do_group_exit+0x49/0xc0
[  359.222058]        [<ffffffff8107b0e1>] get_signal_to_deliver+0x2d1/0x6e0
[  359.222058]        [<ffffffff810143e8>] do_signal+0x48/0x580
[  359.222058]        [<ffffffff81014990>] do_notify_resume+0x70/0xa0
[  359.222058]        [<ffffffff8168dce2>] int_signal+0x12/0x17
[  359.222058]
-> #0 (&conn->names_lock){+.+.+.}:
[  359.222058]        [<ffffffff810d5014>] __lock_acquire+0x1944/0x1c20
[  359.222058]        [<ffffffff810d53a0>] lock_acquire+0xb0/0x160
[  359.222058]        [<ffffffff8167fc0b>] mutex_lock_nested+0x7b/0x3c0
[  359.222058]        [<ffffffffa014e4c0>] kdbus_meta_append+0x320/0x8f0 [kdbus]
[  359.222058]        [<ffffffffa014aa7c>] kdbus_conn_kmsg_send+0x30c/0x3e0 [kdbus]
[  359.222058]        [<ffffffffa014c41c>] kdbus_handle_ioctl+0x6bc/0x930 [kdbus]
[  359.222058]        [<ffffffff811d09d5>] do_vfs_ioctl+0x305/0x530
[  359.222058]        [<ffffffff811d0c81>] SyS_ioctl+0x81/0xa0
[  359.222058]        [<ffffffff8168d9a9>] system_call_fastpath+0x16/0x1b
[  359.222058]
other info that might help us debug this:

[  359.222058]  Possible unsafe locking scenario:

[  359.222058]        CPU0                    CPU1
[  359.222058]        ----                    ----
[  359.222058]   lock(&b->lock);
[  359.222058]                                lock(&conn->names_lock);
[  359.222058]                                lock(&b->lock);
[  359.222058]   lock(&conn->names_lock);
[  359.222058]
 *** DEADLOCK ***
0071e01
@moonlinux

pull-linuxmaster

@torvalds torvalds pushed a commit that referenced this pull request Mar 20, 2014
Andreas Herrmann MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx
Starting with commit 3da5278 (of/irq:
Rework of_irq_count()) the following warning is triggered on octeon
cn3xxx:

[    0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230()
[    0.895642] Modules linked in:
[    0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41
[    0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 000000000000000b
[    0.906860] 	  000000000000000a 000000000000000a 0000000000000000 0000000000000000
[    0.906860] 	  ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177
[    0.906860] 	  ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000
[    0.906860] 	  0000000000000000 0000000000000038 0000000000000001 ffffffff81568484
[    0.906860] 	  800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4
[    0.906860] 	  800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    0.906860] 	  0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000
[    0.906860] 	  ...
[    0.971695] Call Trace:
[    0.974139] [<ffffffff811205e0>] show_stack+0x68/0x80
[    0.979183] [<ffffffff81569c9c>] dump_stack+0x8c/0xe0
[    0.984196] [<ffffffff81145efc>] warn_slowpath_common+0x84/0xb8
[    0.990110] [<ffffffff81436888>] of_device_alloc+0x228/0x230
[    0.995726] [<ffffffff814368d8>] of_platform_device_create_pdata+0x48/0xd0
[    1.002593] [<ffffffff81436a94>] of_platform_bus_create+0x134/0x1e8
[    1.008837] [<ffffffff81436af8>] of_platform_bus_create+0x198/0x1e8
[    1.015064] [<ffffffff81436cc4>] of_platform_bus_probe+0xa4/0x100
[    1.021149] [<ffffffff81100570>] do_one_initcall+0xd8/0x128
[    1.026701] [<ffffffff816e2a10>] kernel_init_freeable+0x144/0x210
[    1.032753] [<ffffffff81564bc4>] kernel_init+0x14/0x110
[    1.037973] [<ffffffff8111bb44>] ret_from_kernel_thread+0x14/0x1c

With this commit the kernel starts mapping the interrupts listed for
gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and
octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL)
and this is causing above warning in of_device_alloc().

Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO
lines (neither return error code nor call octeon_irq_set_ciu_mapping
for it). This should avoid the warning.

(As before the real setup for GPIO lines will happen using
irq_domain_ops of gpio-controller.)

This patch is based on Wei's patch v2 (see
http://marc.info/?l=linux-mips&m=139511814813247).

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Reported-by: Yang Wei <wei.yang@windriver.com>
Acked-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6624/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2eddb70
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Apr 8, 2014
mmotm auto import origin
GIT 08edb33

commit 708f04d
Author: Dave Jones <davej@redhat.com>
Date:   Thu Mar 20 15:03:58 2014 -0600

    block: free q->flush_rq in blk_init_allocated_queue error paths
    
    Commit 7982e90 ("block: fix q->flush_rq NULL pointer crash on
    dm-mpath flush") moved an allocation to blk_init_allocated_queue(), but
    neglected to free that allocation on the error paths that follow.
    
    Signed-off-by: Dave Jones <davej@fedoraproject.org>
    Acked-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 11d4616
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Mar 20 22:11:17 2014 -0700

    futex: revert back to the explicit waiter counting code
    
    Srikar Dronamraju reports that commit b0c29f7 ("futexes: Avoid
    taking the hb->lock if there's nothing to wake up") causes java threads
    getting stuck on futexes when runing specjbb on a power7 numa box.
    
    The cause appears to be that the powerpc spinlocks aren't using the same
    ticket lock model that we use on x86 (and other) architectures, which in
    turn result in the "spin_is_locked()" test in hb_waiters_pending()
    occasionally reporting an unlocked spinlock even when there are pending
    waiters.
    
    So this reinstates Davidlohr Bueso's original explicit waiter counting
    code, which I had convinced Davidlohr to drop in favor of figuring out
    the pending waiters by just using the existing state of the spinlock and
    the wait queue.
    
    Reported-and-tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
    Original-code-by: Davidlohr Bueso <davidlohr@hp.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7e09e73
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Mar 20 21:52:17 2014 -0700

    mm: fix swapops.h:131 bug if remap_file_pages raced migration
    
    Add remove_linear_migration_ptes_from_nonlinear(), to fix an interesting
    little include/linux/swapops.h:131 BUG_ON(!PageLocked) found by trinity:
    indicating that remove_migration_ptes() failed to find one of the
    migration entries that was temporarily inserted.
    
    The problem comes from remap_file_pages()'s switch from vma_interval_tree
    (good for inserting the migration entry) to i_mmap_nonlinear list (no good
    for locating it again); but can only be a problem if the remap_file_pages()
    range does not cover the whole of the vma (zap_pte() clears the range).
    
    remove_migration_ptes() needs a file_nonlinear method to go down the
    i_mmap_nonlinear list, applying linear location to look for migration
    entries in those vmas too, just in case there was this race.
    
    The file_nonlinear method does need rmap_walk_control.arg to do this;
    but it never needed vma passed in - vma comes from its own iteration.
    
    Reported-and-tested-by: Dave Jones <davej@redhat.com>
    Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 8729134
Author: Vaibhav Nagarnaik <vnagarnaik@google.com>
Date:   Thu Feb 13 19:51:48 2014 -0800

    tracing: Fix array size mismatch in format string
    
    In event format strings, the array size is reported in two locations.
    One in array subscript and then via the "size:" attribute. The values
    reported there have a mismatch.
    
    For e.g., in sched:sched_switch the prev_comm and next_comm character
    arrays have subscript values as [32] where as the actual field size is
    16.
    
    name: sched_switch
    ID: 301
    format:
            field:unsigned short common_type;       offset:0;       size:2; signed:0;
            field:unsigned char common_flags;       offset:2;       size:1; signed:0;
            field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
            field:int common_pid;   offset:4;       size:4; signed:1;
    
            field:char prev_comm[32];       offset:8;       size:16;        signed:1;
            field:pid_t prev_pid;   offset:24;      size:4; signed:1;
            field:int prev_prio;    offset:28;      size:4; signed:1;
            field:long prev_state;  offset:32;      size:8; signed:1;
            field:char next_comm[32];       offset:40;      size:16;        signed:1;
            field:pid_t next_pid;   offset:56;      size:4; signed:1;
            field:int next_prio;    offset:60;      size:4; signed:1;
    
    After bisection, the following commit was blamed:
    92edca0 tracing: Use direct field, type and system names
    
    This commit removes the duplication of strings for field->name and
    field->type assuming that all the strings passed in
    __trace_define_field() are immutable. This is not true for arrays, where
    the type string is created in event_storage variable and field->type for
    all array fields points to event_storage.
    
    Use __stringify() to create a string constant for the type string.
    
    Also, get rid of event_storage and event_storage_mutex that are not
    needed anymore.
    
    also, an added benefit is that this reduces the overhead of events a bit more:
    
       text    data     bss     dec     hex filename
    8424787 2036472 1302528 11763787         b3804b vmlinux
    8420814 2036408 1302528 11759750         b37086 vmlinux.patched
    
    Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com
    
    Cc: Laurent Chavey <chavey@google.com>
    Cc: stable@vger.kernel.org # 3.10+
    Signed-off-by: Vaibhav Nagarnaik <vnagarnaik@google.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 71ca758
Author: Jim Quinlan <jim2101024@gmail.com>
Date:   Wed Nov 27 15:34:50 2013 -0500

    MIPS: Make local_irq_disable macro safe for non-Mipsr2
    
    For non-mipsr2 processors, the local_irq_disable contains an mfc0-mtc0
    pair with instructions inbetween.  With preemption enabled, this sequence
    may get preempted and effect a stale value of CP0_STATUS when executing
    the mtc0 instruction.  This commit avoids this scenario by incrementing
    the preempt count before the mfc0 and decrementing it after the mtc9.
    
    [ralf@linux-mips.org: This patch is sorting out the part that were missed
    by e97c5b6 [MIPS: Make irqflags.h functions preempt-safe for non-mipsr2
    cpus.]  I also re-enabled the inclusion of <asm/asm-offsets.h> at the top
    of <asm/asmmacro.h>].
    
    Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: cernekee@gmail.com
    Patchwork: https://patchwork.linux-mips.org/patch/6164/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 85d898b
Author: Daniel Kurtz <djkurtz@chromium.org>
Date:   Mon Mar 17 11:28:06 2014 +0800

    drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
    
    The following commit [0] fixed a use-after-free, but left the subdrv open
    in the error path.
    
    [0] commit 6ca605f
    drm/exynos: Fix freeing issues in exynos_drm_drv.c
    
    Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
    Acked-by: Sachin Kamat <sachin.kamat@linaro.org>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>

commit 8878439
Author: Hugh Dickins <hughd@google.com>
Date:   Tue Mar 18 17:38:38 2014 -0700

    mm: fix bad rss-counter if remap_file_pages raced migration
    
    Fix some "Bad rss-counter state" reports on exit, arising from the
    interaction between page migration and remap_file_pages(): zap_pte()
    must count a migration entry when zapping it.
    
    And yes, it is possible (though very unusual) to find an anon page or
    swap entry in a VM_SHARED nonlinear mapping: coming from that horrid
    get_user_pages(write, force) case which COWs even in a shared mapping.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Tested-by: Sasha Levin sasha.levin@oracle.com>
    Tested-by: Dave Jones davej@redhat.com>
    Cc: Cyrill Gorcunov <gorcunov@gmail.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 2eddb70
Author: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Date:   Wed Mar 19 23:03:30 2014 +0100

    MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx
    
    Starting with commit 3da5278 (of/irq:
    Rework of_irq_count()) the following warning is triggered on octeon
    cn3xxx:
    
    [    0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230()
    [    0.895642] Modules linked in:
    [    0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41
    [    0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc
    [    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 000000000000000b
    [    0.906860] 	  000000000000000a 000000000000000a 0000000000000000 0000000000000000
    [    0.906860] 	  ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177
    [    0.906860] 	  ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000
    [    0.906860] 	  0000000000000000 0000000000000038 0000000000000001 ffffffff81568484
    [    0.906860] 	  800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4
    [    0.906860] 	  800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c
    [    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [    0.906860] 	  0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000
    [    0.906860] 	  ...
    [    0.971695] Call Trace:
    [    0.974139] [<ffffffff811205e0>] show_stack+0x68/0x80
    [    0.979183] [<ffffffff81569c9c>] dump_stack+0x8c/0xe0
    [    0.984196] [<ffffffff81145efc>] warn_slowpath_common+0x84/0xb8
    [    0.990110] [<ffffffff81436888>] of_device_alloc+0x228/0x230
    [    0.995726] [<ffffffff814368d8>] of_platform_device_create_pdata+0x48/0xd0
    [    1.002593] [<ffffffff81436a94>] of_platform_bus_create+0x134/0x1e8
    [    1.008837] [<ffffffff81436af8>] of_platform_bus_create+0x198/0x1e8
    [    1.015064] [<ffffffff81436cc4>] of_platform_bus_probe+0xa4/0x100
    [    1.021149] [<ffffffff81100570>] do_one_initcall+0xd8/0x128
    [    1.026701] [<ffffffff816e2a10>] kernel_init_freeable+0x144/0x210
    [    1.032753] [<ffffffff81564bc4>] kernel_init+0x14/0x110
    [    1.037973] [<ffffffff8111bb44>] ret_from_kernel_thread+0x14/0x1c
    
    With this commit the kernel starts mapping the interrupts listed for
    gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and
    octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL)
    and this is causing above warning in of_device_alloc().
    
    Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO
    lines (neither return error code nor call octeon_irq_set_ciu_mapping
    for it). This should avoid the warning.
    
    (As before the real setup for GPIO lines will happen using
    irq_domain_ops of gpio-controller.)
    
    This patch is based on Wei's patch v2 (see
    http://marc.info/?l=linux-mips&m=139511814813247).
    
    Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
    Reported-by: Yang Wei <wei.yang@windriver.com>
    Acked-by: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/6624/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit b08ac66
Author: Viller Hsiao <villerhsiao@gmail.com>
Date:   Tue Mar 18 15:39:34 2014 +0800

    MIPS: ftrace: Tweak safe_load()/safe_store() macros
    
    Due to name collision in ftrace safe_load and safe_store macros,
    these macros cannot take expressions as operands.
    
    For example, compiler will complain for a macro call like the following:
      safe_store_code(new_code2, ip + 4, faulted);
    
      arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
         : [dst] "r" (dst), [src] "r" (src)\
            ^
      arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
        safe_store_code(new_code2, ip + 4, faulted);
        ^
      arch/mips/kernel/ftrace.c:118:32: error: undefined named operand 'ip + 4'
        safe_store_code(new_code2, ip + 4, faulted);
                                      ^
      arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
         : [dst] "r" (dst), [src] "r" (src)\
            ^
      arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
        safe_store_code(new_code2, ip + 4, faulted);
        ^
    
    This build error is triggered by a467109 [MIPS: ftrace: Fix icache flush
    range error].  Tweak variable naming in those macros to allow flexible
    operands.
    
    Signed-off-by: Viller Hsiao <villerhsiao@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: rostedt@goodmis.org
    Cc: fweisbec@gmail.com
    Cc: mingo@redhat.com
    Cc: Qais.Yousef@imgtec.com
    Patchwork: https://patchwork.linux-mips.org/patch/6622/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 749d322
Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date:   Wed Mar 19 12:59:39 2014 +0000

    ALSA: compress: Pass through return value of open ops callback
    
    The snd_compr_open function would always return 0 even if the compressed
    ops open function failed, obviously this is incorrect. Looks like this
    was introduced by a small typo in:
    
    commit a0830db
    ALSA: Add a reference counter to card instance
    
    This patch returns the value from the compressed op as it should.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Acked-by: Vinod Koul <vinod.koul@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 4fe2169
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Thu Feb 13 17:48:12 2014 +0100

    MIPS: BCM47XX: Check all (32) GPIOs when looking for a pin
    
    Broadcom boards support 32 GPIOs and NVRAM may have entires for higher
    ones too. Example:
    gpio23=wombo_reset
    
    Signed-off-by: Rafa? Mi?ecki <zajec5@gmail.com>
    Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: linux-mips@linux-mips.org
    Cc: Rafał Miłecki <zajec5@gmail.com>
    Patchwork: https://patchwork.linux-mips.org/patch/6547/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 0f4706d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 18 14:50:50 2014 +0200

    drm/i915: Disable stolen memory when DMAR is active
    
    We have reports of heavy screen corruption if we try to use the stolen
    memory reserved by the BIOS whilst the DMA-Remapper is active. This
    quirk may be only specific to a few machines or BIOSes, but first lets
    apply the big hammer and always disable use of stolen memory when DMAR
    is active.
    
    v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 8259383
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Mar 17 15:20:59 2014 +0200

    Revert "drm/i915: don't touch the VDD when disabling the panel"
    
    This reverts
    commit dff392d
    Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Date:   Fri Dec 6 17:32:41 2013 -0200
    
        drm/i915: don't touch the VDD when disabling the panel
    
    which didn't take into account
    
    commit 6cb4983
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Sun May 20 17:14:50 2012 +0200
    
        drm/i915: enable vdd when switching off the eDP panel
    
    and
    
    commit 35a3855
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Sun Aug 12 22:17:14 2012 +0200
    
        drm/i915: reorder edp disabling to fix ivb MacBook Air
    
    Unsurprisingly, various MacBooks failed.
    
    Effectively the same has already been done in drm-intel-next-queued.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
    Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 3eb59ec
Author: Li Zefan <lizefan@huawei.com>
Date:   Tue Mar 18 17:02:36 2014 +0800

    cgroup: fix a failure path in create_css()
    
    If online_css() fails, we should remove cgroup files belonging
    to css->ss.
    
    Signed-off-by: Li Zefan <lizefan@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit 707d4ee
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 18 14:26:12 2014 -0600

    Revert "[PATCH] Insert GART region into resource map"
    
    This reverts commit 56dd669, which makes the GART visible in
    /proc/iomem.  This fixes a regression: e501b3d ("agp: Support 64-bit
    APBASE") exposed an existing problem with a conflict between the GART
    region and a PCI BAR region.
    
    The GART addresses are bus addresses, not CPU addresses, and therefore
    should not be inserted in iomem_resource.
    
    On many machines, the GART region is addressable by the CPU as well as by
    an AGP master, but CPU addressability is not required by the spec.  On some
    of these machines, the GART is mapped by a PCI BAR, and in that case, the
    PCI core automatically inserts it into iomem_resource, just as it does for
    all BARs.
    
    Inserting it here means we'll have a conflict if the PCI core later tries
    to claim the GART region, so let's drop the insertion here.
    
    The conflict indirectly causes X failures, as reported by Jouni in the
    bugzilla below.  We detected the conflict even before e501b3d, but
    after it the AGP code (fix_northbridge()) uses the PCI resource (which is
    zeroed because of the conflict) instead of reading the BAR again.
    
    Conflicts:
    	arch/x86_64/kernel/aperture.c
    
    Fixes: e501b3d agp: Support 64-bit APBASE
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
    Reported-and-tested-by: Jouni Mettälä <jtmettala@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

commit 3055644
Author: Clemens Ladisch <clemens@ladisch.de>
Date:   Tue Mar 18 09:31:18 2014 +0100

    ALSA: oxygen: Xonar DG(X): fix Stereo Upmixing regression
    
    The code introduced in commit 1f91ecc ("ALSA: oxygen: modify
    adjust_dg_dac_routing function") accidentally disregarded the old value
    of the playback routing register, so it broke the "Stereo Upmixing"
    mixer control.
    
    The unmuted parts of the channel routing are the same for all settings
    of the output destination, so it suffices to revert that part of the
    patch.
    
    Fixes: 1f91ecc ('ALSA: oxygen: modify adjust_dg_dac_routing function')
    Tested-by: Roman Volkov <v1ron@mail.ru>
    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit e4362d1
Author: Alex Smith <alex.smith@imgtec.com>
Date:   Tue Jan 21 11:22:35 2014 +0000

    MIPS: Fix possible build error with transparent hugepages enabled
    
    If CONFIG_TRANSPARENT_HUGEPAGE is enabled, but CONFIG_HUGETLB_PAGE is not,
    it is possible to end up with a configuration that fails to build with the
    following error:
    
    include/linux/huge_mm.h:125:2: error: #error "hugepages can't be allocated by the buddy allocator"
    
    This is due to CONFIG_FORCE_MAX_ZONEORDER defaulting to 11. It already has
    ranges that change the valid values when HUGETLB_PAGE is enabled, but this
    is not done for TRANSPARENT_HUGEPAGE. Fix by changing the HUGETLB_PAGE
    dependencies to MIPS_HUGE_TLB_SUPPORT, which includes both
    TRANSPARENT_HUGEPAGE and HUGETLB_PAGE.
    
    Signed-off-by: Alex Smith <alex.smith@imgtec.com>
    Reviewed-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/6391/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 27410e8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jan 30 17:58:38 2014 +0100

    drm: Fix use-after-free in the shadow-attache exit code
    
    This regression has been introduced in
    
    commit b3f2333
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Dec 11 11:34:31 2013 +0100
    
        drm: restrict the device list for shadow attached drivers
    
    Reported-by: Dave Jones <davej@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

commit 06e2e88
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Fri Feb 14 17:55:18 2014 +0000

    MIPS: mark O32+FP64 experimental for now
    
    Commit 597ce17 "MIPS: Support for 64-bit FP with O32 binaries"
    introduced support for setting Status.FR=1 for O32 binaries with the
    EF_MIPS_FP64 ELF header flag set. Whilst this flag is currently
    supported by binutils it does introduce an ABI break within userland.
    Objects built with EF_MIPS_FP64 cannot be safely linked with those built
    without it since code in either object may assume behaviour specific to
    a value of FR.
    
    More recently there has been discussion around avoiding further
    fragmentation of the O32 ABI whilst still allowing the use of FR=1 and
    features such as MSA which depend upon it. Details of the plan to allow
    this are still being worked on, and whilst the kernel will need the
    ability to handle FR=1 with O32 tasks it is unclear what else it may
    need to provide to a userland which seeks to avoid another ABI break. In
    order to prevent the proliferation of userland which may rely upon the
    current EF_MIPS_FP64 behaviour this patch marks the kernel support for
    it experimental & disables it by default. Under current proposals it is
    likely that this support can simply be enabled again later, but possibly
    after the introduction of further interfaces with userland and support
    for the MIPS R5 UFR feature.
    
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Cc: Matthew Fortune <matthew.fortune@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: Paul Burton <paul.burton@imgtec.com>
    Patchwork: https://patchwork.linux-mips.org/patch/6549/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit a467109
Author: Viller Hsiao <villerhsiao@gmail.com>
Date:   Sat Feb 22 15:46:49 2014 +0800

    MIPS: ftrace: Fix icache flush range error
    
    In 32-bit mode, the start address passed to flush_icache_range is
    shifted by 4 bytes before the second safe_store_code() call.
    
    This causes system crash from time to time because the first 4 bytes
    might not be flushed properly. This bug exists since linux-3.8.
    
    Also remove obsoleted comment while at it.
    
    Signed-off-by: Viller Hsiao <villerhsiao@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: rostedt@goodmis.org
    Cc: fweisbec@gmail.com
    Cc: mingo@redhat.com
    Cc: Qais.Yousef@imgtec.com
    Patchwork: https://patchwork.linux-mips.org/patch/6586/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 86ca57b
Author: Lars Persson <lars.persson@axis.com>
Date:   Mon Mar 17 12:14:13 2014 +0100

    MIPS: Fix syscall tracing interface
    
    Fix pointer computation for stack-based arguments.
    
    Signed-off-by: Lars Persson <larper@axis.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/6620/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit a8031d2
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Wed Jan 22 14:39:57 2014 +0000

    MIPS: asm: syscall: Fix copying system call arguments
    
    The syscall_get_arguments function expects the arguments to be copied
    to the '*args' argument but instead a local variable was used to hold
    the system call argument. As a result of which, this variable was
    never passed to the filter and any filter testing the system call
    arguments would fail. This is fixed by passing the '*args' variable
    as the destination memory for the system call arguments.
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Reviewed-by: Paul Burton <paul.burton@imgtec.com>
    Reviewed-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/6402/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 7f02c46
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Feb 10 18:42:57 2014 +0000

    MIPS: Octeon: Fix fall through on bar type OCTEON_DMA_BAR_TYPE_SMALL
    
    Bar type OCTEON_DMA_BAR_TYPE_SMALL assigns lo and hi addresses and
    then falls through to OCTEON_DMA_BAR_TYPE_BIG that re-assignes lo and
    hi addresses with totally different values. Add a break so we don't
    fall through.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Acked-by: David Daney <ddaney@caviumnetworks.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/6529/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit b616365
Author: Huacai Chen <chenhc@lemote.com>
Date:   Fri Feb 7 22:31:33 2014 +0800

    MIPS: FPU: Fix conflict of register usage
    
    In _restore_fp_context/_restore_fp_context32, t0 is used for both
    CP0_Status and CP1_FCSR. This is a mistake and cause FP exeception on
    boot, so fix it.
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Tested-by: Andreas Barth <aba@ayous.org>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: Aurelien Jarno <aurelien@aurel32.net>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Patchwork: https://patchwork.linux-mips.org/patch/6507/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit f5868f0
Author: Paul Bolle <pebolle@tiscali.nl>
Date:   Sun Feb 9 14:32:25 2014 +0100

    MIPS: Replace CONFIG_MIPS64 and CONFIG_MIPS32_R2
    
    Commit 597ce17 ("MIPS: Support for 64-bit FP with O32 binaries")
    introduced references to two undefined Kconfig macros. CONFIG_MIPS32_R2
    should clearly be replaced with CONFIG_CPU_MIPS32_R2. And CONFIG_MIPS64
    should be replaced with CONFIG_64BIT.
    
    Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/6522/
    Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 6b5625b
Author: Simon Wood <simon@mungewell.org>
Date:   Thu Mar 13 12:42:03 2014 -0600

    HID: hid-lg4ff: Support new version of G27
    
    It has been reported that there is a new hardware version of the G27
    in the 'wild'. This patch add's this new revision so that it can be
    sent the command to switch to native mode.
    
    Reported-by: "Ivan Baldo" <ibaldo@adinet.com.uy>
    Tested-by: "evilcow" <evilcow93@yahoo.com>
    Signed-off-by: Simon Wood <simon@mungewell.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit e724f08
Author: Paul Mackerras <paulus@samba.org>
Date:   Thu Mar 13 20:02:48 2014 +1100

    KVM: PPC: Book3S HV: Fix register usage when loading/saving VRSAVE
    
    Commit 595e4f7 ("KVM: PPC: Book3S HV: Use load/store_fp_state
    functions in HV guest entry/exit") changed the register usage in
    kvmppc_save_fp() and kvmppc_load_fp() but omitted changing the
    instructions that load and save VRSAVE.  The result is that the
    VRSAVE value was loaded from a constant address, and saved to a
    location past the end of the vcpu struct, causing host kernel
    memory corruption and various kinds of host kernel crashes.
    
    This fixes the problem by using register r31, which contains the
    vcpu pointer, instead of r3 and r4.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit a5b0ccb
Author: Paul Mackerras <paulus@samba.org>
Date:   Thu Mar 13 20:02:02 2014 +1100

    KVM: PPC: Book3S HV: Remove bogus duplicate code
    
    Commit 7b49041 ("KVM: PPC: Book3S HV: Add new state for
    transactional memory") incorrectly added some duplicate code to the
    guest exit path because I didn't manage to clean up after a rebase
    correctly.  This removes the extraneous material.  The presence of
    this extraneous code causes host crashes whenever a guest is run.
    
    Signed-off-by: Paul Mackerras <paulus@samba.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit 5c673b6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Mar 7 20:34:46 2014 +0100

    drm/i915: Don't enable display error interrupts from the start
    
    We need to enable interrupt processing before all the modeset
    state is set up. But that means we can fall over when we get a pipe
    underrun. This shouldn't happen as long as the bios works correctly
    but as usual this turns out to be wishful thinking.
    
    So disable error interrupts at irq install time and rely on the
    re-enabling code in the modeset functions to take care of this.
    
    Note that due to the SDE interrupt handling race we must
    uncondtionally enable all interrupt sources in SDEIER, hence no need
    to enable the SERR bit specifically.
    
    On gmch platforms we don't have an explicit enable/mask bit for fifo
    underruns. Fixing this up would require a bit of software tracking,
    hence is material for a separate patch. To make this possible we need
    to switch all gmch platforms to the new pipestat interrupt handling
    scheme Imre implemented for vlv, and then also add a safe form of sw
    state checking to __cpu_fifo_underrun_reporting_enabled a bit.
    
    v2: Also handle the ilk/snb cpu fifo underrun bits accordingly.
    Spotted by Ville.
    
    v3: Also handle the south interrupt underrun bits on ibx. Again
    spotted by Ville.
    
    Reported-by: Rob Clark <robdclark@gmail.com>
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: stable@vger.kernel.org
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 2430262
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Mar 11 12:58:46 2014 +0200

    drm/i915: Fix scanline counter fixup on BDW
    
    The display interrupts changed on BDW, so the current ILK-HSW specific
    code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required
    bits for BDW, and while at it, change the existing code to use nicer
    looking vblank status bit macros.
    
    Also remove the now stale __raw_i915_read16() definition which was
    left over from the failed gen2 ISR experiment.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962
    Tested-by: Lu Hua <huax.lu@intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit fcb8182
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Mar 11 12:58:45 2014 +0200

    drm/i915: Add a workaround for HSW scanline counter weirdness
    
    On HSW the scanline counter seems to behave differently depending on
    the output type. eDP on port A does what you would expect an the normal
    +1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
    a +2 fixup. Just assume we always need the +2 fixup and accept the
    slight inaccuracy on eDP.
    
    This fixes a regression introduced in:
     commit 8072bfa
     Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
     Date:   Mon Oct 28 21:22:52 2013 +0200
    
        drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
    
    That commit removed the heuristic that tried to fix up the timestamps
    for vblank interrupts that fire a bit too early. Since then the vblank
    timestamp code would treat some vblank interrupts as spurious since the
    scanline counter would indicate that vblank_start wasn't reached yet.
    That in turn lead to incorrect vblank event sequence numbers being
    reported to userspace, which lead to unsteady framerate in applications
    such as XBMC which uses them for timing purposes.
    
    v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika)
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725
    Tested-by: bugzilla1@gmx.com
    Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 51061b8
Author: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
Date:   Thu Mar 6 17:05:27 2014 -0800

    MIPS: math-emu: Fix prefx detection and COP1X function field definition
    
    When running applications which contain the instruction "prefx" on FPU-less
    CPUs, a message "Illegal instruction" will be seen. This instruction is
    supposed to be ignored by the FPU emulator. However, its current detection
    and function field encoding are incorrect. This patch fix the issue.
    
    Signed-off-by: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
    Reviewed-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
    Reviewed-by: Paul Burton <paul.burton@imgtec.com>
    Acked-by: David Daney <david.daney@cavium.com>
    Cc: linux-mips@linux-mips.org
    Cc: Steven.Hill@imgtec.com
    Patchwork: https://patchwork.linux-mips.org/patch/6608/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 7f32890
Author: Jens Axboe <axboe@fb.com>
Date:   Mon Mar 10 14:29:37 2014 -0600

    mtip32xx: fix bad use of smp_processor_id()
    
    mtip_pci_probe() dumps the current CPU when loaded, but it does
    so in a preemptible context. Hence smp_processor_id() correctly
    warns:
    
    BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/155
    caller is mtip_pci_probe+0x53/0x880 [mtip32xx]
    
    Switch to raw_smp_processor_id(), since it's just informational
    and persistent accuracy isn't important.
    
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit 10beafc
Author: Mike Snitzer <msnitzer@redhat.com>
Date:   Sat Mar 8 20:19:20 2014 -0700

    block: change flush sequence list addition back to front add
    
    Commit 1874198 inadvertently changed the rq flush insertion
    from a head to a tail insertion. Fix that back up.
    
    Signed-off-by: Mike Snitzer <msnitzer@redhat.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit 7982e90
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Sat Mar 8 17:20:01 2014 -0700

    block: fix q->flush_rq NULL pointer crash on dm-mpath flush
    
    Commit 1874198 ("blk-mq: rework flush sequencing logic") switched
    ->flush_rq from being an embedded member of the request_queue structure
    to being dynamically allocated in blk_init_queue_node().
    
    Request-based DM multipath doesn't use blk_init_queue_node(), instead it
    uses blk_alloc_queue_node() + blk_init_allocated_queue().  Because
    commit 1874198 placed the dynamic allocation of ->flush_rq in
    blk_init_queue_node() any flush issued to a dm-mpath device would crash
    with a NULL pointer, e.g.:
    
    BUG: unable to handle kernel NULL pointer dereference at           (null)
    IP: [<ffffffff8125037e>] blk_rq_init+0x1e/0xb0
    PGD bb3c7067 PUD bb01d067 PMD 0
    Oops: 0002 [#1] SMP
    ...
    CPU: 5 PID: 5028 Comm: dt Tainted: G        W  O 3.14.0-rc3.snitm+ #10
    ...
    task: ffff88032fb270e0 ti: ffff880079564000 task.ti: ffff880079564000
    RIP: 0010:[<ffffffff8125037e>]  [<ffffffff8125037e>] blk_rq_init+0x1e/0xb0
    RSP: 0018:ffff880079565c98  EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000030
    RDX: ffff880260c74048 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff880079565ca8 R08: ffff880260aa1e98 R09: 0000000000000001
    R10: ffff88032fa78500 R11: 0000000000000246 R12: 0000000000000000
    R13: ffff880260aa1de8 R14: 0000000000000650 R15: 0000000000000000
    FS:  00007f8d36a2a700(0000) GS:ffff88033fca0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000000079b36000 CR4: 00000000000007e0
    Stack:
     0000000000000000 ffff880260c74048 ffff880079565cd8 ffffffff81257a47
     ffff880260aa1de8 ffff880260c74048 0000000000000001 0000000000000000
     ffff880079565d08 ffffffff81257c2d 0000000000000000 ffff880260aa1de8
    Call Trace:
     [<ffffffff81257a47>] blk_flush_complete_seq+0x2d7/0x2e0
     [<ffffffff81257c2d>] blk_insert_flush+0x1dd/0x210
     [<ffffffff8124ec59>] __elv_add_request+0x1f9/0x320
     [<ffffffff81250681>] ? blk_account_io_start+0x111/0x190
     [<ffffffff81253a4b>] blk_queue_bio+0x25b/0x330
     [<ffffffffa0020bf5>] dm_request+0x35/0x40 [dm_mod]
     [<ffffffff812530c0>] generic_make_request+0xc0/0x100
     [<ffffffff81253173>] submit_bio+0x73/0x140
     [<ffffffff811becdd>] submit_bio_wait+0x5d/0x80
     [<ffffffff81257528>] blkdev_issue_flush+0x78/0xa0
     [<ffffffff811c1f6f>] blkdev_fsync+0x3f/0x60
     [<ffffffff811b7fde>] vfs_fsync_range+0x1e/0x20
     [<ffffffff811b7ffc>] vfs_fsync+0x1c/0x20
     [<ffffffff811b81f1>] do_fsync+0x41/0x80
     [<ffffffff8118874e>] ? SyS_lseek+0x7e/0x80
     [<ffffffff811b8260>] SyS_fsync+0x10/0x20
     [<ffffffff8154c2d2>] system_call_fastpath+0x16/0x1b
    
    Fix this by moving the ->flush_rq allocation from blk_init_queue_node()
    to blk_init_allocated_queue().  blk_init_queue_node() also calls
    blk_init_allocated_queue() so this change is functionality equivalent
    for all blk_init_queue_node() callers.
    
    Reported-by: Hannes Reinecke <hare@suse.de>
    Reported-by: Christoph Hellwig <hch@infradead.org>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Jens Axboe <axboe@fb.com>

commit 031365b
Author: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
Date:   Fri Feb 28 10:23:03 2014 -0800

    MIPS: APRP: Choose the correct VPE loader by fixing the linking
    
    Now we have CONFIG_MIPS_VPE_LOADER and CONFIG_MIPS_VPE_LOADER_[CMP|MT]. The
    latter two are used by the 2 exclusive flavors. The vpe_run in malta-amon.c
    is for CMP APRP. Without the fix, this vpe_run will be used in MT APRP.
    
    Reviewed-by: Steven J. Hill <Steven.Hill@imgtec.com>
    Signed-off-by: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: john@phrozen.org
    Patchwork: https://patchwork.linux-mips.org/patch/6589/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit eee5794
Author: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
Date:   Fri Feb 28 10:23:02 2014 -0800

    MIPS: APRP: Unregister rtlx interrupt hook at module exit
    
    If the aprp_hook is not assigned back to NULL, it will still be called
    after module exits. This is not wanted.
    
    Reviewed-by: Steven J. Hill <Steven.Hill@imgtec.com>
    Signed-off-by: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: john@phrozen.org
    Patchwork: https://patchwork.linux-mips.org/patch/6590/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 9c1f6e0
Author: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
Date:   Fri Feb 28 10:23:01 2014 -0800

    MIPS: APRP: Fix the linking of rtlx interrupt hook
    
    There are 2 errors with the existing aprp_hook linking:
    - The prefix CONFIG_ is missing;
    - The hook should be linked exclusively in the cases of MT and CMP.
    Signed-off-by: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com>
    Reviewed-by: Steven J. Hill <Steven.Hill@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Cc: john@phrozen.org
    Patchwork: https://patchwork.linux-mips.org/patch/6588/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 4890e2e
Author: Markos Chandras <markos.chandras@imgtec.com>
Date:   Wed Feb 19 10:17:18 2014 +0000

    MIPS: bcm47xx: Include missing errno.h for ENXIO
    
    Fixes the following build problen on allmodconfig:
    
    arch/mips/bcm47xx/board.c: In function 'bcm47xx_board_detect':
    arch/mips/bcm47xx/board.c:291:14: error: 'ENXIO' undeclared
    (first use in this function)
    
    Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/6571/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit d334c2b
Author: Manuel Lauss <manuel.lauss@gmail.com>
Date:   Thu Feb 20 14:37:40 2014 +0100

    MIPS: Alchemy: Fix unchecked kstrtoul return value
    
    enabled __must_check logic triggers a build error for mtx1 and gpr
    in the prom init code.  Fix by checking the kstrtoul() return value.
    
    Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
    Cc: Linux-MIPS <linux-mips@linux-mips.org>
    Patchwork: https://patchwork.linux-mips.org/patch/6574/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit f517928
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Mon Feb 10 18:00:17 2014 +0100

    MIPS: Fix randconfig build error.
    
      CC      arch/mips/kernel/ptrace.o
    In file included from arch/mips/kernel/ptrace.c:42:0:
    arch/mips/kernel/ptrace.c: In function ‘mips_get_syscall_arg’:
    /home/ralf/src/linux/linux-mips/arch/mips/include/asm/syscall.h:60:1: error: control reaches end of non-void function [-Werror=return-type]
    cc1: all warnings being treated as errors
    make[2]: *** [arch/mips/kernel/ptrace.o] Error 1
    make[1]: *** [arch/mips/kernel] Error 2
    make: *** [arch/mips] Error 2
    
    Fixed by marking the end of mips_get_syscall_arg() as unreachable.
    
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

commit 24bd9bf
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Tue Mar 4 22:38:10 2014 -0800

    drm/i915: Fix PSR programming
    
    | has a higher precedence than ?. Therefore, the calculation doesn't do
    at all what you would expect. Thanks to Ken for convincing me that this
    was indeed the issue. Send me back to C programmer school, please.
    
    I'm sort of surprised PSR was continuing to work for people. It should
    be broken IMO (and it was broken for me, but I had assumed it never
    worked).
    
    Regression from:
    commit ed8546a
    Author: Ben Widawsky <benjamin.widawsky@intel.com>
    Date:   Mon Nov 4 22:45:05 2013 -0800
    
        drm/i915/bdw: Support eDP PSR
    
    Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
    Cc: Art Runyan <arthur.j.runyan@intel.com>
    Reported-by: "Kumar, Kiran S" <kiran.s.kumar@intel.com>
    Cc: stable@vger.kernel.org [v3.13+]
    Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 224aa3e
Author: Stefan Agner <stefan@agner.ch>
Date:   Wed Mar 5 23:11:08 2014 +0100

    clocksource: vf_pit_timer: use complement for sched_clock reading
    
    Vybrids PIT register is monitonic decreasing. However, sched_clock
    reading needs to be monitonic increasing. Use bitwise not to get
    the complement of the clock register. This fixes the clock going
    backward. Also, the clock now starts at 0 since we load the
    register with the maximum value at start.
    
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Cc: daniel.lezcano@linaro.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux@arm.linux.org.uk
    Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.ch
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 47587fc
Author: Fernando Luis Vázquez Cao <fernando_b1@lab.ntt.co.jp>
Date:   Wed Feb 26 16:51:24 2014 +0900

    HID: hidraw: fix warning destroying hidraw device files after parent
    
    I noticed that after hot unplugging a Logitech unifying receiver
    (drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a
    stack trace similar to this:
    
    usb 1-1.1.2: USB disconnect, device number 7
    WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0()
    sysfs group ffffffff8187fa20 not found for kobject 'hidraw0'
    [...]
    CPU: 0 PID: 2865 Comm: upowerd Tainted: G        W 3.14.0-rc4 #7
    Hardware name: LENOVO 7783PN4/        , BIOS 9HKT43AUS 07/11/2011
     0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7
     ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8
     ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028
    Call Trace:
     [<ffffffff814cd684>] ? dump_stack+0x41/0x51
     [<ffffffff810616e7>] ? warn_slowpath_common+0x77/0x90
     [<ffffffff8106174c>] ? warn_slowpath_fmt+0x4c/0x50
     [<ffffffff81374fd0>] ? device_del+0x40/0x1b0
     [<ffffffff8137516f>] ? device_unregister+0x2f/0x50
     [<ffffffff813751fa>] ? device_destroy+0x3a/0x40
     [<ffffffffa03ca245>] ? drop_ref+0x55/0x120 [hid]
     [<ffffffffa03ca3e6>] ? hidraw_release+0x96/0xb0 [hid]
     [<ffffffff811929da>] ? __fput+0xca/0x210
     [<ffffffff8107fe17>] ? task_work_run+0x97/0xd0
     [<ffffffff810139a9>] ? do_notify_resume+0x69/0xa0
     [<ffffffff814dbd22>] ? int_signal+0x12/0x17
    ---[ end trace 63f4a46f6566d737 ]---
    
    During device removal hid_disconnect() is called via hid_hw_stop() to
    stop the device and free all its resources, including the sysfs
    files. The problem is that if a user space process, such as upowerd,
    holds a reference to a hidraw file the corresponding sysfs files will
    be kept around (drop_ref() does not call device_destroy() if the open
    counter is not 0) and it will be usb_disconnect() who, by calling
    device_del() for the USB device, will indirectly remove the sysfs
    files of the hidraw device (sysfs_remove_dir() is recursive these
    days). Because of this, by the time user space releases the last
    reference to the hidraw file and drop_ref() tries to destroy the
    device the sysfs files are already gone and the kernel will print
    the warning above.
    
    Fix this by calling device_destroy() at USB disconnect time.
    
    Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
    Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
    Cc: stable@vger.kernel.org	# 3.13
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 5f5750d
Author: Frank Praznik <frank.praznik@oh.rr.com>
Date:   Wed Feb 19 13:09:22 2014 -0500

    HID: sony: Fix work queue issues.
    
    Don't initialize force-feedback for devices that don't support it to avoid calls
    to schedule_work() with an uninitialized work_struct.
    
    Move the cancel_work_sync() call out of sony_destroy_ff() since the state worker
    is used for the LEDs even when force-feedback is disabled.
    
    Remove sony_destroy_ff() to avoid a compiler warning since it is no longer used.
    
    Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
954b775
@gregnietsky gregnietsky pushed a commit to Distrotech/linux that referenced this pull request Apr 9, 2014
@ebiederm ebiederm net: Fix ip link add netns oops
commit 13ad177 upstream.

Ed Swierk <eswierk@bigswitch.com> writes:
> On 2.6.35.7
>  ip link add link eth0 netns 9999 type macvlan
> where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
> [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
>  [10663.821917] IP: [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
>  [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
>  [10663.821944] Oops: 0000 [#1] SMP
>  [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
>  [10663.821959] CPU 3
>  [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class
>  [10663.822155]
>  [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
>  [10663.822167] RIP: 0010:[<ffffffff8149c2fa>] [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
>  [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
>  [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
>  [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
>  [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
>  [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
>  [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
>  [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
>  [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>  [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
>  [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>  [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>  [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
>  [10663.822236] Stack:
>  [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
>  [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
>  [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
>  [10663.822281] Call Trace:
>  [10663.822290] [<ffffffff814a2bb5>] ? dev_addr_init+0x75/0xb0
>  [10663.822298] [<ffffffff8149c413>] dev_alloc_name+0x43/0x90
>  [10663.822307] [<ffffffff814a85ee>] rtnl_create_link+0xbe/0x1b0
>  [10663.822314] [<ffffffff814ab2aa>] rtnl_newlink+0x48a/0x570
>  [10663.822321] [<ffffffff814aafcc>] ? rtnl_newlink+0x1ac/0x570
>  [10663.822332] [<ffffffff81030064>] ? native_x2apic_icr_read+0x4/0x20
>  [10663.822339] [<ffffffff814a8c17>] rtnetlink_rcv_msg+0x177/0x290
>  [10663.822346] [<ffffffff814a8aa0>] ? rtnetlink_rcv_msg+0x0/0x290
>  [10663.822354] [<ffffffff814c25d9>] netlink_rcv_skb+0xa9/0xd0
>  [10663.822360] [<ffffffff814a8a85>] rtnetlink_rcv+0x25/0x40
>  [10663.822367] [<ffffffff814c223e>] netlink_unicast+0x2de/0x2f0
>  [10663.822374] [<ffffffff814c303e>] netlink_sendmsg+0x1fe/0x2e0
>  [10663.822383] [<ffffffff81488533>] sock_sendmsg+0xf3/0x120
>  [10663.822391] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
>  [10663.822400] [<ffffffff81168656>] ? __d_lookup+0x136/0x150
>  [10663.822406] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
>  [10663.822414] [<ffffffff812b7a0d>] ? _atomic_dec_and_lock+0x4d/0x80
>  [10663.822422] [<ffffffff8116ea90>] ? mntput_no_expire+0x30/0x110
>  [10663.822429] [<ffffffff81486ff5>] ? move_addr_to_kernel+0x65/0x70
>  [10663.822435] [<ffffffff81493308>] ? verify_iovec+0x88/0xe0
>  [10663.822442] [<ffffffff81489020>] sys_sendmsg+0x240/0x3a0
> [10663.822450] [<ffffffff8111e2a9>] ? __do_fault+0x479/0x560
>  [10663.822457] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
>  [10663.822465] [<ffffffff8116cf4a>] ? alloc_fd+0x10a/0x150
>  [10663.822473] [<ffffffff8158d76e>] ? do_page_fault+0x15e/0x350
>  [10663.822482] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b
>  [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
>  [10663.822618] RIP [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
>  [10663.822627] RSP <ffff88014aebf7b8>
>  [10663.822631] CR2: 000000000000006d
>  [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---

This bug was introduced in:
commit 81adee4
Author: Eric W. Biederman <ebiederm@aristanetworks.com>
Date:   Sun Nov 8 00:53:51 2009 -0800

    net: Support specifying the network namespace upon device creation.

    There is no good reason to not support userspace specifying the
    network namespace during device creation, and it makes it easier
    to create a network device and pass it to a child network namespace
    with a well known name.

    We have to be careful to ensure that the target network namespace
    for the new device exists through the life of the call.  To keep
    that logic clear I have factored out the network namespace grabbing
    logic into rtnl_link_get_net.

    In addtion we need to continue to pass the source network namespace
    to the rtnl_link_ops.newlink method so that we can find the base
    device source network namespace.

    Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

Where apparently I forgot to add error handling to the path where we create
a new network device in a new network namespace, and pass in an invalid pid.

Reported-by: Ed Swierk <eswierk@bigswitch.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
67edd8e
@tom3q tom3q pushed a commit to tom3q/linux that referenced this pull request Jun 10, 2014
Thierry Reding drm/plane: Fix a couple of checkpatch warnings
Code should be indented using tabs rather than spaces (see CodingStyle)
and the canonical form to declare a constant static variable is using
"static const" rather than "const static". Fixes the following warnings
from checkpatch:

	$ scripts/checkpatch.pl -f drivers/gpu/drm/drm_plane_helper.c
	WARNING: storage class should be at the beginning of the declaration
	#40: FILE: drivers/gpu/drm/drm_plane_helper.c:40:
	+const static uint32_t safe_modeset_formats[] = {

	WARNING: please, no spaces at the start of a line
	#41: FILE: drivers/gpu/drm/drm_plane_helper.c:41:
	+       DRM_FORMAT_XRGB8888,$

	WARNING: please, no spaces at the start of a line
	#42: FILE: drivers/gpu/drm/drm_plane_helper.c:42:
	+       DRM_FORMAT_ARGB8888,$

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
233fd4e
@KarthikNayak KarthikNayak pushed a commit that referenced this pull request Jun 16, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
a700666
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request Jun 23, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
87eb349
@Gnurou Gnurou pushed a commit to Gnurou/linux that referenced this pull request Jun 27, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d79ed55
@JoonsooKim JoonsooKim pushed a commit to JoonsooKim/linux that referenced this pull request Jul 4, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
91b59ef
@krieger-od krieger-od pushed a commit to krieger-od/linux that referenced this pull request Jul 10, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
485d440
@krieger-od krieger-od pushed a commit to krieger-od/linux that referenced this pull request Jul 10, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d30f8a6
@krieger-od krieger-od pushed a commit to krieger-od/linux that referenced this pull request Jul 17, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
857dbc7
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Jul 25, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5cd2714
@krieger-od krieger-od pushed a commit to krieger-od/linux that referenced this pull request Aug 4, 2014
Andrew Morton ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes
ERROR: trailing whitespace
#41: FILE: fs/ocfs2/inode.c:1197:
+^Ireturn 1; $

total: 1 errors, 0 warnings, 18 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/ocfs2-free-inode-when-i_count-becomes-zero.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Xue jiufei <xuejiufei@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
fc10148
@heftig heftig referenced this pull request in zen-kernel/zen-kernel Sep 6, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
306ccdf
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Sep 9, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
da660d1
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Sep 9, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
3501de9
@baerwolf baerwolf pushed a commit to baerwolf/linux-stephan that referenced this pull request Sep 19, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: deleted code is slightly different; we don't
 have list_next_entry()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
e45a1a0
@aryabinin aryabinin pushed a commit to aryabinin/linux that referenced this pull request Sep 24, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2da6427
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Sep 25, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
79512e7
@Naoya-Horiguchi Naoya-Horiguchi pushed a commit that referenced this pull request Sep 26, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
e52ad00
@koct9i koct9i pushed a commit to koct9i/linux that referenced this pull request Sep 27, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
4b6a520
@tom3q tom3q pushed a commit to tom3q/linux that referenced this pull request Oct 2, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ceab77d
@aryabinin aryabinin pushed a commit to aryabinin/linux that referenced this pull request Oct 3, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7e98789
@pstglia pstglia added a commit to pstglia/linux that referenced this pull request Oct 6, 2014
Andreas Herrmann MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx
Starting with commit 3da5278 (of/irq:
Rework of_irq_count()) the following warning is triggered on octeon
cn3xxx:

[    0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230()
[    0.895642] Modules linked in:
[    0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41
[    0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 000000000000000b
[    0.906860] 	  000000000000000a 000000000000000a 0000000000000000 0000000000000000
[    0.906860] 	  ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177
[    0.906860] 	  ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000
[    0.906860] 	  0000000000000000 0000000000000038 0000000000000001 ffffffff81568484
[    0.906860] 	  800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4
[    0.906860] 	  800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    0.906860] 	  0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000
[    0.906860] 	  ...
[    0.971695] Call Trace:
[    0.974139] [<ffffffff811205e0>] show_stack+0x68/0x80
[    0.979183] [<ffffffff81569c9c>] dump_stack+0x8c/0xe0
[    0.984196] [<ffffffff81145efc>] warn_slowpath_common+0x84/0xb8
[    0.990110] [<ffffffff81436888>] of_device_alloc+0x228/0x230
[    0.995726] [<ffffffff814368d8>] of_platform_device_create_pdata+0x48/0xd0
[    1.002593] [<ffffffff81436a94>] of_platform_bus_create+0x134/0x1e8
[    1.008837] [<ffffffff81436af8>] of_platform_bus_create+0x198/0x1e8
[    1.015064] [<ffffffff81436cc4>] of_platform_bus_probe+0xa4/0x100
[    1.021149] [<ffffffff81100570>] do_one_initcall+0xd8/0x128
[    1.026701] [<ffffffff816e2a10>] kernel_init_freeable+0x144/0x210
[    1.032753] [<ffffffff81564bc4>] kernel_init+0x14/0x110
[    1.037973] [<ffffffff8111bb44>] ret_from_kernel_thread+0x14/0x1c

With this commit the kernel starts mapping the interrupts listed for
gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and
octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL)
and this is causing above warning in of_device_alloc().

Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO
lines (neither return error code nor call octeon_irq_set_ciu_mapping
for it). This should avoid the warning.

(As before the real setup for GPIO lines will happen using
irq_domain_ops of gpio-controller.)

This patch is based on Wei's patch v2 (see
http://marc.info/?l=linux-mips&m=139511814813247).

Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Reported-by: Yang Wei <wei.yang@windriver.com>
Acked-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6624/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2f2c39d
@pstglia pstglia added a commit to pstglia/linux that referenced this pull request Oct 6, 2014
Thierry Reding drm/plane: Fix a couple of checkpatch warnings
Code should be indented using tabs rather than spaces (see CodingStyle)
and the canonical form to declare a constant static variable is using
"static const" rather than "const static". Fixes the following warnings
from checkpatch:

	$ scripts/checkpatch.pl -f drivers/gpu/drm/drm_plane_helper.c
	WARNING: storage class should be at the beginning of the declaration
	#40: FILE: drivers/gpu/drm/drm_plane_helper.c:40:
	+const static uint32_t safe_modeset_formats[] = {

	WARNING: please, no spaces at the start of a line
	#41: FILE: drivers/gpu/drm/drm_plane_helper.c:41:
	+       DRM_FORMAT_XRGB8888,$

	WARNING: please, no spaces at the start of a line
	#42: FILE: drivers/gpu/drm/drm_plane_helper.c:42:
	+       DRM_FORMAT_ARGB8888,$

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
53977fb
@bengal bengal pushed a commit to bengal/linux that referenced this pull request Oct 7, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#38: FILE: include/linux/mmdebug.h:34:
+                if (unlikely(cond)) {^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#39: FILE: include/linux/mmdebug.h:35:
+                        dump_mm(mm);^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#40: FILE: include/linux/mmdebug.h:36:
+                        BUG();^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

WARNING: please, no spaces at the start of a line
#41: FILE: include/linux/mmdebug.h:37:
+                }^I^I^I^I^I^I^I\$

ERROR: code indent should use tabs where possible
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: please, no spaces at the start of a line
#42: FILE: include/linux/mmdebug.h:38:
+        } while (0)$

WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then dev_alert(dev, ... then pr_alert(...  to printk(KERN_ALERT ...
#74: FILE: mm/debug.c:171:
+	printk(KERN_ALERT

total: 6 errors, 7 warnings, 109 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
      scripts/cleanfile

./patches/mm-introduce-vm_bug_on_mm.patch has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d17e8aa
@kees kees pushed a commit to kees/linux that referenced this pull request Oct 9, 2014
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
BugLink: http://bugs.launchpad.net/bugs/1371601

commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
a40c9dd
@torvalds torvalds pushed a commit that referenced this pull request Oct 29, 2014
@pranith pranith powerpc: Wire up sys_bpf() syscall
This patch wires up the new syscall sys_bpf() on powerpc.

Passes the tests in samples/bpf:

    #0 add+sub+mul OK
    #1 unreachable OK
    #2 unreachable2 OK
    #3 out of range jump OK
    #4 out of range jump2 OK
    #5 test1 ld_imm64 OK
    #6 test2 ld_imm64 OK
    #7 test3 ld_imm64 OK
    #8 test4 ld_imm64 OK
    #9 test5 ld_imm64 OK
    #10 no bpf_exit OK
    #11 loop (back-edge) OK
    #12 loop2 (back-edge) OK
    #13 conditional loop OK
    #14 read uninitialized register OK
    #15 read invalid register OK
    #16 program doesn't init R0 before exit OK
    #17 stack out of bounds OK
    #18 invalid call insn1 OK
    #19 invalid call insn2 OK
    #20 invalid function call OK
    #21 uninitialized stack1 OK
    #22 uninitialized stack2 OK
    #23 check valid spill/fill OK
    #24 check corrupted spill/fill OK
    #25 invalid src register in STX OK
    #26 invalid dst register in STX OK
    #27 invalid dst register in ST OK
    #28 invalid src register in LDX OK
    #29 invalid dst register in LDX OK
    #30 junk insn OK
    #31 junk insn2 OK
    #32 junk insn3 OK
    #33 junk insn4 OK
    #34 junk insn5 OK
    #35 misaligned read from stack OK
    #36 invalid map_fd for function call OK
    #37 don't check return value before access OK
    #38 access memory with incorrect alignment OK
    #39 sometimes access memory with incorrect alignment OK
    #40 jump test 1 OK
    #41 jump test 2 OK
    #42 jump test 3 OK
    #43 jump test 4 OK

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
fcbb539
@dabrace dabrace referenced this pull request in dabrace/linux Nov 10, 2014
@pranith pranith powerpc: Wire up sys_bpf() syscall
This patch wires up the new syscall sys_bpf() on powerpc.

Passes the tests in samples/bpf:

    #0 add+sub+mul OK
    #1 unreachable OK
    #2 unreachable2 OK
    #3 out of range jump OK
    #4 out of range jump2 OK
    #5 test1 ld_imm64 OK
    #6 test2 ld_imm64 OK
    #7 test3 ld_imm64 OK
    #8 test4 ld_imm64 OK
    #9 test5 ld_imm64 OK
    #10 no bpf_exit OK
    #11 loop (back-edge) OK
    #12 loop2 (back-edge) OK
    #13 conditional loop OK
    #14 read uninitialized register OK
    #15 read invalid register OK
    #16 program doesn't init R0 before exit OK
    #17 stack out of bounds OK
    #18 invalid call insn1 OK
    #19 invalid call insn2 OK
    #20 invalid function call OK
    #21 uninitialized stack1 OK
    #22 uninitialized stack2 OK
    #23 check valid spill/fill OK
    #24 check corrupted spill/fill OK
    #25 invalid src register in STX OK
    #26 invalid dst register in STX OK
    #27 invalid dst register in ST OK
    #28 invalid src register in LDX OK
    #29 invalid dst register in LDX OK
    #30 junk insn OK
    #31 junk insn2 OK
    #32 junk insn3 OK
    #33 junk insn4 OK
    #34 junk insn5 OK
    #35 misaligned read from stack OK
    #36 invalid map_fd for function call OK
    #37 don't check return value before access OK
    #38 access memory with incorrect alignment OK
    #39 sometimes access memory with incorrect alignment OK
    #40 jump test 1 OK
    #41 jump test 2 OK
    #42 jump test 3 OK
    #43 jump test 4 OK

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
7a0faa9
@torvalds torvalds pushed a commit that referenced this pull request Dec 15, 2014
@fulong82 fulong82 firmware loader: fix hung task warning dump
When using request_firmware_nowait() with FW_ACTION_NOHOTPLUG param to
expose user helper interface, if the user do not react immediately, after
120 seconds there will be a hung task warning message dumped as below:

[ 3000.784235] INFO: task kworker/0:0:8259 blocked for more than 120 seconds.
[ 3000.791281]       Tainted: G            E 3.16.0-rc1-yocto-standard #41
[ 3000.798082] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 3000.806072] kworker/0:0     D cd0075c8     0  8259      2 0x00000000
[ 3000.812765] Workqueue: events request_firmware_work_func
[ 3000.818253]  cd375e18 00000046 0000000e cd0075c8 000000f0 cd40ea00 cd375fec 1b883e89
[ 3000.826374]  0000026b cd40ea00 80000000 00000001 cd0075c8 00000000 cd375de4 c119917f
[ 3000.834492]  cd563360 cd375df4 c119a0ab cd563360 00000000 cd375e24 c119a1d6 00000000
[ 3000.842616] Call Trace:
[ 3000.845252]  [<c119917f>] ? kernfs_next_descendant_post+0x3f/0x50
[ 3000.851543]  [<c119a0ab>] ? kernfs_activate+0x6b/0xc0
[ 3000.856790]  [<c119a1d6>] ? kernfs_add_one+0xd6/0x130
[ 3000.862047]  [<c15fdb02>] schedule+0x22/0x60
[ 3000.866548]  [<c15fd195>] schedule_timeout+0x175/0x1d0
[ 3000.871887]  [<c119b391>] ? __kernfs_create_file+0x71/0xa0
[ 3000.877574]  [<c119bb9a>] ? sysfs_add_file_mode_ns+0xaa/0x180
[ 3000.883533]  [<c15fe84f>] wait_for_completion+0x6f/0xb0
[ 3000.888961]  [<c1065200>] ? wake_up_process+0x40/0x40
[ 3000.894219]  [<c13cb600>] _request_firmware+0x750/0x9f0
[ 3000.899666]  [<c1382a7f>] ? n_tty_receive_buf2+0x1f/0x30
[ 3000.905200]  [<c13cba02>] request_firmware_work_func+0x22/0x50
[ 3000.911235]  [<c10550d2>] process_one_work+0x122/0x380
[ 3000.916571]  [<c1055859>] worker_thread+0xf9/0x470
[ 3000.921555]  [<c1055760>] ? create_and_start_worker+0x50/0x50
[ 3000.927497]  [<c1055760>] ? create_and_start_worker+0x50/0x50
[ 3000.933448]  [<c105a5ff>] kthread+0x9f/0xc0
[ 3000.937850]  [<c15ffd40>] ret_from_kernel_thread+0x20/0x30
[ 3000.943548]  [<c105a560>] ? kthread_worker_fn+0x100/0x100

This patch change the wait_for_completion() function call to
wait_for_completion_interruptible() function call for solving the issue.

Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
000deba
@dongsupark dongsupark pushed a commit to dongsupark/linux that referenced this pull request Dec 18, 2014
Ming Lin block: fix panic in generic_make_request()
bio should be added to splits.
Fixed below panic.

[    1.112557] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    1.112563] IP: [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112564] PGD 0
[    1.112566] Oops: 0002 [#1] PREEMPT SMP
[    1.112568] Modules linked in:
[    1.112570] CPU: 3 PID: 530 Comm: kworker/u8:2 Not tainted 3.18.0-00033-ge76e0b3 #41
[    1.112571] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    1.112575] Workqueue: events_unbound async_run_entry_fn
[    1.112576] task: ffff88001d8eae90 ti: ffff88001dad0000 task.ti: ffff88001dad0000
[    1.112579] RIP: 0010:[<ffffffff812bc2d3>]  [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112579] RSP: 0000:ffff88001dad3798  EFLAGS: 00010246
[    1.112580] RAX: 0000000000000000 RBX: ffff88001d8eae90 RCX: 0000000000000008
[    1.112581] RDX: ffff88001dad3798 RSI: 0000000000000000 RDI: ffff88001dad3798
[    1.112582] RBP: ffff88001dad37d8 R08: ffff88001e2908b8 R09: 000000000000000d
[    1.112583] R10: 000000000000000d R11: 000000000000000c R12: ffff88001dad3798
[    1.112583] R13: 0000000000000000 R14: 0000000000000000 R15: ffffea000078cb80
[    1.112585] FS:  0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000
[    1.112586] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    1.112588] CR2: 0000000000000000 CR3: 000000000180e000 CR4: 00000000000006e0
[    1.112593] Stack:
[    1.112595]  0000000000000000 0000000000000000 ffff88001dad37a8 ffff88001dad37a8
[    1.112597]  ffff88001dad37b8 ffff88001dad37b8 ffff88001e290840 0000000000000008
[    1.112599]  ffff88001dad3838 ffffffff812bc404 ffff88001dad3808 0000000481059f5e
[    1.112599] Call Trace:
[    1.112603]  [<ffffffff812bc404>] submit_bio+0xf7/0x136
[    1.112607]  [<ffffffff8114a1b9>] _submit_bh+0x104/0x12e
[    1.112610]  [<ffffffff8114a1f3>] submit_bh+0x10/0x12
[    1.112612]  [<ffffffff8114a4be>] block_read_full_page+0x24a/0x266
[    1.112614]  [<ffffffff8114be05>] ? I_BDEV+0xd/0xd
[    1.112618]  [<ffffffff812e8bd2>] ? debug_smp_processor_id+0x17/0x19
[    1.112621]  [<ffffffff810dd817>] ? __lru_cache_add+0x72/0x88
[    1.112623]  [<ffffffff8114c4e8>] ? blkdev_readpages+0x1f/0x1f
[    1.112625]  [<ffffffff8114c500>] blkdev_readpage+0x18/0x1a
[    1.112628]  [<ffffffff810d2f1f>] do_read_cache_page+0x97/0x16f
[    1.112630]  [<ffffffff810d3013>] read_cache_page+0x1c/0x1e
[    1.112633]  [<ffffffff812c98cf>] read_dev_sector+0x2d/0x87
[    1.112636]  [<ffffffff812cc283>] read_lba+0xb1/0x105
[    1.112638]  [<ffffffff812cc6e4>] ? find_valid_gpt+0x80/0x4d4
[    1.112640]  [<ffffffff812cc705>] find_valid_gpt+0xa1/0x4d4
[    1.112642]  [<ffffffff812dd430>] ? string.isra.6+0x3d/0xa2
[    1.112645]  [<ffffffff812ccbb4>] efi_partition+0x7c/0x364
[    1.112647]  [<ffffffff812de3b4>] ? vsnprintf+0x82/0x3a7
[    1.112649]  [<ffffffff812de77f>] ? snprintf+0x34/0x36
[    1.112651]  [<ffffffff812ca773>] check_partition+0x11e/0x1c3
[    1.112653]  [<ffffffff812c9e53>] rescan_partitions+0x98/0x271
[    1.112657]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112659]  [<ffffffff8114d32b>] __blkdev_get+0x1c7/0x3f6
[    1.112660]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112663]  [<ffffffff8114d5b8>] blkdev_get+0x5e/0x2a9
[    1.112666]  [<ffffffff8113513b>] ? unlock_new_inode+0x5c/0x61
[    1.112668]  [<ffffffff8114c3cb>] ? bdget+0x120/0x12f
[    1.112670]  [<ffffffff81330a9e>] ? put_device+0x17/0x19
[    1.112672]  [<ffffffff812c7e17>] add_disk+0x286/0x3f9
[    1.112676]  [<ffffffff8136ab9f>] sd_probe_async+0x106/0x19d
[    1.112678]  [<ffffffff81053a9c>] async_run_entry_fn+0x71/0x138
[    1.112681]  [<ffffffff8104d603>] process_one_work+0x1c7/0x36f
[    1.112683]  [<ffffffff8104e090>] worker_thread+0x28b/0x37f
[    1.112685]  [<ffffffff8104de05>] ? rescuer_thread+0x226/0x226
[    1.112687]  [<ffffffff810519a8>] kthread+0xdb/0xe3
[    1.112689]  [<ffffffff81480000>] ? __ww_mutex_lock_slowpath+0xcc/0x1c3
[    1.112691]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f
[    1.112693]  [<ffffffff8148226c>] ret_from_fork+0x7c/0xb0
[    1.112695]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f

Signed-off-by: Ming Lin <mlin@minggr.net>
cb984fd
@dongsupark dongsupark pushed a commit to dongsupark/linux that referenced this pull request Dec 29, 2014
Ming Lin block: fix panic in generic_make_request()
bio should be added to splits.
Fixed below panic.

[    1.112557] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    1.112563] IP: [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112564] PGD 0
[    1.112566] Oops: 0002 [#1] PREEMPT SMP
[    1.112568] Modules linked in:
[    1.112570] CPU: 3 PID: 530 Comm: kworker/u8:2 Not tainted 3.18.0-00033-ge76e0b3 #41
[    1.112571] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    1.112575] Workqueue: events_unbound async_run_entry_fn
[    1.112576] task: ffff88001d8eae90 ti: ffff88001dad0000 task.ti: ffff88001dad0000
[    1.112579] RIP: 0010:[<ffffffff812bc2d3>]  [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112579] RSP: 0000:ffff88001dad3798  EFLAGS: 00010246
[    1.112580] RAX: 0000000000000000 RBX: ffff88001d8eae90 RCX: 0000000000000008
[    1.112581] RDX: ffff88001dad3798 RSI: 0000000000000000 RDI: ffff88001dad3798
[    1.112582] RBP: ffff88001dad37d8 R08: ffff88001e2908b8 R09: 000000000000000d
[    1.112583] R10: 000000000000000d R11: 000000000000000c R12: ffff88001dad3798
[    1.112583] R13: 0000000000000000 R14: 0000000000000000 R15: ffffea000078cb80
[    1.112585] FS:  0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000
[    1.112586] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    1.112588] CR2: 0000000000000000 CR3: 000000000180e000 CR4: 00000000000006e0
[    1.112593] Stack:
[    1.112595]  0000000000000000 0000000000000000 ffff88001dad37a8 ffff88001dad37a8
[    1.112597]  ffff88001dad37b8 ffff88001dad37b8 ffff88001e290840 0000000000000008
[    1.112599]  ffff88001dad3838 ffffffff812bc404 ffff88001dad3808 0000000481059f5e
[    1.112599] Call Trace:
[    1.112603]  [<ffffffff812bc404>] submit_bio+0xf7/0x136
[    1.112607]  [<ffffffff8114a1b9>] _submit_bh+0x104/0x12e
[    1.112610]  [<ffffffff8114a1f3>] submit_bh+0x10/0x12
[    1.112612]  [<ffffffff8114a4be>] block_read_full_page+0x24a/0x266
[    1.112614]  [<ffffffff8114be05>] ? I_BDEV+0xd/0xd
[    1.112618]  [<ffffffff812e8bd2>] ? debug_smp_processor_id+0x17/0x19
[    1.112621]  [<ffffffff810dd817>] ? __lru_cache_add+0x72/0x88
[    1.112623]  [<ffffffff8114c4e8>] ? blkdev_readpages+0x1f/0x1f
[    1.112625]  [<ffffffff8114c500>] blkdev_readpage+0x18/0x1a
[    1.112628]  [<ffffffff810d2f1f>] do_read_cache_page+0x97/0x16f
[    1.112630]  [<ffffffff810d3013>] read_cache_page+0x1c/0x1e
[    1.112633]  [<ffffffff812c98cf>] read_dev_sector+0x2d/0x87
[    1.112636]  [<ffffffff812cc283>] read_lba+0xb1/0x105
[    1.112638]  [<ffffffff812cc6e4>] ? find_valid_gpt+0x80/0x4d4
[    1.112640]  [<ffffffff812cc705>] find_valid_gpt+0xa1/0x4d4
[    1.112642]  [<ffffffff812dd430>] ? string.isra.6+0x3d/0xa2
[    1.112645]  [<ffffffff812ccbb4>] efi_partition+0x7c/0x364
[    1.112647]  [<ffffffff812de3b4>] ? vsnprintf+0x82/0x3a7
[    1.112649]  [<ffffffff812de77f>] ? snprintf+0x34/0x36
[    1.112651]  [<ffffffff812ca773>] check_partition+0x11e/0x1c3
[    1.112653]  [<ffffffff812c9e53>] rescan_partitions+0x98/0x271
[    1.112657]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112659]  [<ffffffff8114d32b>] __blkdev_get+0x1c7/0x3f6
[    1.112660]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112663]  [<ffffffff8114d5b8>] blkdev_get+0x5e/0x2a9
[    1.112666]  [<ffffffff8113513b>] ? unlock_new_inode+0x5c/0x61
[    1.112668]  [<ffffffff8114c3cb>] ? bdget+0x120/0x12f
[    1.112670]  [<ffffffff81330a9e>] ? put_device+0x17/0x19
[    1.112672]  [<ffffffff812c7e17>] add_disk+0x286/0x3f9
[    1.112676]  [<ffffffff8136ab9f>] sd_probe_async+0x106/0x19d
[    1.112678]  [<ffffffff81053a9c>] async_run_entry_fn+0x71/0x138
[    1.112681]  [<ffffffff8104d603>] process_one_work+0x1c7/0x36f
[    1.112683]  [<ffffffff8104e090>] worker_thread+0x28b/0x37f
[    1.112685]  [<ffffffff8104de05>] ? rescuer_thread+0x226/0x226
[    1.112687]  [<ffffffff810519a8>] kthread+0xdb/0xe3
[    1.112689]  [<ffffffff81480000>] ? __ww_mutex_lock_slowpath+0xcc/0x1c3
[    1.112691]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f
[    1.112693]  [<ffffffff8148226c>] ret_from_fork+0x7c/0xb0
[    1.112695]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f

Signed-off-by: Ming Lin <mlin@minggr.net>
d159df4
@dongsupark dongsupark pushed a commit to dongsupark/linux that referenced this pull request Jan 12, 2015
Ming Lin block: fix panic in generic_make_request()
bio should be added to splits.
Fixed below panic.

[    1.112557] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    1.112563] IP: [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112564] PGD 0
[    1.112566] Oops: 0002 [#1] PREEMPT SMP
[    1.112568] Modules linked in:
[    1.112570] CPU: 3 PID: 530 Comm: kworker/u8:2 Not tainted 3.18.0-00033-ge76e0b3 #41
[    1.112571] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[    1.112575] Workqueue: events_unbound async_run_entry_fn
[    1.112576] task: ffff88001d8eae90 ti: ffff88001dad0000 task.ti: ffff88001dad0000
[    1.112579] RIP: 0010:[<ffffffff812bc2d3>]  [<ffffffff812bc2d3>] generic_make_request+0x63/0x9d
[    1.112579] RSP: 0000:ffff88001dad3798  EFLAGS: 00010246
[    1.112580] RAX: 0000000000000000 RBX: ffff88001d8eae90 RCX: 0000000000000008
[    1.112581] RDX: ffff88001dad3798 RSI: 0000000000000000 RDI: ffff88001dad3798
[    1.112582] RBP: ffff88001dad37d8 R08: ffff88001e2908b8 R09: 000000000000000d
[    1.112583] R10: 000000000000000d R11: 000000000000000c R12: ffff88001dad3798
[    1.112583] R13: 0000000000000000 R14: 0000000000000000 R15: ffffea000078cb80
[    1.112585] FS:  0000000000000000(0000) GS:ffff88001fd80000(0000) knlGS:0000000000000000
[    1.112586] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    1.112588] CR2: 0000000000000000 CR3: 000000000180e000 CR4: 00000000000006e0
[    1.112593] Stack:
[    1.112595]  0000000000000000 0000000000000000 ffff88001dad37a8 ffff88001dad37a8
[    1.112597]  ffff88001dad37b8 ffff88001dad37b8 ffff88001e290840 0000000000000008
[    1.112599]  ffff88001dad3838 ffffffff812bc404 ffff88001dad3808 0000000481059f5e
[    1.112599] Call Trace:
[    1.112603]  [<ffffffff812bc404>] submit_bio+0xf7/0x136
[    1.112607]  [<ffffffff8114a1b9>] _submit_bh+0x104/0x12e
[    1.112610]  [<ffffffff8114a1f3>] submit_bh+0x10/0x12
[    1.112612]  [<ffffffff8114a4be>] block_read_full_page+0x24a/0x266
[    1.112614]  [<ffffffff8114be05>] ? I_BDEV+0xd/0xd
[    1.112618]  [<ffffffff812e8bd2>] ? debug_smp_processor_id+0x17/0x19
[    1.112621]  [<ffffffff810dd817>] ? __lru_cache_add+0x72/0x88
[    1.112623]  [<ffffffff8114c4e8>] ? blkdev_readpages+0x1f/0x1f
[    1.112625]  [<ffffffff8114c500>] blkdev_readpage+0x18/0x1a
[    1.112628]  [<ffffffff810d2f1f>] do_read_cache_page+0x97/0x16f
[    1.112630]  [<ffffffff810d3013>] read_cache_page+0x1c/0x1e
[    1.112633]  [<ffffffff812c98cf>] read_dev_sector+0x2d/0x87
[    1.112636]  [<ffffffff812cc283>] read_lba+0xb1/0x105
[    1.112638]  [<ffffffff812cc6e4>] ? find_valid_gpt+0x80/0x4d4
[    1.112640]  [<ffffffff812cc705>] find_valid_gpt+0xa1/0x4d4
[    1.112642]  [<ffffffff812dd430>] ? string.isra.6+0x3d/0xa2
[    1.112645]  [<ffffffff812ccbb4>] efi_partition+0x7c/0x364
[    1.112647]  [<ffffffff812de3b4>] ? vsnprintf+0x82/0x3a7
[    1.112649]  [<ffffffff812de77f>] ? snprintf+0x34/0x36
[    1.112651]  [<ffffffff812ca773>] check_partition+0x11e/0x1c3
[    1.112653]  [<ffffffff812c9e53>] rescan_partitions+0x98/0x271
[    1.112657]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112659]  [<ffffffff8114d32b>] __blkdev_get+0x1c7/0x3f6
[    1.112660]  [<ffffffff814818c8>] ? _raw_spin_lock+0x18/0x37
[    1.112663]  [<ffffffff8114d5b8>] blkdev_get+0x5e/0x2a9
[    1.112666]  [<ffffffff8113513b>] ? unlock_new_inode+0x5c/0x61
[    1.112668]  [<ffffffff8114c3cb>] ? bdget+0x120/0x12f
[    1.112670]  [<ffffffff81330a9e>] ? put_device+0x17/0x19
[    1.112672]  [<ffffffff812c7e17>] add_disk+0x286/0x3f9
[    1.112676]  [<ffffffff8136ab9f>] sd_probe_async+0x106/0x19d
[    1.112678]  [<ffffffff81053a9c>] async_run_entry_fn+0x71/0x138
[    1.112681]  [<ffffffff8104d603>] process_one_work+0x1c7/0x36f
[    1.112683]  [<ffffffff8104e090>] worker_thread+0x28b/0x37f
[    1.112685]  [<ffffffff8104de05>] ? rescuer_thread+0x226/0x226
[    1.112687]  [<ffffffff810519a8>] kthread+0xdb/0xe3
[    1.112689]  [<ffffffff81480000>] ? __ww_mutex_lock_slowpath+0xcc/0x1c3
[    1.112691]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f
[    1.112693]  [<ffffffff8148226c>] ret_from_fork+0x7c/0xb0
[    1.112695]  [<ffffffff810518cd>] ? kthread_create_on_node+0x17f/0x17f

Signed-off-by: Ming Lin <mlin@minggr.net>
aed8463
@kdave kdave pushed a commit to kdave/btrfs-devel that referenced this pull request Feb 16, 2015
@fdmanana fdmanana Btrfs: scrub, fix sleep in atomic context
My previous patch "Btrfs: fix scrub race leading to use-after-free"
introduced the possibility to sleep in an atomic context, which happens
when the scrub_lock mutex is held at the time scrub_pending_bio_dec()
is called - this function can be called under an atomic context.
Chris ran into this in a debug kernel which gave the following trace:

[ 1928.950319] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:621
[ 1928.967334] in_atomic(): 1, irqs_disabled(): 0, pid: 149670, name: fsstress
[ 1928.981324] INFO: lockdep is turned off.
[ 1928.989244] CPU: 24 PID: 149670 Comm: fsstress Tainted: G        W     3.19.0-rc7-mason+ #41
[ 1929.006418] Hardware name: ZTSYSTEMS Echo Ridge T4  /A9DRPF-10D, BIOS 1.07 05/10/2012
[ 1929.022207]  ffffffff81a22cf8 ffff881076e03b78 ffffffff816b8dd9 ffff881076e03b78
[ 1929.037267]  ffff880d8e828710 ffff881076e03ba8 ffffffff810856c4 ffff881076e03bc8
[ 1929.052315]  0000000000000000 000000000000026d ffffffff81a22cf8 ffff881076e03bd8
[ 1929.067381] Call Trace:
[ 1929.072344]  <IRQ>  [<ffffffff816b8dd9>] dump_stack+0x4f/0x6e
[ 1929.083968]  [<ffffffff810856c4>] ___might_sleep+0x174/0x230
[ 1929.095352]  [<ffffffff810857d2>] __might_sleep+0x52/0x90
[ 1929.106223]  [<ffffffff816bb68f>] mutex_lock_nested+0x2f/0x3b0
[ 1929.117951]  [<ffffffff810ab37d>] ? trace_hardirqs_on+0xd/0x10
[ 1929.129708]  [<ffffffffa05dc838>] scrub_pending_bio_dec+0x38/0x70 [btrfs]
[ 1929.143370]  [<ffffffffa05dd0e0>] scrub_parity_bio_endio+0x50/0x70 [btrfs]
[ 1929.157191]  [<ffffffff812fa603>] bio_endio+0x53/0xa0
[ 1929.167382]  [<ffffffffa05f96bc>] rbio_orig_end_io+0x7c/0xa0 [btrfs]
[ 1929.180161]  [<ffffffffa05f97ba>] raid_write_parity_end_io+0x5a/0x80 [btrfs]
[ 1929.194318]  [<ffffffff812fa603>] bio_endio+0x53/0xa0
[ 1929.204496]  [<ffffffff8130401b>] blk_update_request+0x1eb/0x450
[ 1929.216569]  [<ffffffff81096e58>] ? trigger_load_balance+0x78/0x500
[ 1929.229176]  [<ffffffff8144c74d>] scsi_end_request+0x3d/0x1f0
[ 1929.240740]  [<ffffffff8144ccac>] scsi_io_completion+0xac/0x5b0
[ 1929.252654]  [<ffffffff81441c50>] scsi_finish_command+0xf0/0x150
[ 1929.264725]  [<ffffffff8144d317>] scsi_softirq_done+0x147/0x170
[ 1929.276635]  [<ffffffff8130ace6>] blk_done_softirq+0x86/0xa0
[ 1929.288014]  [<ffffffff8105d92e>] __do_softirq+0xde/0x600
[ 1929.298885]  [<ffffffff8105df6d>] irq_exit+0xbd/0xd0
(...)

Fix this by using a reference count on the scrub context structure
instead of locking the scrub_lock mutex.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
f55985f
@nirobin nirobin pushed a commit to nirobin/linux that referenced this pull request Jun 25, 2015
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
a88afa0
@krzk krzk pushed a commit to krzk/linux that referenced this pull request Sep 14, 2015
Russell King ARM: uaccess: fix undefined instruction on ARMv7M/noMMU
The use of get_domain() in copy_thread() results in an oops on
ARMv7M/noMMU systems.  The thread cpu_domain value is only used when
CONFIG_CPU_USE_DOMAINS is enabled, so there's no need to save the
value in copy_thread() except when this is enabled, and this option
will never be enabled on these platforms.

Unhandled exception: IPSR = 00000006 LR = fffffff1
CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-next-20150909-00001-gb8ec5ad #41
Hardware name: NXP LPC18xx/43xx (Device Tree)
task: 2823fbe0 ti: 2823c000 task.ti: 2823c000
PC is at copy_thread+0x18/0x92
LR is at copy_thread+0x19/0x92
pc : [<2800a46e>]    lr : [<2800a46f>]    psr: 4100000b
sp : 2823df00  ip : 00000000  fp : 287c81c0
r10: 00000000  r9 : 00800300  r8 : 287c8000
r7 : 287c8000  r6 : 2818908d  r5 : 00000000  r4 : 287ca000
r3 : 00000000  r2 : 00000000  r1 : fffffff0  r0 : 287ca048
xPSR: 4100000b

Reported-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
af4cb25
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Sep 15, 2015
mmotm auto import linux-next
GIT d3f67beceb16295ea830272634ee322252f3d7c3

commit af4cb25df93d2e7a97d65db2bfacaa4400988dea
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Wed Sep 9 21:19:49 2015 +0100

    ARM: uaccess: fix undefined instruction on ARMv7M/noMMU
    
    The use of get_domain() in copy_thread() results in an oops on
    ARMv7M/noMMU systems.  The thread cpu_domain value is only used when
    CONFIG_CPU_USE_DOMAINS is enabled, so there's no need to save the
    value in copy_thread() except when this is enabled, and this option
    will never be enabled on these platforms.
    
    Unhandled exception: IPSR = 00000006 LR = fffffff1
    CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-next-20150909-00001-gb8ec5ad #41
    Hardware name: NXP LPC18xx/43xx (Device Tree)
    task: 2823fbe0 ti: 2823c000 task.ti: 2823c000
    PC is at copy_thread+0x18/0x92
    LR is at copy_thread+0x19/0x92
    pc : [<2800a46e>]    lr : [<2800a46f>]    psr: 4100000b
    sp : 2823df00  ip : 00000000  fp : 287c81c0
    r10: 00000000  r9 : 00800300  r8 : 287c8000
    r7 : 287c8000  r6 : 2818908d  r5 : 00000000  r4 : 287ca000
    r3 : 00000000  r2 : 00000000  r1 : fffffff0  r0 : 287ca048
    xPSR: 4100000b
    
    Reported-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 296254f3223d201f2aa53f5f717eedfdc63f3db8
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Sep 7 00:30:06 2015 +0100

    ARM: uaccess: remove unneeded uaccess_save_and_disable macro
    
    This macro is never referenced, remove it.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 39dc53deff30d9b239ac36cfeb0ef2022d03a449
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Sep 7 00:29:15 2015 +0100

    ARM: swpan: fix nwfpe for uaccess changes
    
    NWFPE needs to access userspace to check whether the next instruction
    is another FP instruction.  Allow userspace access for this read.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 8edb1554f7c2eb73cf70c9856aec01e786b9bcf9
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Tue Sep 8 23:05:49 2015 -0700

    mpt3sas: Fix unprotected list lookup in v4.3-rc0 changes
    
    This patch adds the missing mpt3sas_get_sdev_by_addr() protected
    lookup usage in mpt3sas_transport_port_add() to avoid a NULL pointer
    dereference when &ioc->sas_device_list or &ioc->sas_device_init_list
    changes from below without a proper sas_device_get(sas_device)
    reference held.
    
    Also, use the protected mpt3sas_get_sdev_by_handle() lookup within
    _scsih_block_io_device() as well.
    
    Reported-by: Sreekanth Reddy <sreekanth.reddy@avagotech.com>
    Reported-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
    Cc: Calvin Owens <calvinowens@fb.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit f53de1e9a4aaf8cbe08845da6f7ff26a078ac507
Author: Phil Sutter <phil@nwl.cc>
Date:   Wed Sep 9 14:20:56 2015 +0200

    net: ipv6: use common fib_default_rule_pref
    
    This switches IPv6 policy routing to use the shared
    fib_default_rule_pref() function of IPv4 and DECnet. It is also used in
    multicast routing for IPv4 as well as IPv6.
    
    The motivation for this patch is a complaint about iproute2 behaving
    inconsistent between IPv4 and IPv6 when adding policy rules: Formerly,
    IPv6 rules were assigned a fixed priority of 0x3FFF whereas for IPv4 the
    assigned priority value was decreased with each rule added.
    
    Since then all users of the default_pref field have been converted to
    assign the generic function fib_default_rule_pref(), fib_nl_newrule()
    may just use it directly instead. Therefore get rid of the function
    pointer altogether and make fib_default_rule_pref() static, as it's not
    used outside fib_rules.c anymore.
    
    Signed-off-by: Phil Sutter <phil@nwl.cc>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 444c5f92ed152346aef0952316e0ea855129846c
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Wed Sep 9 11:24:29 2015 +0200

    net: ethoc: Remove unnecessary #ifdef CONFIG_OF
    
    For !CONFIG_OF of_get_property() is defined to always return NULL. Thus
    there's no need to protect the call to of_get_property() with #ifdef
    CONFIG_OF.
    
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 03679a14739a0d4c14b52ba65a69ff553bfba73b
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Sep 8 20:06:41 2015 -0700

    net: dsa: bcm_sf2: Fix 64-bits register writes
    
    The macro to write 64-bits quantities to the 32-bits register swapped
    the value and offsets arguments, we want to preserve the ordering of the
    arguments with respect to how writel() is implemented for instance:
    value first, offset/base second.
    
    Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 687f07156b0c99205c21aa4e2986564046d342fe
Author: Alexei Starovoitov <ast@plumgrid.com>
Date:   Tue Sep 8 13:40:01 2015 -0700

    bpf: fix out of bounds access in verifier log
    
    when the verifier log is enabled the print_bpf_insn() is doing
    bpf_alu_string[BPF_OP(insn->code) >> 4]
    and
    bpf_jmp_string[BPF_OP(insn->code) >> 4]
    where BPF_OP is a 4-bit instruction opcode.
    Malformed insns can cause out of bounds access.
    Fix it by sizing arrays appropriately.
    
    The bug was found by clang address sanitizer with libfuzzer.
    
    Reported-by: Yonghong Song <yhs@plumgrid.com>
    Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6b9ea5a64ed5eeb3f68f2e6fcce0ed1179801d1e
Author: Roopa Prabhu <roopa@cumulusnetworks.com>
Date:   Tue Sep 8 10:53:04 2015 -0700

    ipv6: fix multipath route replace error recovery
    
    Problem:
    The ecmp route replace support for ipv6 in the kernel, deletes the
    existing ecmp route too early, ie when it installs the first nexthop.
    If there is an error in installing the subsequent nexthops, its too late
    to recover the already deleted existing route leaving the fib
    in an inconsistent state.
    
    This patch reduces the possibility of this by doing the following:
    a) Changes the existing multipath route add code to a two stage process:
      build rt6_infos + insert them
    	ip6_route_add rt6_info creation code is moved into
    	ip6_route_info_create.
    b) This ensures that most errors are caught during building rt6_infos
      and we fail early
    c) Separates multipath add and del code. Because add needs the special
      two stage mode in a) and delete essentially does not care.
    d) In any event if the code fails during inserting a route again, a
      warning is printed (This should be unlikely)
    
    Before the patch:
    $ip -6 route show
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024
    
    /* Try replacing the route with a duplicate nexthop */
    $ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
    fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
    swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
    RTNETLINK answers: File exists
    
    $ip -6 route show
    /* previously added ecmp route 3000:1000:1000:1000::2 dissappears from
     * kernel */
    
    After the patch:
    $ip -6 route show
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024
    
    /* Try replacing the route with a duplicate nexthop */
    $ip -6 route change 3000:1000:1000:1000::2/128 nexthop via
    fe80::202:ff:fe00:b dev swp49s0 nexthop via fe80::202:ff:fe00:d dev
    swp49s1 nexthop via fe80::202:ff:fe00:d dev swp49s1
    RTNETLINK answers: File exists
    
    $ip -6 route show
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:b dev swp49s0 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:d dev swp49s1 metric 1024
    3000:1000:1000:1000::2 via fe80::202:ff:fe00:f dev swp49s2 metric 1024
    
    Fixes: 27596472473a ("ipv6: fix ECMP route replacement")
    Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
    Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 592867bfabe2fcb449393ba7eb0de4f972a08c63
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Tue Sep 8 18:00:09 2015 +0200

    ebpf: fix fd refcount leaks related to maps in bpf syscall
    
    We may already have gotten a proper fd struct through fdget(), so
    whenever we return at the end of an map operation, we need to call
    fdput(). However, each map operation from syscall side first probes
    CHECK_ATTR() to verify that unused fields in the bpf_attr union are
    zero.
    
    In case of malformed input, we return with error, but the lookup to
    the map_fd was already performed at that time, so that we return
    without an corresponding fdput(). Fix it by performing an fdget()
    only right before bpf_map_get(). The fdget() invocation on maps in
    the verifier is not affected.
    
    Fixes: db20fd2b0108 ("bpf: add lookup/update/delete/iterate methods to BPF maps")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@plumgrid.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 74e98eb085889b0d2d4908f59f6e00026063014f
Author: Sasha Levin <sasha.levin@oracle.com>
Date:   Tue Sep 8 10:53:40 2015 -0400

    RDS: verify the underlying transport exists before creating a connection
    
    There was no verification that an underlying transport exists when creating
    a connection, this would cause dereferencing a NULL ptr.
    
    It might happen on sockets that weren't properly bound before attempting to
    send a message, which will cause a NULL ptr deref:
    
    [135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
    [135546.051270] Modules linked in:
    [135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527
    [135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000
    [135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194)
    [135546.055666] RSP: 0018:ffff8800bc70fab0  EFLAGS: 00010202
    [135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000
    [135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038
    [135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000
    [135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000
    [135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000
    [135546.061668] FS:  00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000
    [135546.062836] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0
    [135546.064723] Stack:
    [135546.065048]  ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008
    [135546.066247]  0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342
    [135546.067438]  1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00
    [135546.068629] Call Trace:
    [135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134)
    [135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298)
    [135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278)
    [135546.071981] rds_sendmsg (net/rds/send.c:1058)
    [135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38)
    [135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298)
    [135546.074577] ? rds_send_drop_to (net/rds/send.c:976)
    [135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795)
    [135546.076349] ? __might_fault (mm/memory.c:3795)
    [135546.077179] ? rds_send_drop_to (net/rds/send.c:976)
    [135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620)
    [135546.078856] SYSC_sendto (net/socket.c:1657)
    [135546.079596] ? SYSC_connect (net/socket.c:1628)
    [135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926)
    [135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674)
    [135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
    [135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16)
    [135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16)
    [135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
    [135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1
    
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1d5d48523900a4b0f25d6b52f1a93c84bd671186
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Tue Sep 8 14:25:14 2015 +0100

    xen-netback: require fewer guest Rx slots when not using GSO
    
    Commit f48da8b14d04ca87ffcffe68829afd45f926ec6a (xen-netback: fix
    unlimited guest Rx internal queue and carrier flapping) introduced a
    regression.
    
    The PV frontend in IPXE only places 4 requests on the guest Rx ring.
    Since netback required at least (MAX_SKB_FRAGS + 1) slots, IPXE could
    not receive any packets.
    
    a) If GSO is not enabled on the VIF, fewer guest Rx slots are required
       for the largest possible packet.  Calculate the required slots
       based on the maximum GSO size or the MTU.
    
       This calculation of the number of required slots relies on
       1650d5455bd2 (xen-netback: always fully coalesce guest Rx packets)
       which present in 4.0-rc1 and later.
    
    b) Reduce the Rx stall detection to checking for at least one
       available Rx request.  This is fine since we're predominately
       concerned with detecting interfaces which are down and thus have
       zero available Rx requests.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Reviewed-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2a485cf7db2815ca0d1510143d9126c4475aab39
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date:   Tue Sep 8 16:25:40 2015 +0530

    cxgb4: Fix for write-combining stats configuration
    
    The write-combining configuration register SGE_STAT_CFG_A needs to
    be configured after FW initializes the adapter, else FW will reset
    the configuration
    
    Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fd1754fb8afbd9cf4ea279d533414aa6577b7e60
Author: Hariprasad Shenai <hariprasad@chelsio.com>
Date:   Tue Sep 8 16:25:39 2015 +0530

    cxgb4: Fix tx flit calculation
    
    In commit 0aac3f56d4a63f04 ("cxgb4: Add comment for calculate tx flits
    and sge length code") introduced a regression where tx flit calculation
    is going wrong, which can lead to data corruption, hang, stall and
    write-combining failure. Fixing it.
    
    Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d43cefcd68bbc9a67b2c0efe38eb9cf6b5170fe8
Author: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
Date:   Tue Sep 8 18:15:41 2015 +0900

    net: eth: altera: Fix the initial device operstate
    
    Call netif_carrier_off() prior to register_netdev(), otherwise
    userspace can see incorrect link state.
    
    Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 23453f7f4e6c2ce271e6eff48523f42e34bb6c79
Author: Loic Poulain <loic.poulain@intel.com>
Date:   Wed Sep 9 21:04:15 2015 +0200

    Bluetooth: hci_intel: Enable IRQ wake capability
    
    We need to explicitly enable the IRQ wakeup mode to let the controller
    wake the system from sleep states (like suspend-to-ram).
    PM suspend/resume callbacks now call the generic intel device PM
    functions after enabling/disabling IRQ wake.
    
    Signed-off-by: Loic Poulain <loic.poulain@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

commit b444aeceb66fb24267bc8cf5386d6d9671775540
Author: Loic Poulain <loic.poulain@intel.com>
Date:   Wed Sep 9 19:08:02 2015 +0200

    Bluetooth: hci_intel: Give priority to LPM packets
    
    Change the way to insert LPM packets into the txq.
    Use skb_queue_head instead of skb_queue_tail to always prioritise LPM
    packets over potential tx queue content.
    
    Signed-off-by: Loic Poulain <loic.poulain@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

commit 02cc2ccfe771677db3cd40a71837e1467ebc839a
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Wed Apr 22 21:28:04 2015 -0400

    Revert "Hexagon: fix signal.c compile error"
    
    This reverts commit f3f601c1d2728f02544cfd143eaa82e5398b3e9b.
    
    UAPI headers cannot use "uapi/" in their paths by design -- when they're
    installed, they do not have the uapi/ prefix.  Otherwise doing so breaks
    userland badly.
    
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>
    Signed-off-by: Richard Kuo <rkuo@codeaurora.org>

commit c099b55a6fa6f9ec2f26105c76df462d7c7c7d5b
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Wed Sep 9 13:46:21 2015 +0200

    drm/core: Do not call drm_framebuffer_remove internally during teardown.
    
    This may cause issues because encoders are already destroyed so removing
    active primaries may use freed memory. Instead free the fb directly,
    ignoring refcount.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit fcc9021343212f6a4a52a085b3d383ab29a9ac0a
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Wed Sep 9 14:21:30 2015 +0200

    drm: move drm_class into drm_sysfs.c
    
    Right now, drm_sysfs_create() returns the newly allocated "struct class"
    to the caller (which is drm_core_init()), which then has to set the
    global variable 'drm_class'. During cleanup, though, we call
    drm_sysfs_destroy() which implicitly uses the global 'drm_class'. This is
    confusing, as ownership of the global 'drm_class' is non-obvious.
    
    This patch changes drm_sysfs_create() to drm_sysfs_init() and makes it
    initialize the 'drm_class' object directly, rather than returning it.
    This way, both drm_sysfs_init() and drm_sysfs_destroy() work in a similar
    fashion and manage the global drm class.
    
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 26b91ae4732be89228d207c76827071c6aecc4d8
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Wed Sep 9 14:21:29 2015 +0200

    drm: simplify drm_sysfs_destroy() via IS_ERR_OR_NULL()
    
    Simplify `foo == NULL || IS_ERR(foo)` via IS_ERR_OR_NULL(). This is
    pretty commonly used all over the kernel, especially for debugfs/sysfs
    cleanup paths.
    
    Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 3a818d350f6b5ad542175ab1f71c027787ce952e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 7 18:22:58 2015 +0300

    drm: Make drm_av_sync_delay() 'mode' argument const
    
    drm_av_sync_delay() doesn't change the passed in mode, so make it const.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 9e5a3b529e8419db1dd2b32c86a1fb42fc07347d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 7 18:22:57 2015 +0300

    drm: Remove the 'mode' argument from drm_select_eld()
    
    drm_select_eld() doesn't look at the passed in mode, so don't pass it
    in.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 85f8fcd619d161d65c53b067e2d99590c0d7bbad
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Sep 7 18:22:56 2015 +0300

    drm: Make some modes const when iterating through them
    
    valid_inferred_mode() don't change the modes over which it iterates,
    so make the iterator const.
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit b0ba362c611f6cba047a298655eeffea560a3b81
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Sep 7 14:25:01 2015 +0200

    leds:lp55xx: Correct Kconfig dependency for f/w user helper
    
    The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
    tries to address the firmware file handling with user helper, but it
    sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK.  Since the
    wrong option was enabled, the system got a regression -- it suffers
    from the unexpected long delays for non-present firmware files.
    
    This patch corrects the Kconfig dependency to the right one,
    CONFIG_FW_LOADER_USER_HELPER.  This doesn't change the fallback
    behavior but only enables UMH when needed.
    
    Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
    Fixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')
    Cc: <stable@vger.kernel.org> # v4.2+
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>

commit e5342eeb718461dbeaf879071684d30fe7d557ba
Author: Muhammad Falak R Wani <falakreyaz@gmail.com>
Date:   Mon Sep 7 21:58:29 2015 +0530

    leds: leds-ipaq-micro: Fix coding style issues
    
    Spaces at the starting of a line are removed, indentation using
    tab, instead of space. Also, line width of more than 80 characters
    is also taken care of.
    Two warnings are left alone to aid better readability.
    
    Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
    Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>

commit 99a5a605d0bcb7fcee9c9f390ce953f6eaee1d4f
Author: Jacek Anaszewski <j.anaszewski@samsung.com>
Date:   Mon Sep 7 17:06:05 2015 +0200

    leds: leds-ipaq-micro: Add LEDS_CLASS dependency
    
    Fix missing Kconfig LEDS_CLASS dependency.
    
    Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

commit acd29f7b22262d9e848393b9b6ae13eb42d22514
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 8 14:17:13 2015 +0100

    drm/i915: Limit the number of loops for reading a split 64bit register
    
    In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
    reads. Due to the nature of the registers we try to read in this manner,
    they may increment between the two instruction (e.g. a timestamp
    counter). To keep the result accurate, we repeat the read if we detect
    an overflow (i.e. the upper value varies). However, some hardware is just
    plain flaky and may endless loop as the the upper 32bits are not stable.
    Just give up after a couple of tries and report whatever we read last.
    
    v2: Use the most recent values when erring out on an unstable register.
    
    Reported-by: russianneuromancer@ya.ru
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Michał Winiarski <michal.winiarski@intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Jani Nikula <jani.nikula@linux.intel.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit ab5ec3eb3fdd24b4febaf2ebd2c10d4a18194111
Author: David Disseldorp <ddiss@suse.de>
Date:   Fri Sep 4 01:39:56 2015 +0200

    target: use stringify.h instead of own definition
    
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Acked-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 4c48204d8bb6786964e48e599f7332520744dd06
Author: Andy Grover <agrover@redhat.com>
Date:   Thu Sep 3 16:03:44 2015 -0700

    target/user: Fix UFLAG_UNKNOWN_OP handling
    
    Calling transport_generic_request_failure() from here causes list
    corruption. We should be using target_complete_cmd() instead.
    
    Which we do in all other cases, so the UNKNOWN_OP case can become just
    another member of the big else/if chain in tcmu_handle_completion().
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 5fde682e2b0206d553737ab8fd169c35b5479bcf
Author: Andy Grover <agrover@redhat.com>
Date:   Thu Sep 3 16:03:43 2015 -0700

    target: Remove no-op conditional
    
    This does nothing, and there are many other places where
    transport_cmd_check_stop_to_fabric()'s retval is not checked>, If we
    wanted to check it here, we should probably do it those other places too.
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 9db98bff2973f9019710a66db2dd7aa89df9b87f
Author: Andy Grover <agrover@redhat.com>
Date:   Thu Sep 3 16:03:42 2015 -0700

    target/user: Remove unused variable
    
    We don't use it any more.
    
    Signed-off-by: Andy Grover <agrover@redhat.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit fec6fdd2ecdc385dbfa7e4973052afb06dfb48d8
Author: Roland Dreier <roland@purestorage.com>
Date:   Tue Sep 8 06:14:18 2015 -0700

    target: Fix max_cmd_sn increment w/o cmdsn mutex regressions
    
    Current for-next iscsi target is broken:
    
    commit 109e2381749c1cfd94a0d22b2b54142539024973
    Author: Roland Dreier <roland@purestorage.com>
    Date:   Thu Jul 23 14:53:32 2015 -0700
    
        target: Drop iSCSI use of mutex around max_cmd_sn increment
    
    This patch fixes incorrect pr_debug() + atomic_inc_return() usage
    within iscsit_increment_maxcmdsn() code.
    
    Also fix funny iscsit_determine_maxcmdsn() usage and update
    iscsi_target_do_tx_login_io() code.
    
    Reported-by: Sagi Grimberg <sagig@mellanox.com>
    Cc: Sagi Grimberg <sagig@mellanox.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Cc: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 042a424559e2a2b3664f07e4988ceb9fc1cebc4a
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Thu Sep 3 06:30:45 2015 +0000

    target: Attach EXTENDED_COPY local I/O descriptors to xcopy_pt_sess
    
    This patch is a >= v4.1 regression bug-fix where control CDB
    emulation logic in commit 38b57f82 now expects a se_cmd->se_sess
    pointer to exist when determining T10-PI support is to be exposed
    for initiator host ports.
    
    To address this bug, go ahead and add locally generated se_cmd
    descriptors for copy-offload block-copy to it's own stand-alone
    se_session nexus, while the parent EXTENDED_COPY se_cmd descriptor
    remains associated with it's originating se_cmd->se_sess nexus.
    
    Note a valid se_cmd->se_sess is also required for future support
    of WRITE_INSERT and READ_STRIP software emulation when submitting
    backend I/O to se_device that exposes T10-PI suport.
    
    Reported-by: Alex Gorbachev <ag@iss-integration.com>
    Tested-by: Alex Gorbachev <ag@iss-integration.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Doug Gilbert <dgilbert@interlog.com>
    Cc: <stable@vger.kernel.org> # v4.1+
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

commit 7845989cb4b3da1db903918c844fccb9817d34a0
Author: Kolmakov Dmitriy <kolmakov.dmitriy@huawei.com>
Date:   Mon Sep 7 09:05:48 2015 +0000

    net: tipc: fix stall during bclink wakeup procedure
    
    If an attempt to wake up users of broadcast link is made when there is
    no enough place in send queue than it may hang up inside the
    tipc_sk_rcv() function since the loop breaks only after the wake up
    queue becomes empty. This can lead to complete CPU stall with the
    following message generated by RCU:
    
    INFO: rcu_sched self-detected stall on CPU { 0}  (t=2101 jiffies
    					g=54225 c=54224 q=11465)
    Task dump for CPU 0:
    tpch            R  running task        0 39949  39948 0x0000000a
     ffffffff818536c0 ffff88181fa037a0 ffffffff8106a4be 0000000000000000
     ffffffff818536c0 ffff88181fa037c0 ffffffff8106d8a8 ffff88181fa03800
     0000000000000001 ffff88181fa037f0 ffffffff81094a50 ffff88181fa15680
    Call Trace:
     <IRQ>  [<ffffffff8106a4be>] sched_show_task+0xae/0x120
     [<ffffffff8106d8a8>] dump_cpu_task+0x38/0x40
     [<ffffffff81094a50>] rcu_dump_cpu_stacks+0x90/0xd0
     [<ffffffff81097c3b>] rcu_check_callbacks+0x3eb/0x6e0
     [<ffffffff8106e53f>] ? account_system_time+0x7f/0x170
     [<ffffffff81099e64>] update_process_times+0x34/0x60
     [<ffffffff810a84d1>] tick_sched_handle.isra.18+0x31/0x40
     [<ffffffff810a851c>] tick_sched_timer+0x3c/0x70
     [<ffffffff8109a43d>] __run_hrtimer.isra.34+0x3d/0xc0
     [<ffffffff8109aa95>] hrtimer_interrupt+0xc5/0x1e0
     [<ffffffff81030d52>] ? native_smp_send_reschedule+0x42/0x60
     [<ffffffff81032f04>] local_apic_timer_interrupt+0x34/0x60
     [<ffffffff810335bc>] smp_apic_timer_interrupt+0x3c/0x60
     [<ffffffff8165a3fb>] apic_timer_interrupt+0x6b/0x70
     [<ffffffff81659129>] ? _raw_spin_unlock_irqrestore+0x9/0x10
     [<ffffffff8107eb9f>] __wake_up_sync_key+0x4f/0x60
     [<ffffffffa313ddd1>] tipc_write_space+0x31/0x40 [tipc]
     [<ffffffffa313dadf>] filter_rcv+0x31f/0x520 [tipc]
     [<ffffffffa313d699>] ? tipc_sk_lookup+0xc9/0x110 [tipc]
     [<ffffffff81659259>] ? _raw_spin_lock_bh+0x19/0x30
     [<ffffffffa314122c>] tipc_sk_rcv+0x2dc/0x3e0 [tipc]
     [<ffffffffa312e7ff>] tipc_bclink_wakeup_users+0x2f/0x40 [tipc]
     [<ffffffffa313ce26>] tipc_node_unlock+0x186/0x190 [tipc]
     [<ffffffff81597c1c>] ? kfree_skb+0x2c/0x40
     [<ffffffffa313475c>] tipc_rcv+0x2ac/0x8c0 [tipc]
     [<ffffffffa312ff58>] tipc_l2_rcv_msg+0x38/0x50 [tipc]
     [<ffffffff815a76d3>] __netif_receive_skb_core+0x5a3/0x950
     [<ffffffff815a98d3>] __netif_receive_skb+0x13/0x60
     [<ffffffff815a993e>] netif_receive_skb_internal+0x1e/0x90
     [<ffffffff815aa138>] napi_gro_receive+0x78/0xa0
     [<ffffffffa07f93f4>] tg3_poll_work+0xc54/0xf40 [tg3]
     [<ffffffff81597c8c>] ? consume_skb+0x2c/0x40
     [<ffffffffa07f9721>] tg3_poll_msix+0x41/0x160 [tg3]
     [<ffffffff815ab0f2>] net_rx_action+0xe2/0x290
     [<ffffffff8104b92a>] __do_softirq+0xda/0x1f0
     [<ffffffff8104bc26>] irq_exit+0x76/0xa0
     [<ffffffff81004355>] do_IRQ+0x55/0xf0
     [<ffffffff8165a12b>] common_interrupt+0x6b/0x6b
     <EOI>
    
    The issue occurs only when tipc_sk_rcv() is used to wake up postponed
    senders:
    
    	tipc_bclink_wakeup_users()
    		// wakeupq - is a queue which consists of special
    		// 		 messages with SOCK_WAKEUP type.
    		tipc_sk_rcv(wakeupq)
    			...
    			while (skb_queue_len(inputq)) {
    				filter_rcv(skb)
    					// Here the type of message is checked
    					// and if it is SOCK_WAKEUP then
    					// it tries to wake up a sender.
    					tipc_write_space(sk)
    						wake_up_interruptible_sync_poll()
    			}
    
    After the sender thread is woke up it can gather control and perform
    an attempt to send a message. But if there is no enough place in send
    queue it will call link_schedule_user() function which puts a message
    of type SOCK_WAKEUP to the wakeup queue and put the sender to sleep.
    Thus the size of the queue actually is not changed and the while()
    loop never exits.
    
    The approach I proposed is to wake up only senders for which there is
    enough place in send queue so the described issue can't occur.
    Moreover the same approach is already used to wake up senders on
    unicast links.
    
    I have got into the issue on our product code but to reproduce the
    issue I changed a benchmark test application (from
    tipcutils/demos/benchmark) to perform the following scenario:
    	1. Run 64 instances of test application (nodes). It can be done
    	   on the one physical machine.
    	2. Each application connects to all other using TIPC sockets in
    	   RDM mode.
    	3. When setup is done all nodes start simultaneously send
    	   broadcast messages.
    	4. Everything hangs up.
    
    The issue is reproducible only when a congestion on broadcast link
    occurs. For example, when there are only 8 nodes it works fine since
    congestion doesn't occur. Send queue limit is 40 in my case (I use a
    critical importance level) and when 64 nodes send a message at the
    same moment a congestion occurs every time.
    
    Signed-off-by: Dmitry S Kolmakov <kolmakov.dmitriy@huawei.com>
    Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
    Acked-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7b9018738e43c7c7693632174c69fde83b8edc07
Author: Barry Song <Baohua.Song@csr.com>
Date:   Mon Sep 7 03:15:20 2015 +0000

    dm9000: fix a typo
    
    Signed-off-by: Barry Song <Baohua.Song@csr.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7a577f013d6745c800a11a2911ddc9a3214e7f09
Author: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date:   Sat Sep 5 21:49:41 2015 -0400

    net: bridge: remove unnecessary switchdev include
    
    Remove the unnecessary switchdev.h include from br_netlink.c.
    
    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Acked-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bf361ad38165939049a2649b1a0078f3268d4bd1
Author: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date:   Sat Sep 5 21:27:57 2015 -0400

    net: bridge: check __vlan_vid_del for error
    
    Since __vlan_del can return an error code, change its inner function
    __vlan_vid_del to return an eventual error from switchdev_port_obj_del.
    
    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Acked-by: Jiri Pirko <jiri@resnulli.us>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 39797a279d62972cd914ef580fdfacb13e508bf8
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sat Sep 5 13:07:27 2015 -0700

    net: dsa: bcm_sf2: Fix ageing conditions and operation
    
    The comparison check between cur_hw_state and hw_state is currently
    invalid because cur_hw_state is right shifted by G_MISTP_SHIFT, while
    hw_state is not, so we end-up comparing bits 2:0 with bits 7:5, which is
    going to cause an additional aging to occur. Fix this by not shifting
    cur_hw_state while reading it, but instead, mask the value with the
    appropriately shitfted bitmask.
    
    The other problem with the fast-ageing process is that we did not set
    the EN_AGE_DYNAMIC bit to request the ageing to occur for dynamically
    learned MAC addresses. Finally, write back 0 to the FAST_AGE_CTRL
    register to avoid leaving spurious bits sets from one operation to the
    other.
    
    Fixes: 12f460f23423 ("net: dsa: bcm_sf2: add HW bridging support")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 953ba9ff77f3d08635712eaeffb218d46889b58a
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Tue Sep 8 18:41:03 2015 +0200

    cpufreq-dt: add suspend frequency support
    
    Add suspend frequency support and if needed set it to
    the frequency obtained from the suspend opp (can be defined
    using opp-v2 bindings and is optional).
    
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 201f3716575781b83259ed026845a213c2355035
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Tue Sep 8 18:41:02 2015 +0200

    cpufreq: allow cpufreq_generic_suspend() to work without suspend frequency
    
    Some cpufreq drivers may set suspend frequency only for
    selected setups but still would like to use the generic
    suspend handler.  Thus don't treat !policy->suspend_freq
    condition as an incorrect one.
    
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 4eafbd15b6c84cd3f6c76022c8a6c27f7cc076e1
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date:   Tue Sep 8 18:41:01 2015 +0200

    PM / OPP: add dev_pm_opp_get_suspend_opp() helper
    
    Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
    
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit f33b77408a91d4427374010897b90af678dc47be
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Sep 8 19:06:03 2015 +0200

    staging: board: Migrate away from __pm_genpd_name_add_device()
    
    The named genpd APIs are deprecated. Hence convert the board staging
    code from using genpd names to DT node paths.
    
    For now this supports PM domains with "#power-domain-cells = <0>" only.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit d70e22d5bcf700a53881acad71a6c669be6eec93
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Thu Jul 16 16:56:19 2015 +0530

    hexagon/time: Migrate to new 'set-state' interface
    
    Migrate hexagon driver to the new 'set-state' interface provided by
    clockevents core, the earlier 'set-mode' interface is marked obsolete
    now.
    
    This also enables us to implement callbacks for new states of clockevent
    devices, for example: ONESHOT_STOPPED.
    
    We weren't doing anything in the ->set_mode() callback. So, this patch
    doesn't provide any set-state callbacks.
    
    Cc: linux-hexagon@vger.kernel.org
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Richard Kuo <rkuo@codeaurora.org>

commit 12f0721c5a70408e86257c5c99605cf743cd44c6
Author: Aristeu Rozanski <aris@redhat.com>
Date:   Fri Jun 12 15:08:17 2015 -0400

    sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell
    
    dimm_dev_type has been incorrectly determined in sb_edac. This patch fixes it
    for Ivy Bridge and Haswell only since nothing like exists for Sandy Bridge.
    We tested this patch in multiple systems matching the results with the
    installed memory modules.
    
    Acked-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Aristeu Rozanski <aris@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 7179385afef252cd3f52c0a06cc0c405ae6d66bc
Author: Aristeu Rozanski <aris@redhat.com>
Date:   Fri Jun 12 09:44:52 2015 -0400

    sb_edac: look harder for DDRIO on Haswell systems
    
    In case the memory banks are populated so the first channel isn't used, the
    DDRIO PCI device won't be visible and it won't be possible to determine the
    memory type.
    
    Acked-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Aristeu Rozanski <aris@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit fd2e11f4c5e1e0dace8750d9bfc9092590271b2b
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 20 05:03:35 2015 -0300

    [media] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
    
    Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
    This removes the knowledge about vmas and mmap_sem locking from exynos
    driver. Also it fixes a problem that the function has been mapping user
    provided address without holding mmap_sem.
    
    Acked-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit cc8cec342df4a11c3de1c5753035b33e68eb8a3e
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:50 2015 -0300

    [media] media: vb2: Remove unused functions
    
    Conversion to the use of pinned pfns made some functions unused. Remove
    them. Also there's no need to lock mmap_sem in __buf_prepare() anymore.
    
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 89f9e2e3c3844f6cdbb484562b219b8fbb03847b
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:49 2015 -0300

    [media] media: vb2: Convert vb2_dc_get_userptr() to use frame vector
    
    Convert vb2_dc_get_userptr() to use frame vector infrastructure. When we
    are doing that there's no need to allocate page array and some code can
    be simplified.
    
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit aa0a3233be99517b94a79be057f013d3a8b8f6e5
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:48 2015 -0300

    [media] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector
    
    Convert vb2_vmalloc_get_userptr() to use frame vector infrastructure.
    When we are doing that there's no need to allocate page array and some
    code can be simplified.
    
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 408d6ff8ea724b4f5e28f994ddb07d4b98f5cb10
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:47 2015 -0300

    [media] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector
    
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 01311b437053a404be4d835bc7d9df7e2a04e08f
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:46 2015 -0300

    [media] vb2: Provide helpers for mapping virtual addresses
    
    Provide simple helper functions to map virtual address range into an
    array of pfns / pages.
    
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 2487aed4ceef2711855e9c3459737ea6ed18606a
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:45 2015 -0300

    [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
    
    Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
    hand made mapping of virtual address to physical address. Also the
    function leaked page reference from get_user_pages() so fix that by
    properly release the reference when omap_vout_buffer_release() is
    called.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    [hans.verkuil@cisco.com: remove unused variable]
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 8bb8ff42d80b58ffa908c2b6b2ecb32d7627c374
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:44 2015 -0300

    [media] mm: Provide new get_vaddr_frames() helper
    
    Provide new function get_vaddr_frames().  This function maps virtual
    addresses from given start and fills given array with page frame numbers of
    the corresponding pages. If given start belongs to a normal vma, the function
    grabs reference to each of the pages to pin them in memory. If start
    belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
    must make sure pfns aren't reused for anything else while he is using
    them.
    
    This function is created for various drivers to simplify handling of
    their buffers.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit d5d64b172da5d45cda8999d4e2e663ae7b5edae0
Author: Jan Kara <jack@suse.cz>
Date:   Mon Jul 13 11:55:43 2015 -0300

    [media] vb2: Push mmap_sem down to memops
    
    Currently vb2 core acquires mmap_sem just around call to
    __qbuf_userptr(). However since commit f035eb4e976ef5 (videobuf2: fix
    lockdep warning) it isn't necessary to acquire it so early as we no
    longer have to drop queue mutex before acquiring mmap_sem. So push
    acquisition of mmap_sem down into .get_userptr memop so that the
    semaphore is acquired for a shorter time and it is clearer what it is
    needed for.
    
    Note that we also need mmap_sem in .put_userptr memop since that ends up
    calling vb2_put_vma() which calls vma->vm_ops->close() which should be
    called with mmap_sem held. However we didn't hold mmap_sem in some code
    paths anyway (e.g. when called via vb2_ioctl_reqbufs() ->
    __vb2_queue_free() -> vb2_dma_sg_put_userptr()) and getting mmap_sem in
    put_userptr() introduces a lock inversion with queue->mmap_lock in the
    above mentioned call path.
    
    Luckily this whole locking mess will get resolved once we convert
    videobuf2 core to the new mm helper which avoids the need for mmap_sem
    in .put_userptr memop altogether.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

commit 5b902d6f97f573fde911338e5d943e6b07fac7f9
Author: Julien Grall <julien.grall@citrix.com>
Date:   Thu Sep 3 23:59:50 2015 +0100

    device property: Don't overwrite addr when failing in device_get_mac_address
    
    The function device_get_mac_address is trying different property names
    in order to get the mac address. To check the return value, the variable
    addr (which contain the buffer pass by the caller) will be re-used. This
    means that if the previous property is not found, the next property will
    be read using a NULL buffer.
    
    Therefore it's only possible to retrieve the mac if node contains a
    property "mac-address". Fix it by using a temporary buffer for the
    return value.
    
    This has been introduced by commit 4c96b7dc0d393f12c17e0d81db15aa4a820a6ab3
    "Add a matching set of device_ functions for determining mac/phy"
    
    Signed-off-by: Julien Grall <julien.grall@citrix.com>
    Cc: Jeremy Linton <jeremy.linton@arm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fcb0bb6aab256288a4e0a8650d26e4096ec30319
Author: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
Date:   Tue Sep 1 17:05:33 2015 +0300

    usbnet: Fix a race between usbnet_stop() and the BH
    
    The race may happen when a device (e.g. YOTA 4G LTE Modem) is
    unplugged while the system is downloading a large file from the Net.
    
    Hardware breakpoints and Kprobes with delays were used to confirm that
    the race does actually happen.
    
    The race is on skb_queue ('next' pointer) between usbnet_stop()
    and rx_complete(), which, in turn, calls usbnet_bh().
    
    Here is a part of the call stack with the code where the changes to the
    queue happen. The line numbers are for the kernel 4.1.0:
    
    *0 __skb_unlink (skbuff.h:1517)
        prev->next = next;
    *1 defer_bh (usbnet.c:430)
        spin_lock_irqsave(&list->lock, flags);
        old_state = entry->state;
        entry->state = state;
        __skb_unlink(skb, list);
        spin_unlock(&list->lock);
        spin_lock(&dev->done.lock);
        __skb_queue_tail(&dev->done, skb);
        if (dev->done.qlen == 1)
            tasklet_schedule(&dev->bh);
        spin_unlock_irqrestore(&dev->done.lock, flags);
    *2 rx_complete (usbnet.c:640)
        state = defer_bh(dev, skb, &dev->rxq, state);
    
    At the same time, the following code repeatedly checks if the queue is
    empty and reads these values concurrently with the above changes:
    
    *0  usbnet_terminate_urbs (usbnet.c:765)
        /* maybe wait for deletions to finish. */
        while (!skb_queue_empty(&dev->rxq)
            && !skb_queue_empty(&dev->txq)
            && !skb_queue_empty(&dev->done)) {
                schedule_timeout(msecs_to_jiffies(UNLINK_TIMEOUT_MS));
                set_current_state(TASK_UNINTERRUPTIBLE);
                netif_dbg(dev, ifdown, dev->net,
                      "waited for %d urb completions\n", temp);
        }
    *1  usbnet_stop (usbnet.c:806)
        if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
            usbnet_terminate_urbs(dev);
    
    As a result, it is possible, for example, that the skb is removed from
    dev->rxq by __skb_unlink() before the check
    "!skb_queue_empty(&dev->rxq)" in usbnet_terminate_urbs() is made. It is
    also possible in this case that the skb is added to dev->done queue
    after "!skb_queue_empty(&dev->done)" is checked. So
    usbnet_terminate_urbs() may stop waiting and return while dev->done
    queue still has an item.
    
    Locking in defer_bh() and usbnet_terminate_urbs() was revisited to avoid
    this race.
    
    Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
    Reviewed-by: Bjørn Mork <bjorn@mork.no>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8dbd263de1cba18100a9fb30fed606e6d7939b9d
Author: Yan, Zheng <zyan@redhat.com>
Date:   Mon Sep 7 15:46:24 2015 +0800

    ceph: improve readahead for file holes
    
    When readahead encounters file holes, osd reply returns error -ENOENT,
    finish_read() skips adding pages to the the page cache. So readahead
    does not work for file holes. The fix is adding zero pages to the
    page cache when -ENOENT is returned.
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit b9abfcf80021b9ab52e24e733df3558eb6cdcc96
Author: Yan, Zheng <zyan@redhat.com>
Date:   Mon Sep 7 11:35:01 2015 +0800

    ceph: get inode size for each append write
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 5f1c79a71766ba656762636936edf708089bdb14
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Sep 2 11:37:09 2015 +0300

    libceph: check data_len in ->alloc_msg()
    
    Only ->alloc_msg() should check data_len of the incoming message
    against the preallocated ceph_msg, doing it in the messenger is not
    right.  The contract is that either ->alloc_msg() returns a ceph_msg
    which will fit all of the portions of the incoming message, or it
    returns NULL and possibly sets skip, signaling whether NULL is due to
    an -ENOMEM.  ->alloc_msg() should be the only place where we make the
    skip/no-skip decision.
    
    I stumbled upon this while looking at con/osd ref counting.  Right now,
    if we get a non-extent message with a larger data portion than we are
    prepared for, ->alloc_msg() returns a ceph_msg, and then, when we skip
    it in the messenger, we don't put the con/osd ref acquired in
    ceph_con_in_msg_alloc() (which is normally put in process_message()),
    so this also fixes a memory leak.
    
    An existing BUG_ON in ceph_msg_data_cursor_init() ensures we don't
    corrupt random memory should a buggy ->alloc_msg() return an unfit
    ceph_msg.
    
    While at it, I changed the "unknown tid" dout() to a pr_warn() to make
    sure all skips are seen and unified format strings.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 8b9558aab853e98ba6e3fee0dd8545544966958c
Author: Yan, Zheng <zyan@redhat.com>
Date:   Tue Sep 1 17:19:38 2015 +0800

    libceph: use keepalive2 to verify the mon session is alive
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit d194cd1dd1be61249b08e5461ae8a9c05d1072c9
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Aug 31 18:22:10 2015 +0300

    rbd: plug rbd_dev->header.object_prefix memory leak
    
    Need to free object_prefix when rbd_dev_v2_snap_context() fails, but
    only if this is the first time we are reading in the header.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>

commit 3ebe138ac642a195c7f2efdb918f464734421fd6
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Mon Aug 31 15:21:39 2015 +0300

    rbd: fix double free on rbd_dev->header_name
    
    If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
    is freed twice: once in rbd_dev_probe_parent() and then in its caller
    rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
    handle parent images).
    
    rbd_dev_probe_parent() is responsible for probing the parent, so it
    shouldn't muck with clone's fields.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>

commit 6dd74e44dc1df85f125982a8d6591bc4a76c9f5d
Author: Yan, Zheng <zyan@redhat.com>
Date:   Fri Aug 28 17:59:35 2015 +0800

    libceph: set 'exists' flag for newly up osd
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>
    Reviewed-by: Sage Weil <sage@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 5fdb1389e1399d6801a8c5d10952ef4153039fb2
Author: Jianpeng Ma <jianpeng.ma@intel.com>
Date:   Tue Aug 18 10:30:38 2015 +0800

    ceph: cleanup use of ceph_msg_get
    
    Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit e36d571d70c7f46b20c28d81025fd5fc044a8e22
Author: Jianpeng Ma <jianpeng.ma@intel.com>
Date:   Tue Aug 18 10:25:35 2015 +0800

    ceph: no need to get parent inode in ceph_open
    
    parent inode is needed in creating new inode case.  For ceph_open,
    the target inode already exists.
    
    Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit a43137f7b0f1467cf3005b6ff6574d978642d247
Author: Jianpeng Ma <jianpeng.ma@intel.com>
Date:   Tue Aug 18 10:23:50 2015 +0800

    ceph: remove the useless judgement
    
    err != 0 is already handled. So skip this.
    
    Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 1550d34e5626a20a2e12c73bdc1e6e217a0ba897
Author: Brad Hubbard <bhubbard@redhat.com>
Date:   Tue Aug 18 10:18:53 2015 +0800

    ceph: remove redundant test of head->safe and silence static analysis warnings
    
    Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 23078637e05460428f803be7d0f46908df8a970a
Author: Yan, Zheng <zyan@redhat.com>
Date:   Mon Jul 20 10:14:06 2015 +0800

    ceph: fix queuing inode to mdsdir's snaprealm
    
    During MDS failovers, MClientSnap message may cause kclient to move
    some inodes from root directory's snaprealm to mdsdir's snaprealm
    and queue snapshots for these inodes. For a FS has never created any
    snapshot, both root directory's snaprealm and mdsdir's snaprealm
    share the same snapshot contexts (both are ceph_empty_snapc). This
    confuses ceph_put_wrbuffer_cap_refs(), make it unable to distinguish
    snapshot buffers from head buffers.
    
    The fix is do not use ceph_empty_snapc as snaprealm's cached context.
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 6893162215d7bf08a4273247ec1fc7dedee5135c
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Fri Jul 3 15:44:41 2015 +0300

    libceph: rename con_work() to ceph_con_workfn()
    
    Even though it's static, con_work(), being a work func, shows up in
    various stacktraces a lot.  Prefix it with ceph_.
    
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit d920ff6fc7c1ec3d7bd80432bff5575c0ebe426c
Author: Benoît Canet <benoit.canet@nodalink.com>
Date:   Thu Jun 25 21:02:57 2015 +0200

    libceph: Avoid holding the zero page on ceph_msgr_slab_init errors
    
    ceph_msgr_slab_init may fail due to a temporary ENOMEM.
    
    Delay a bit the initialization of zero_page in ceph_msgr_init and
    reorder its cleanup in _ceph_msgr_exit so it's done in reverse
    order of setup.
    
    BUG_ON() will not suffer to be postponed in case it is triggered.
    
    Signed-off-by: Benoît Canet <benoit.canet@nodalink.com>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit b79b23682a1649f30960fb5bd920ba46c89a1b14
Author: Nicholas Krause <xerofoify@gmail.com>
Date:   Sun Jul 5 06:34:05 2015 +0000

    libceph: remove the unused macro AES_KEY_SIZE
    
    This removes the no longer used macro AES_KEY_SIZE as no functions use
    this macro anymore and thus this macro can be removed due it no longer
    being required.
    
    Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit a341d4df87487ae68189e0be869c39a2b0cb9aaa
Author: Yan, Zheng <zyan@redhat.com>
Date:   Wed Jul 1 17:03:23 2015 +0800

    ceph: invalidate dirty pages after forced umount
    
    After forced umount, ceph_writepages_start() skips flushing dirty
    pages. To make sure inode's reference count get dropped to zero,
    we need to invalidate dirty pages.
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 48fec5d0a504dfbb302cb1dd24ebb0b82a46cce9
Author: Yan, Zheng <zyan@redhat.com>
Date:   Wed Jul 1 16:27:46 2015 +0800

    ceph: EIO all operations after forced umount
    
    This patch makes try_get_cap_refs() and __do_request() check
    if the file system was forced umount, and return -EIO if it was.
    This patch also adds a helper function to drops dirty caps and
    wakes up blocking operation.
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>

commit 68ec2a2a24815c0ee359b1327b60a276cd2280d8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Aug 27 17:23:30 2015 +0300

    drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests
    
    When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
    supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
    when we continue to poll for the completion of the request.
    
    v2: Don't assume DP_AUX_I2C_WRITE is 0 even though it is, to make the
        code more obvious to the casual reader (Jani)
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    [danvet: Resolve conflict due to changed context.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit f993406182b3ffad7c53ffc180b65e2b7e3d8986
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Aug 27 17:23:29 2015 +0300

    drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
    
    A address-only I2C_WRITE can't be replied with a short i2c ack, but I
    suppose it could be replied with an i2c defer. So the code should be
    prepared for an address-only I2C_WRITE_STATUS_UPDATE.
    
    Cc: Thierry Reding <thierry.reding@gmail.com>
    Cc: "Terje Bergström" <tbergstrom@nvidia.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 1f75b29d3fc9abb06b095860f9312f8190e6015b
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Aug 27 17:23:28 2015 +0300

    drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
    
    When we get an i2c defer or short ack for i2c-over-aux write we need
    to switch to WRITE_STATUS_UPDATE to poll for the completion of the
    original request.
    
    Looks like radeon doesn't do anything special with the request type,
    so hopefully just treating it the same as a i2c write is enough.
    
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Christian König" <christian.koenig@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

commit c1e74122fb029d30b66d9364122aef50265354aa
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Aug 27 17:23:27 2015 +0300

    drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
    
    When we get an i2c defer or short ack for i2c-over-aux write we need
    to switch to WRITE_STATUS_UPDATE to poll for the completion of the
    original request.
    
    i915 doesn't try to interpret wht request type apart from separating
    reads from writes, and so we should be able to treat this the same as
    a normal i2c write.
    
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 2b712be72fddc74ac12c2857af24a20a93d9e9c0
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Aug 27 17:23:26 2015 +0300

    drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
    
    Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
    spec.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit fa5d8f13afb8618dc83aa4039360bc19b06ac50f
Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date:   Mon Sep 7 20:06:57 2015 +0530

    tile: fix build failure
    
    When building with allmodconfig the build was failing with the error:
    
    arch/tile/kernel/usb.c:70:1: warning: data definition has no type or storage class [enabled by default]
    arch/tile/kernel/usb.c:70:1: error: type defaults to 'int' in declaration of 'arch_initcall' [-Werror=implicit-int]
    arch/tile/kernel/usb.c:70:1: warning: parameter names (without types) in function declaration [enabled by default]
    arch/tile/kernel/usb.c:63:19: warning: 'tilegx_usb_init' defined but not used [-Wunused-function]
    
    Include linux/module.h to resolve the build failure.
    
    Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
    Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>

commit ecfb4598512a7c3e21df2941db58c10461583bb9
Author: Tang Yuantian <Yuantian.Tang@freescale.com>
Date:   Mon Sep 7 16:23:16 2015 +0800

    ahci: added a new driver for supporting Freescale AHCI sata
    
    Currently Freescale QorIQ series SATA is supported by ahci_platform
    driver. Some SoC specific settings have been put in uboot. So whether
    SATA works or not heavily depends on uboot.
    This patch will add a new driver to support QorIQ sata which removes
    the dependency on any other boot loader.
    Freescale QorIQ series sata, like ls1021a ls2085a ls1043a, is
    compatible with serial ATA 3.0 and AHCI 1.3 specification.
    
    Signed-off-by: Yuantian Tang <Yuantian.Tang@freescale.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit 437dd8c3c20fa750a9db2e6b39b5e2ff7d01c79e
Author: Tang Yuantian <Yuantian.Tang@freescale.com>
Date:   Mon Sep 7 16:23:15 2015 +0800

    devicetree:bindings: add devicetree bindings for Freescale AHCI
    
    adds bindings for Freescale QorIQ …
2e4adca
@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Oct 25, 2015
@vsyrjala vsyrjala x86: dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL dev
Commit 6894258 ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}")
broke drivers that pass NULL as the device for dma_alloc.
Fix things by moving the ISA DMA fallback dev assignment earlier.

A quick search suggest that Meelis Roos has hit this with sb16, and I
caught it with smsc-ircc2. Here's the oops I got:

BUG: unable to handle kernel NULL pointer dereference at 000001c0
IP: [<c100840d>] arch_dma_alloc_attrs+0xd/0x80
*pde = 00000000
Oops: 0000 [#1] PREEMPT
Modules linked in: smsc_ircc2(+) irda crc_ccitt sch_fq_codel binfmt_misc joydev mousedev ipw2100 libipw snd_intel8x0 lib80211 snd_ac97_codec cfg80211 iTCO_wdt ac97_bus evdev psmouse firewire_ohci snd_pcm input_leds firewire_core crc_itu_t intel_agp 8139too mii led_class snd_timer snd intel_gtt soundcore lpc_ich mfd_core i2c_i801 i2c_core agpgart rng_core rfkill
CPU: 0 PID: 2135 Comm: modprobe Not tainted 4.2.0-dma-oops+ #41
Hardware name: FUJITSU SIEMENS LIFEBOOK S6010/FJNB159, BIOS Version 1.07  10/28/2002
task: f39ba7c0 ti: f39d4000 task.ti: f39d4000
EIP: 0060:[<c100840d>] EFLAGS: 00010246 CPU: 0
EIP is at arch_dma_alloc_attrs+0xd/0x80
EAX: f39d5d7c EBX: 00000000 ECX: 000080d0 EDX: f39d5d78
ESI: f39ce800 EDI: c16325a0 EBP: f39d5d30 ESP: f39d5d2c
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
CR0: 8005003b CR2: 000001c0 CR3: 339a8000 CR4: 000006d0
Stack:
 00000400 f39d5dbc f88ca8bb f39d5d88 00000002 00000000 00000400 000002e8
 00000003 00000003 00000003 c1e8e600 00000404 00000407 00000003 00000003
 f39ceda0 f39cee34 000002e8 000080d0 00000000 c108c0b4 00000000 ffffffff
Call Trace:
 [<f88ca8bb>] smsc_ircc_open+0x5eb/0x8f0 [smsc_ircc2]
 [<c108c0b4>] ? vprintk_default+0x34/0x40
 [<c1101fde>] ? printk+0x16/0x18
 [<f88f9656>] ? smsc_superio_flat+0xcd/0x103 [smsc_ircc2]
 [<f88f9676>] smsc_superio_flat+0xed/0x103 [smsc_ircc2]
 [<f88f9b77>] smsc_ircc_init+0x43f/0x8c8 [smsc_ircc2]
 [<c107964b>] ? trace_hardirqs_on+0xb/0x10
 [<c1000413>] ? do_one_initcall+0x73/0x1b0
 [<f88f9738>] ? smsc_superio_paged+0xac/0xac [smsc_ircc2]
 [<c100041e>] do_one_initcall+0x7e/0x1b0
 [<f88f9738>] ? smsc_superio_paged+0xac/0xac [smsc_ircc2]
 [<c1093412>] ? rcu_read_lock_sched_held+0x62/0x90
 [<c1149915>] ? kmem_cache_alloc_trace+0xe5/0x2b0
 [<c11392a5>] ? __vunmap+0xb5/0x100
 [<c11020cc>] ? do_init_module+0x21/0x1b5
 [<c11020fa>] do_init_module+0x4f/0x1b5
 [<c10b91b9>] load_module+0x1c19/0x2040
 [<c10b9741>] SyS_finit_module+0x61/0x80
 [<c148ba17>] sysenter_do_call+0x12/0x12
Code: 3b 4d e4 77 e7 42 83 c0 14 39 fa 75 be 90 83 c4 10 31 c0 5b 5e 5f 5d c3 66 90 66 90 66 90 55 89 e5 53 3e 8d 74 26 00 8b 18 8b 0a <8b> 9b c0 01 00 00 85 db 75 29 f6 c1 01 75 2c 83 e1 f8 89 0a 8b
EIP: [<c100840d>] arch_dma_alloc_attrs+0xd/0x80 SS:ESP 0068:f39d5d2c
CR2: 00000000000001c0
---[ end trace fbf24ded74a1e64a ]---

Cc: Christoph Hellwig <hch@lst.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Cc: Meelis Roos <mroos@linux.ee>
References: http://permalink.gmane.org/gmane.linux.kernel/2048042
Fixes: 6894258 ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
f2ac67a
@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Dec 21, 2015
@mchehab mchehab [media] media-entity: don't sleep at media_device_register_entity()
media_device_register_entity() is protected by a spin_lock.

Calling ida_pre_get() with GFP_KERNEL may put it to sleep,
with is a bad idea and causes this warning:

[ 8812.397195] BUG: sleeping function called from invalid context at mm/slub.c:1287
[ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe
[ 8812.397207] INFO: lockdep is turned off.
[ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: G    B           4.4.0-rc2+ #41
[ 8812.397218] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 8812.397222]  0000000000000000 ffff880314c77268 ffffffff818f8ba7 ffff8803b17dde00
[ 8812.397232]  ffff880314c77290 ffffffff811c2ee5 ffff8803b17dde00 ffffffff8284dbc9
[ 8812.397241]  0000000000000507 ffff880314c772d0 ffffffff811c30d5 0000000041b58ab3
[ 8812.397250] Call Trace:
[ 8812.397258]  [<ffffffff818f8ba7>] dump_stack+0x4b/0x64
[ 8812.397265]  [<ffffffff811c2ee5>] ___might_sleep+0x245/0x3a0
[ 8812.397270]  [<ffffffff811c30d5>] __might_sleep+0x95/0x1a0
[ 8812.397276]  [<ffffffff818fd083>] ? ida_pre_get+0x113/0x250
[ 8812.397282]  [<ffffffff8153bb77>] kmem_cache_alloc+0x197/0x250
[ 8812.397288]  [<ffffffff818fd083>] ida_pre_get+0x113/0x250
[ 8812.397293]  [<ffffffff818fd265>] ida_simple_get+0xa5/0x170
[ 8812.397298]  [<ffffffff818fd1c0>] ? ida_pre_get+0x250/0x250
[ 8812.397306]  [<ffffffffa07382d1>] media_device_register_entity+0x171/0x420 [media]
[ 8812.397318]  [<ffffffffa129e76f>] v4l2_device_register_subdev+0x34f/0x640 [videodev]
[ 8812.397324]  [<ffffffffa0768dea>] v4l2_i2c_new_subdev_board+0x12a/0x250 [v4l2_common]
[ 8812.397330]  [<ffffffffa0768fe7>] v4l2_i2c_new_subdev+0xd7/0x110 [v4l2_common]
[ 8812.397337]  [<ffffffffa0768f10>] ? v4l2_i2c_new_subdev_board+0x250/0x250 [v4l2_common]
[ 8812.397347]  [<ffffffffa13d2f76>] au0828_card_analog_fe_setup+0x2e6/0x3f0 [au0828]
[ 8812.397352]  [<ffffffff814450cc>] ? power_down+0xc4/0xc4
[ 8812.397361]  [<ffffffffa13d2c90>] ? au0828_tuner_callback+0x160/0x160 [au0828]
[ 8812.397370]  [<ffffffffa13d319f>] au0828_card_setup+0x11f/0x340 [au0828]
[ 8812.397378]  [<ffffffffa13d3080>] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 [au0828]
[ 8812.397384]  [<ffffffff812a575b>] ? msleep+0x7b/0xc0
[ 8812.397393]  [<ffffffffa13d0d79>] au0828_usb_probe+0x679/0xcf0 [au0828]
[ 8812.397399]  [<ffffffff81d7619d>] usb_probe_interface+0x45d/0x940
[ 8812.397406]  [<ffffffff81ca7004>] driver_probe_device+0x454/0xd90
[ 8812.397411]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397417]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397422]  [<ffffffff81ca7a61>] __driver_attach+0x121/0x160
[ 8812.397427]  [<ffffffff81ca141f>] bus_for_each_dev+0x11f/0x1a0
[ 8812.397433]  [<ffffffff81ca1300>] ? subsys_dev_iter_exit+0x10/0x10
[ 8812.397439]  [<ffffffff822917d7>] ? _raw_spin_unlock+0x27/0x40
[ 8812.397445]  [<ffffffff81ca5d4d>] driver_attach+0x3d/0x50
[ 8812.397450]  [<ffffffff81ca5039>] bus_add_driver+0x4c9/0x770
[ 8812.397456]  [<ffffffff81ca944c>] driver_register+0x18c/0x3b0
[ 8812.397462]  [<ffffffff8124c952>] ? __raw_spin_lock_init+0x32/0x100
[ 8812.397468]  [<ffffffff81d71e58>] usb_register_driver+0x1f8/0x440
[ 8812.397473]  [<ffffffffa0208000>] ? 0xffffffffa0208000
[ 8812.397481]  [<ffffffffa02080b7>] au0828_init+0xb7/0x1000 [au0828]
[ 8812.397486]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
[ 8812.397492]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
[ 8812.397497]  [<ffffffff8123bbf6>] ? trace_hardirqs_on_caller+0x16/0x590
[ 8812.397502]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397507]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397512]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397517]  [<ffffffff815407f7>] ? __asan_register_globals+0x87/0xa0
[ 8812.397524]  [<ffffffff814454e5>] do_init_module+0x1d0/0x5a4
[ 8812.397530]  [<ffffffff812ed7e8>] load_module+0x6648/0x9d70
[ 8812.397535]  [<ffffffff812e4b70>] ? symbol_put_addr+0x50/0x50
[ 8812.397546]  [<ffffffff812e71a0>] ? module_frob_arch_sections+0x20/0x20
[ 8812.397552]  [<ffffffff8158e950>] ? open_exec+0x50/0x50
[ 8812.397559]  [<ffffffff811648db>] ? ns_capable+0x5b/0xd0
[ 8812.397565]  [<ffffffff812f1208>] SyS_finit_module+0x108/0x130
[ 8812.397571]  [<ffffffff812f1100>] ? SyS_init_module+0x1f0/0x1f0
[ 8812.397576]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
[ 8812.397582]  [<ffffffff82292236>] entry_SYSCALL_64_fastpath+0x16/0x7a

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
cdf0ebd
@martinezjavier martinezjavier pushed a commit to martinezjavier/linux that referenced this pull request Dec 29, 2015
@mchehab mchehab [media] media-entity: don't sleep at media_device_register_entity()
media_device_register_entity() is protected by a spin_lock.

Calling ida_pre_get() with GFP_KERNEL may put it to sleep,
with is a bad idea and causes this warning:

[ 8812.397195] BUG: sleeping function called from invalid context at mm/slub.c:1287
[ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe
[ 8812.397207] INFO: lockdep is turned off.
[ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: G    B           4.4.0-rc2+ #41
[ 8812.397218] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 8812.397222]  0000000000000000 ffff880314c77268 ffffffff818f8ba7 ffff8803b17dde00
[ 8812.397232]  ffff880314c77290 ffffffff811c2ee5 ffff8803b17dde00 ffffffff8284dbc9
[ 8812.397241]  0000000000000507 ffff880314c772d0 ffffffff811c30d5 0000000041b58ab3
[ 8812.397250] Call Trace:
[ 8812.397258]  [<ffffffff818f8ba7>] dump_stack+0x4b/0x64
[ 8812.397265]  [<ffffffff811c2ee5>] ___might_sleep+0x245/0x3a0
[ 8812.397270]  [<ffffffff811c30d5>] __might_sleep+0x95/0x1a0
[ 8812.397276]  [<ffffffff818fd083>] ? ida_pre_get+0x113/0x250
[ 8812.397282]  [<ffffffff8153bb77>] kmem_cache_alloc+0x197/0x250
[ 8812.397288]  [<ffffffff818fd083>] ida_pre_get+0x113/0x250
[ 8812.397293]  [<ffffffff818fd265>] ida_simple_get+0xa5/0x170
[ 8812.397298]  [<ffffffff818fd1c0>] ? ida_pre_get+0x250/0x250
[ 8812.397306]  [<ffffffffa07382d1>] media_device_register_entity+0x171/0x420 [media]
[ 8812.397318]  [<ffffffffa129e76f>] v4l2_device_register_subdev+0x34f/0x640 [videodev]
[ 8812.397324]  [<ffffffffa0768dea>] v4l2_i2c_new_subdev_board+0x12a/0x250 [v4l2_common]
[ 8812.397330]  [<ffffffffa0768fe7>] v4l2_i2c_new_subdev+0xd7/0x110 [v4l2_common]
[ 8812.397337]  [<ffffffffa0768f10>] ? v4l2_i2c_new_subdev_board+0x250/0x250 [v4l2_common]
[ 8812.397347]  [<ffffffffa13d2f76>] au0828_card_analog_fe_setup+0x2e6/0x3f0 [au0828]
[ 8812.397352]  [<ffffffff814450cc>] ? power_down+0xc4/0xc4
[ 8812.397361]  [<ffffffffa13d2c90>] ? au0828_tuner_callback+0x160/0x160 [au0828]
[ 8812.397370]  [<ffffffffa13d319f>] au0828_card_setup+0x11f/0x340 [au0828]
[ 8812.397378]  [<ffffffffa13d3080>] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 [au0828]
[ 8812.397384]  [<ffffffff812a575b>] ? msleep+0x7b/0xc0
[ 8812.397393]  [<ffffffffa13d0d79>] au0828_usb_probe+0x679/0xcf0 [au0828]
[ 8812.397399]  [<ffffffff81d7619d>] usb_probe_interface+0x45d/0x940
[ 8812.397406]  [<ffffffff81ca7004>] driver_probe_device+0x454/0xd90
[ 8812.397411]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397417]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397422]  [<ffffffff81ca7a61>] __driver_attach+0x121/0x160
[ 8812.397427]  [<ffffffff81ca141f>] bus_for_each_dev+0x11f/0x1a0
[ 8812.397433]  [<ffffffff81ca1300>] ? subsys_dev_iter_exit+0x10/0x10
[ 8812.397439]  [<ffffffff822917d7>] ? _raw_spin_unlock+0x27/0x40
[ 8812.397445]  [<ffffffff81ca5d4d>] driver_attach+0x3d/0x50
[ 8812.397450]  [<ffffffff81ca5039>] bus_add_driver+0x4c9/0x770
[ 8812.397456]  [<ffffffff81ca944c>] driver_register+0x18c/0x3b0
[ 8812.397462]  [<ffffffff8124c952>] ? __raw_spin_lock_init+0x32/0x100
[ 8812.397468]  [<ffffffff81d71e58>] usb_register_driver+0x1f8/0x440
[ 8812.397473]  [<ffffffffa0208000>] ? 0xffffffffa0208000
[ 8812.397481]  [<ffffffffa02080b7>] au0828_init+0xb7/0x1000 [au0828]
[ 8812.397486]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
[ 8812.397492]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
[ 8812.397497]  [<ffffffff8123bbf6>] ? trace_hardirqs_on_caller+0x16/0x590
[ 8812.397502]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397507]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397512]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397517]  [<ffffffff815407f7>] ? __asan_register_globals+0x87/0xa0
[ 8812.397524]  [<ffffffff814454e5>] do_init_module+0x1d0/0x5a4
[ 8812.397530]  [<ffffffff812ed7e8>] load_module+0x6648/0x9d70
[ 8812.397535]  [<ffffffff812e4b70>] ? symbol_put_addr+0x50/0x50
[ 8812.397546]  [<ffffffff812e71a0>] ? module_frob_arch_sections+0x20/0x20
[ 8812.397552]  [<ffffffff8158e950>] ? open_exec+0x50/0x50
[ 8812.397559]  [<ffffffff811648db>] ? ns_capable+0x5b/0xd0
[ 8812.397565]  [<ffffffff812f1208>] SyS_finit_module+0x108/0x130
[ 8812.397571]  [<ffffffff812f1100>] ? SyS_init_module+0x1f0/0x1f0
[ 8812.397576]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
[ 8812.397582]  [<ffffffff82292236>] entry_SYSCALL_64_fastpath+0x16/0x7a

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
3e021e9
@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 12, 2016
@mchehab mchehab [media] media-entity: don't sleep at media_device_register_entity()
media_device_register_entity() is protected by a spin_lock.

Calling ida_pre_get() with GFP_KERNEL may put it to sleep,
with is a bad idea and causes this warning:

[ 8812.397195] BUG: sleeping function called from invalid context at mm/slub.c:1287
[ 8812.397203] in_atomic(): 1, irqs_disabled(): 0, pid: 15179, name: modprobe
[ 8812.397207] INFO: lockdep is turned off.
[ 8812.397213] CPU: 2 PID: 15179 Comm: modprobe Tainted: G    B           4.4.0-rc2+ #41
[ 8812.397218] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 8812.397222]  0000000000000000 ffff880314c77268 ffffffff818f8ba7 ffff8803b17dde00
[ 8812.397232]  ffff880314c77290 ffffffff811c2ee5 ffff8803b17dde00 ffffffff8284dbc9
[ 8812.397241]  0000000000000507 ffff880314c772d0 ffffffff811c30d5 0000000041b58ab3
[ 8812.397250] Call Trace:
[ 8812.397258]  [<ffffffff818f8ba7>] dump_stack+0x4b/0x64
[ 8812.397265]  [<ffffffff811c2ee5>] ___might_sleep+0x245/0x3a0
[ 8812.397270]  [<ffffffff811c30d5>] __might_sleep+0x95/0x1a0
[ 8812.397276]  [<ffffffff818fd083>] ? ida_pre_get+0x113/0x250
[ 8812.397282]  [<ffffffff8153bb77>] kmem_cache_alloc+0x197/0x250
[ 8812.397288]  [<ffffffff818fd083>] ida_pre_get+0x113/0x250
[ 8812.397293]  [<ffffffff818fd265>] ida_simple_get+0xa5/0x170
[ 8812.397298]  [<ffffffff818fd1c0>] ? ida_pre_get+0x250/0x250
[ 8812.397306]  [<ffffffffa07382d1>] media_device_register_entity+0x171/0x420 [media]
[ 8812.397318]  [<ffffffffa129e76f>] v4l2_device_register_subdev+0x34f/0x640 [videodev]
[ 8812.397324]  [<ffffffffa0768dea>] v4l2_i2c_new_subdev_board+0x12a/0x250 [v4l2_common]
[ 8812.397330]  [<ffffffffa0768fe7>] v4l2_i2c_new_subdev+0xd7/0x110 [v4l2_common]
[ 8812.397337]  [<ffffffffa0768f10>] ? v4l2_i2c_new_subdev_board+0x250/0x250 [v4l2_common]
[ 8812.397347]  [<ffffffffa13d2f76>] au0828_card_analog_fe_setup+0x2e6/0x3f0 [au0828]
[ 8812.397352]  [<ffffffff814450cc>] ? power_down+0xc4/0xc4
[ 8812.397361]  [<ffffffffa13d2c90>] ? au0828_tuner_callback+0x160/0x160 [au0828]
[ 8812.397370]  [<ffffffffa13d319f>] au0828_card_setup+0x11f/0x340 [au0828]
[ 8812.397378]  [<ffffffffa13d3080>] ? au0828_card_analog_fe_setup+0x3f0/0x3f0 [au0828]
[ 8812.397384]  [<ffffffff812a575b>] ? msleep+0x7b/0xc0
[ 8812.397393]  [<ffffffffa13d0d79>] au0828_usb_probe+0x679/0xcf0 [au0828]
[ 8812.397399]  [<ffffffff81d7619d>] usb_probe_interface+0x45d/0x940
[ 8812.397406]  [<ffffffff81ca7004>] driver_probe_device+0x454/0xd90
[ 8812.397411]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397417]  [<ffffffff81ca7940>] ? driver_probe_device+0xd90/0xd90
[ 8812.397422]  [<ffffffff81ca7a61>] __driver_attach+0x121/0x160
[ 8812.397427]  [<ffffffff81ca141f>] bus_for_each_dev+0x11f/0x1a0
[ 8812.397433]  [<ffffffff81ca1300>] ? subsys_dev_iter_exit+0x10/0x10
[ 8812.397439]  [<ffffffff822917d7>] ? _raw_spin_unlock+0x27/0x40
[ 8812.397445]  [<ffffffff81ca5d4d>] driver_attach+0x3d/0x50
[ 8812.397450]  [<ffffffff81ca5039>] bus_add_driver+0x4c9/0x770
[ 8812.397456]  [<ffffffff81ca944c>] driver_register+0x18c/0x3b0
[ 8812.397462]  [<ffffffff8124c952>] ? __raw_spin_lock_init+0x32/0x100
[ 8812.397468]  [<ffffffff81d71e58>] usb_register_driver+0x1f8/0x440
[ 8812.397473]  [<ffffffffa0208000>] ? 0xffffffffa0208000
[ 8812.397481]  [<ffffffffa02080b7>] au0828_init+0xb7/0x1000 [au0828]
[ 8812.397486]  [<ffffffff810021b1>] do_one_initcall+0x141/0x300
[ 8812.397492]  [<ffffffff81002070>] ? try_to_run_init_process+0x40/0x40
[ 8812.397497]  [<ffffffff8123bbf6>] ? trace_hardirqs_on_caller+0x16/0x590
[ 8812.397502]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397507]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397512]  [<ffffffff815406e6>] ? kasan_unpoison_shadow+0x36/0x50
[ 8812.397517]  [<ffffffff815407f7>] ? __asan_register_globals+0x87/0xa0
[ 8812.397524]  [<ffffffff814454e5>] do_init_module+0x1d0/0x5a4
[ 8812.397530]  [<ffffffff812ed7e8>] load_module+0x6648/0x9d70
[ 8812.397535]  [<ffffffff812e4b70>] ? symbol_put_addr+0x50/0x50
[ 8812.397546]  [<ffffffff812e71a0>] ? module_frob_arch_sections+0x20/0x20
[ 8812.397552]  [<ffffffff8158e950>] ? open_exec+0x50/0x50
[ 8812.397559]  [<ffffffff811648db>] ? ns_capable+0x5b/0xd0
[ 8812.397565]  [<ffffffff812f1208>] SyS_finit_module+0x108/0x130
[ 8812.397571]  [<ffffffff812f1100>] ? SyS_init_module+0x1f0/0x1f0
[ 8812.397576]  [<ffffffff81004044>] ? lockdep_sys_exit_thunk+0x12/0x14
[ 8812.397582]  [<ffffffff82292236>] entry_SYSCALL_64_fastpath+0x16/0x7a

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
ba0dd72
@nkskjames nkskjames referenced this pull request in nkskjames/linux Jan 13, 2016
Russell King ARM: uaccess: fix undefined instruction on ARMv7M/noMMU
The use of get_domain() in copy_thread() results in an oops on
ARMv7M/noMMU systems.  The thread cpu_domain value is only used when
CONFIG_CPU_USE_DOMAINS is enabled, so there's no need to save the
value in copy_thread() except when this is enabled, and this option
will never be enabled on these platforms.

Unhandled exception: IPSR = 00000006 LR = fffffff1
CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-next-20150909-00001-gb8ec5ad #41
Hardware name: NXP LPC18xx/43xx (Device Tree)
task: 2823fbe0 ti: 2823c000 task.ti: 2823c000
PC is at copy_thread+0x18/0x92
LR is at copy_thread+0x19/0x92
pc : [<2800a46e>]    lr : [<2800a46f>]    psr: 4100000b
sp : 2823df00  ip : 00000000  fp : 287c81c0
r10: 00000000  r9 : 00800300  r8 : 287c8000
r7 : 287c8000  r6 : 2818908d  r5 : 00000000  r4 : 287ca000
r3 : 00000000  r2 : 00000000  r1 : fffffff0  r0 : 287ca048
xPSR: 4100000b

Reported-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
8fd6430
@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Mar 25, 2016
Winter Wang usb: gadget: fix NULL ptr derefer while unlinking functions
Fix NULL pointer dereference while trying to unlink audio_source
in android.

If unlink audio_source function, got a NULL pointer dereference:
---------------
[00000000] *pgd=28ad1831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: init Not tainted 4.1.15-03448-g3749667-dirty #41
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: d8070000 ti: d8056000 task.ti: d8056000
PC is at 0x0
LR is at config_usb_cfg_unlink+0xfc/0x10c
pc : [<00000000>]    lr : [<c06d24b4>]    psr: a00f0013
<..snip..>
[<c06d24b4>] (config_usb_cfg_unlink) from [<c026bfe4>] (configfs_unlink+0x110/0x1a4)
[<c026bfe4>] (configfs_unlink) from [<c020d894>] (vfs_unlink+0xcc/0x1a8)
[<c020d894>] (vfs_unlink) from [<c0212a3c>] (do_unlinkat+0x230/0x264)
...
---------------

Add sanity check for NULL pointer in usb_put_function, as some
functions doesn't have func->free_func implemented.

Signed-off-by: Winter Wang <wente.wang@nxp.com>
29db085
@sashalevin sashalevin added a commit that referenced this pull request Apr 11, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
f938e2d
@sashalevin sashalevin added a commit that referenced this pull request Apr 11, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
b608ed4
@sashalevin sashalevin added a commit that referenced this pull request Apr 11, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
621f5e4
@sashalevin sashalevin added a commit that referenced this pull request Apr 11, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: deleted code is slightly different; we don't
 have list_next_entry()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
36a5883
@sashalevin sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: deleted code is slightly different; we don't
 have list_next_entry()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
dd75824
@sashalevin sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
47e1a6a
@sashalevin sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
364e2bc
@sashalevin sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
@rostedt rostedt debugfs: Fix corrupted loop in debugfs_remove_recursive
commit 485d440 upstream.

[ I'm currently running my tests on it now, and so far, after a few
 hours it has yet to blow up. I'll run it for 24 hours which it never
 succeeded in the past. ]

The tracing code has a way to make directories within the debugfs file
system as well as deleting them using mkdir/rmdir in the instance
directory. This is very limited in functionality, such as there is
no renames, and the parent directory "instance" can not be modified.
The tracing code creates the instance directory from the debugfs code
and then replaces the dentry->d_inode->i_op with its own to allow
for mkdir/rmdir to work.

When these are called, the d_entry and inode locks need to be released
to call the instance creation and deletion code. That code has its own
accounting and locking to serialize everything to prevent multiple
users from causing harm. As the parent "instance" directory can not
be modified this simplifies things.

I created a stress test that creates several threads that randomly
creates and deletes directories thousands of times a second. The code
stood up to this test and I submitted it a while ago.

Recently I added a new test that adds readers to the mix. While the
instance directories were being added and deleted, readers would read
from these directories and even enable tracing within them. This test
was able to trigger a bug:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: ...
 CPU: 3 PID: 17789 Comm: rmdir Tainted: G        W     3.15.0-rc2-test+ #41
 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
 task: ffff88003786ca60 ti: ffff880077018000 task.ti: ffff880077018000
 RIP: 0010:[<ffffffff811ed5eb>]  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
 RSP: 0018:ffff880077019df8  EFLAGS: 00010246
 RAX: 0000000000000002 RBX: ffff88006f0fe490 RCX: 0000000000000000
 RDX: dead000000100058 RSI: 0000000000000246 RDI: ffff88003786d454
 RBP: ffff88006f0fe640 R08: 0000000000000628 R09: 0000000000000000
 R10: 0000000000000628 R11: ffff8800795110a0 R12: ffff88006f0fe640
 R13: ffff88006f0fe640 R14: ffffffff81817d0b R15: ffffffff818188b7
 FS:  00007ff13ae24700(0000) GS:ffff88007d580000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000003054ec7be0 CR3: 0000000076d51000 CR4: 00000000000007e0
 Stack:
  ffff88007a41ebe0 dead000000100058 00000000fffffffe ffff88006f0fe640
  0000000000000000 ffff88006f0fe678 ffff88007a41ebe0 ffff88003793a000
  00000000fffffffe ffffffff810bde82 ffff88006f0fe640 ffff88007a41eb28
 Call Trace:
  [<ffffffff810bde82>] ? instance_rmdir+0x15b/0x1de
  [<ffffffff81132e2d>] ? vfs_rmdir+0x80/0xd3
  [<ffffffff81132f51>] ? do_rmdir+0xd1/0x139
  [<ffffffff8124ad9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
  [<ffffffff814fea62>] ? system_call_fastpath+0x16/0x1b
 Code: fe ff ff 48 8d 75 30 48 89 df e8 c9 fd ff ff 85 c0 75 13 48 c7 c6 b8 cc d2 81 48 c7 c7 b0 cc d2 81 e8 8c 7a f5 ff 48 8b 54 24 08 <48> 8b 82 a8 00 00 00 48 89 d3 48 2d a8 00 00 00 48 89 44 24 08
 RIP  [<ffffffff811ed5eb>] debugfs_remove_recursive+0x1bd/0x367
  RSP <ffff880077019df8>

It took a while, but every time it triggered, it was always in the
same place:

	list_for_each_entry_safe(child, next, &parent->d_subdirs, d_u.d_child) {

Where the child->d_u.d_child seemed to be corrupted.  I added lots of
trace_printk()s to see what was wrong, and sure enough, it was always
the child's d_u.d_child field. I looked around to see what touches
it and noticed that in __dentry_kill() which calls dentry_free():

static void dentry_free(struct dentry *dentry)
{
	/* if dentry was never visible to RCU, immediate free is OK */
	if (!(dentry->d_flags & DCACHE_RCUACCESS))
		__d_free(&dentry->d_u.d_rcu);
	else
		call_rcu(&dentry->d_u.d_rcu, __d_free);
}

I also noticed that __dentry_kill() unlinks the child->d_u.child
under the parent->d_lock spin_lock.

Looking back at the loop in debugfs_remove_recursive() it never takes the
parent->d_lock to do the list walk. Adding more tracing, I was able to
prove this was the issue:

 ftrace-t-15385   1.... 246662024us : dentry_kill <ffffffff81138b91>: free ffff88006d573600
    rmdir-15409   2.... 246662024us : debugfs_remove_recursive <ffffffff811ec7e5>: child=ffff88006d573600 next=dead000000100058

The dentry_kill freed ffff88006d573600 just as the remove recursive was walking
it.

In order to fix this, the list walk needs to be modified a bit to take
the parent->d_lock. The safe version is no longer necessary, as every
time we remove a child, the parent->d_lock must be released and the
list walk must start over. Each time a child is removed, even though it
may still be on the list, it should be skipped by the first check
in the loop:

		if (!debugfs_positive(child))
			continue;

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4d003c6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment