Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Merge pull request #1 from torvalds/master #41

Open
wants to merge 12 commits into from

1 participant

@moonlinux

pull-linuxmaster

@dsahern dsahern referenced this pull request from a commit in dsahern/linux
@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 referenced this pull request from a commit in swarren/linux-tegra
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 referenced this pull request from a commit in swarren/linux-tegra
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
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@eegorov eegorov referenced this pull request from a commit in eegorov/zen-kernel
@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 from a commit in eegorov/zen-kernel
@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 from a commit in eegorov/zen-kernel
@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 from a commit in eegorov/zen-kernel
@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 referenced this pull request from a commit
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 referenced this pull request from a commit in ddstreet/linux
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 referenced this pull request from a commit in Distrotech/linux
@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 referenced this pull request from a commit in tom3q/linux
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 referenced this pull request from a commit
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 referenced this pull request from a commit in swarren/linux-tegra
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 referenced this pull request from a commit in Gnurou/linux
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 referenced this pull request from a commit in JoonsooKim/linux
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 referenced this pull request from a commit in krieger-od/linux
@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 referenced this pull request from a commit in krieger-od/linux
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 referenced this pull request from a commit in krieger-od/linux
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 referenced this pull request from a commit in ddstreet/linux
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 referenced this pull request from a commit in krieger-od/linux
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
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@heftig heftig referenced this pull request from a commit in zen-kernel/zen-kernel
@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 referenced this pull request from a commit in sunny256/linux
@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 referenced this pull request from a commit in sunny256/linux
@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
@zdobersek zdobersek referenced this pull request from a commit in zdobersek/linux
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>
da75e8a
@baerwolf baerwolf referenced this pull request from a commit in baerwolf/linux-stephan
@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
@koct9i koct9i referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
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 referenced this pull request from a commit in ddstreet/linux
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 referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@koct9i koct9i referenced this pull request from a commit in koct9i/linux
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 referenced this pull request from a commit in tom3q/linux
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 referenced this pull request from a commit in aryabinin/linux
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 referenced this pull request from a commit in pstglia/linux
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 referenced this pull request from a commit in pstglia/linux
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 referenced this pull request from a commit in bengal/linux
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 referenced this pull request from a commit in kees/linux
@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 referenced this pull request from a commit
@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 from a commit in dabrace/linux
@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 referenced this pull request from a commit
Kweh, Hock Leong 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 referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit in dongsupark/linux
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 referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit in dongsupark/linux
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 referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@dongsupark dongsupark referenced this pull request from a commit in dongsupark/linux
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 referenced this pull request from a commit in kdave/btrfs-devel
@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 referenced this pull request from a commit in nirobin/linux
@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 28, 2013
  1. @moonlinux

    Merge pull request #1 from torvalds/master

    moonlinux authored
    pull-linuxmaster
Commits on Aug 1, 2013
  1. @moonlinux
Commits on Sep 6, 2013
  1. @moonlinux

    Merge pull request #3 from torvalds/master

    moonlinux authored
    merge pull request
Commits on Sep 28, 2013
  1. @moonlinux

    Merge pull request #4 from torvalds/master

    moonlinux authored
    Merge Pull
Commits on Oct 9, 2013
  1. @moonlinux

    Merge pull request #5 from torvalds/master

    moonlinux authored
    Merge pull
Commits on Mar 20, 2014
  1. @moonlinux
Commits on Mar 23, 2014
  1. @moonlinux
Commits on Apr 2, 2014
  1. @moonlinux
Commits on Apr 24, 2014
  1. @moonlinux
Commits on May 15, 2014
  1. @moonlinux
Commits on May 25, 2014
  1. @moonlinux
Commits on May 26, 2014
  1. @moonlinux
This page is out of date. Refresh to see the latest.
Showing with 0 additions and 0 deletions.
Something went wrong with that request. Please try again.