update #40

Open
wants to merge 1 commit into
from

1 participant

@lsmushroom

update

@hardkernel hardkernel referenced this pull request in hardkernel/linux Jun 25, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
commit 5e4ba61 upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
6572391
@johnweber johnweber pushed a commit to johnweber/linux that referenced this pull request Jun 26, 2013
Steve Cornelius ENGR00215875-1: caam: improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Terry Lv <r65388@freescale.com>
aa15123
@johnweber johnweber pushed a commit to johnweber/linux that referenced this pull request Jun 26, 2013
Steve Cornelius ENGR00215875-1: caam: improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Terry Lv <r65388@freescale.com>
06cb9c6
@ffainelli ffainelli pushed a commit to ffainelli/linux that referenced this pull request Jun 26, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Cc: <stable@vger.kernel.org>
Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
5e4ba61
@Ithamar Ithamar pushed a commit that referenced this pull request Jun 27, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
commit 5e4ba61 upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
95a2b9b
@zehome zehome referenced this pull request in zehome/linux Aug 10, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
commit 5e4ba61 upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
908e88f
@swarren swarren pushed a commit to swarren/linux-tegra that referenced this pull request Oct 14, 2013
Borislav Petkov x86: Improve the printout of the SMP bootup CPU table
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

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

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

and this:

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

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

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

and drop useless elements.

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

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@TechNexion TechNexion pushed a commit to TechNexion/linux that referenced this pull request Oct 25, 2013
Steve Cornelius ENGR00215875-1: caam: improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Terry Lv <r65388@freescale.com>
27629a6
@wandboard-org wandboard-org pushed a commit to wandboard-org/linux that referenced this pull request Nov 6, 2013
Steve Cornelius ENGR00215875-1: caam: improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Terry Lv <r65388@freescale.com>
3bb9cfb
@kees kees pushed a commit to kees/linux that referenced this pull request Nov 8, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
BugLink: http://bugs.launchpad.net/bugs/1164646

commit 5e4ba61 upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Steve Conklin <sconklin@canonical.com>
ec9f975
@shr-buildhost shr-buildhost pushed a commit to shr-distribution/linux that referenced this pull request Nov 30, 2013
Russell King ARM: VFP: fix emulation of second VFP instruction
commit 5e4ba61 upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
e1f3c39
@elp elp pushed a commit to ariknem/linux that referenced this pull request Jan 28, 2014
@mugunthanvnm mugunthanvnm drivers: net: cpsw: discard all packets received when interface is down
When the Ethernet interface is brought down during high Ethernet traffic,
then cpsw creates the following warn dump. When cpdma has already processed
the packet then the status will be greater than 0, so the cpsw_rx_handler
considers that the interface is up and try to resubmit one more rx buffer
to cpdma which fails as the DMA is in teardown process. This can be avoided
by checking the interface state and then process the received packet, if the
interface is down just discard and free the skb and return.

[  160.107111] WARNING: CPU: 0 PID: 1422 at drivers/net/ethernet/ti/cpsw.c:708 cpsw_rx_handler+0x150/0x164()
[  160.117235] Modules linked in:
[  160.120470] CPU: 0 PID: 1422 Comm: ifconfig Tainted: G        W    3.12.4-01484-gb60d714 #40
[  160.129427] [<c001cc98>] (unwind_backtrace+0x0/0xf0) from [<c0018124>] (show_stack+0x10/0x14)
[  160.138468] [<c0018124>] (show_stack+0x10/0x14) from [<c05f89b0>] (dump_stack+0x74/0xb4)
[  160.147047] [<c05f89b0>] (dump_stack+0x74/0xb4) from [<c0047df8>] (warn_slowpath_common+0x6c/0x90)
[  160.156540] [<c0047df8>] (warn_slowpath_common+0x6c/0x90) from [<c0047e38>] (warn_slowpath_null+0x1c/0x24)
[  160.166709] [<c0047e38>] (warn_slowpath_null+0x1c/0x24) from [<c043e0ec>] (cpsw_rx_handler+0x150/0x164)
[  160.176611] [<c043e0ec>] (cpsw_rx_handler+0x150/0x164) from [<c043a580>] (__cpdma_chan_free+0x90/0xa8)
[  160.186411] [<c043a580>] (__cpdma_chan_free+0x90/0xa8) from [<c043a68c>] (__cpdma_chan_process+0xf4/0x134)
[  160.196578] [<c043a68c>] (__cpdma_chan_process+0xf4/0x134) from [<c043a7d4>] (cpdma_chan_stop+0xb4/0x17c)
[  160.206654] [<c043a7d4>] (cpdma_chan_stop+0xb4/0x17c) from [<c043a8e0>] (cpdma_ctlr_stop+0x44/0x9c)
[  160.216186] [<c043a8e0>] (cpdma_ctlr_stop+0x44/0x9c) from [<c043eae4>] (cpsw_ndo_stop+0x14c/0x180)
[  160.225626] [<c043eae4>] (cpsw_ndo_stop+0x14c/0x180) from [<c051f478>] (__dev_close_many+0x84/0xcc)
[  160.235151] [<c051f478>] (__dev_close_many+0x84/0xcc) from [<c051f4e8>] (__dev_close+0x28/0x3c)
[  160.244292] [<c051f4e8>] (__dev_close+0x28/0x3c) from [<c0523ebc>] (__dev_change_flags+0x88/0x138)
[  160.253721] [<c0523ebc>] (__dev_change_flags+0x88/0x138) from [<c0523fec>] (dev_change_flags+0x10/0x48)
[  160.263616] [<c0523fec>] (dev_change_flags+0x10/0x48) from [<c0585060>] (devinet_ioctl+0x610/0x6c8)
[  160.273146] [<c0585060>] (devinet_ioctl+0x610/0x6c8) from [<c050c538>] (sock_ioctl+0x68/0x2a4)
[  160.282216] [<c050c538>] (sock_ioctl+0x68/0x2a4) from [<c0128504>] (do_vfs_ioctl+0x7c/0x5c8)
[  160.291108] [<c0128504>] (do_vfs_ioctl+0x7c/0x5c8) from [<c0128abc>] (SyS_ioctl+0x6c/0x7c)
[  160.299814] [<c0128abc>] (SyS_ioctl+0x6c/0x7c) from [<c0014100>] (ret_fast_syscall+0x0/0x48)
[  160.308703] ---[ end trace 111935c3f7a2bbeb ]---

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
5ef3537
@tom3q tom3q pushed a commit to tom3q/linux that referenced this pull request Jun 10, 2014
Thierry Reding drm/plane: Fix a couple of checkpatch warnings
Code should be indented using tabs rather than spaces (see CodingStyle)
and the canonical form to declare a constant static variable is using
"static const" rather than "const static". Fixes the following warnings
from checkpatch:

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

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

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

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
233fd4e
@Gnurou Gnurou pushed a commit to Gnurou/linux that referenced this pull request Jul 8, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2a96dfa
@heftig heftig referenced this pull request in zen-kernel/zen-kernel Jul 18, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
commit 2a96dfa upstream.

After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
885b745
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Jul 18, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
commit 2a96dfa upstream.

After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
22c9e29
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Jul 27, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
commit 2a96dfa upstream.

After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
c2602aa
@aryabinin aryabinin pushed a commit to aryabinin/linux that referenced this pull request Sep 24, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

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

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

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

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

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

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

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

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

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

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7e98789
@pstglia pstglia added a commit to pstglia/linux that referenced this pull request Oct 6, 2014
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
@pstglia pstglia added a commit to pstglia/linux that referenced this pull request Oct 6, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
bf775d1
@chrillomat chrillomat pushed a commit to chrillomat/linux that referenced this pull request Oct 6, 2014
Xianzhong ENGR00309915 [#1087] enhanced video memory mutex
this patch can fix NULL pointer issue in GPU kernel driver with the following log

[<7f240438>] (gckEVENT_AddList+0x0/0x810 [galcore]) from [<7f239ebc>] (gckCOMMAND_Commit+0xf28/0x118c [galcore])
[<7f238f94>] (gckCOMMAND_Commit+0x0/0x118c [galcore]) from [<7f2362dc>] (gckKERNEL_Dispatch+0x120c/0x24e4 [galcore])
[<7f2350d0>] (gckKERNEL_Dispatch+0x0/0x24e4 [galcore]) from [<7f222280>] (drv_ioctl+0x390/0x540 [galcore])
[<7f221ef0>] (drv_ioctl+0x0/0x540 [galcore]) from [<800facd0>] (vfs_ioctl+0x30/0x44)

The false code is at 0x217bc where the 0-pointer happens (r3 = 0)

gcuVIDMEM_NODE_PTR node = (gcuVIDMEM_NODE_PTR)(gcmUINT64_TO_PTR(Record->info.u.FreeVideoMemory.node));
   217b8:                e5953028             ldr           r3, [r5, #40]         ; 0x28

                if (node->VidMem.memory->object.type == gcvOBJ_VIDMEM)
   217bc:                e5932000             ldr           r2, [r3]
   217c0:                e5922000             ldr           r2, [r2]
   217c4:                e152000a             cmp       r2, sl
                {
                     gcmkVERIFY_OK(gckKERNEL_RemoveProcessDB(Event->kernel,

Date: Apr 23, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
13859c2
@bengal bengal pushed a commit to bengal/linux that referenced this pull request Oct 7, 2014
Andrew Morton mm-introduce-vm_bug_on_mm-checkpatch-fixes
ERROR: code indent should use tabs where possible
#37: FILE: include/linux/mmdebug.h:33:
+        do {^I^I^I^I^I^I^I^I\$

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

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

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

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

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

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

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

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

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

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

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

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

total: 6 errors, 7 warnings, 109 lines checked

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

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

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

Please run checkpatch prior to sending patches

Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d17e8aa
@kees kees pushed a commit to kees/linux that referenced this pull request Oct 9, 2014
@krzk krzk clk: s2mps11: Fix double free corruption during driver unbind
BugLink: http://bugs.launchpad.net/bugs/1356913

commit 2a96dfa upstream.

After unbinding the driver memory was corrupted by double free of
clk_lookup structure. This lead to OOPS when re-binding the driver
again.

The driver allocated memory for 'clk_lookup' with devm_kzalloc. During
driver removal this memory was freed twice: once by clkdev_drop() and
second by devm code.

Kernel panic log:
[   30.839284] Unable to handle kernel paging request at virtual address 5f343173
[   30.846476] pgd = dee14000
[   30.849165] [5f343173] *pgd=00000000
[   30.852703] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[   30.858166] Modules linked in:
[   30.861208] CPU: 0 PID: 1 Comm: bash Not tainted 3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   30.869364] task: df478000 ti: df480000 task.ti: df480000
[   30.874752] PC is at clkdev_add+0x2c/0x38
[   30.878738] LR is at clkdev_add+0x18/0x38
[   30.882732] pc : [<c0350908>]    lr : [<c03508f4>]    psr: 60000013
[   30.882732] sp : df481e78  ip : 00000001  fp : c0700ed8
[   30.894187] r10: 0000000c  r9 : 00000000  r8 : c07b0e3c
[   30.899396] r7 : 00000002  r6 : df45f9d0  r5 : df421390  r4 : c0700d6c
[   30.905906] r3 : 5f343173  r2 : c0700d84  r1 : 60000013  r0 : c0700d6c
[   30.912417] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   30.919534] Control: 10c53c7d  Table: 5ee1406a  DAC: 00000015
[   30.925262] Process bash (pid: 1, stack limit = 0xdf480240)
[   30.930817] Stack: (0xdf481e78 to 0xdf482000)
[   30.935159] 1e60:                                                       00001000 df6de610
[   30.943321] 1e80: df7f4558 c0355650 c05ec6ec c0700eb0 df6de600 df7f4510 dec9d69c 00000014
[   30.951480] 1ea0: 00167b48 df6de610 c0700e30 c0713518 00000000 c0700e30 dec9d69c 00000006
[   30.959639] 1ec0: 00167b48 c02c1b7c c02c1b64 df6de610 c07aff48 c02c0420 c06fb150 c047cc20
[   30.967798] 1ee0: df6de610 df6de610 c0700e30 df6de644 c06fb150 0000000c dec9d690 c02bef90
[   30.975957] 1f00: dec9c6c0 dece4c00 df481f80 dece4c00 0000000c c02be73c 0000000c c016ca8c
[   30.984116] 1f20: c016ca48 00000000 00000000 c016c1f4 00000000 00000000 b6f18000 df481f80
[   30.992276] 1f40: df7f66c0 0000000c df480000 df480000 b6f18000 c011094c df47839c 60000013
[   31.000435] 1f60: 00000000 00000000 df7f66c0 df7f66c0 0000000c df480000 b6f18000 c0110dd4
[   31.008594] 1f80: 00000000 00000000 0000000c b6ec05d8 0000000c b6f18000 00000004 c000f2a8
[   31.016753] 1fa0: 00001000 c000f0e0 b6ec05d8 0000000c 00000001 b6f18000 0000000c 00000000
[   31.024912] 1fc0: b6ec05d8 0000000c b6f18000 00000004 0000000c 00000001 00000000 00167b48
[   31.033071] 1fe0: 00000000 bed83a80 b6e004f0 b6e5122c 60000010 00000001 ffffffff ffffffff
[   31.041248] [<c0350908>] (clkdev_add) from [<c0355650>] (s2mps11_clk_probe+0x2b4/0x3b4)
[   31.049223] [<c0355650>] (s2mps11_clk_probe) from [<c02c1b7c>] (platform_drv_probe+0x18/0x48)
[   31.057728] [<c02c1b7c>] (platform_drv_probe) from [<c02c0420>] (driver_probe_device+0x13c/0x384)
[   31.066579] [<c02c0420>] (driver_probe_device) from [<c02bef90>] (bind_store+0x88/0xd8)
[   31.074564] [<c02bef90>] (bind_store) from [<c02be73c>] (drv_attr_store+0x20/0x2c)
[   31.082118] [<c02be73c>] (drv_attr_store) from [<c016ca8c>] (sysfs_kf_write+0x44/0x48)
[   31.090016] [<c016ca8c>] (sysfs_kf_write) from [<c016c1f4>] (kernfs_fop_write+0xc0/0x17c)
[   31.098176] [<c016c1f4>] (kernfs_fop_write) from [<c011094c>] (vfs_write+0xa0/0x1c4)
[   31.105899] [<c011094c>] (vfs_write) from [<c0110dd4>] (SyS_write+0x40/0x8c)
[   31.112931] [<c0110dd4>] (SyS_write) from [<c000f0e0>] (ret_fast_syscall+0x0/0x3c)
[   31.120481] Code: e2842018 e584501c e1a00004 e885000c (e5835000)
[   31.126596] ---[ end trace efad45bfa3a61b05 ]---
[   31.131181] Kernel panic - not syncing: Fatal exception
[   31.136368] CPU1: stopping
[   31.139054] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D       3.16.0-rc2-00239-g94bdf617b07e-dirty #40
[   31.148697] [<c0016480>] (unwind_backtrace) from [<c0012950>] (show_stack+0x10/0x14)
[   31.156419] [<c0012950>] (show_stack) from [<c0480db8>] (dump_stack+0x80/0xcc)
[   31.163622] [<c0480db8>] (dump_stack) from [<c001499c>] (handle_IPI+0x130/0x15c)
[   31.170998] [<c001499c>] (handle_IPI) from [<c000862c>] (gic_handle_irq+0x60/0x68)
[   31.178549] [<c000862c>] (gic_handle_irq) from [<c0013480>] (__irq_svc+0x40/0x70)
[   31.186009] Exception stack(0xdf4bdf88 to 0xdf4bdfd0)
[   31.191046] df80:                   ffffffed 00000000 00000000 00000000 df4bc000 c06d042c
[   31.199207] dfa0: 00000000 ffffffed c06d03c0 00000000 c070c288 00000000 00000000 df4bdfd0
[   31.207363] dfc0: c0010324 c0010328 60000013 ffffffff
[   31.212402] [<c0013480>] (__irq_svc) from [<c0010328>] (arch_cpu_idle+0x28/0x30)
[   31.219783] [<c0010328>] (arch_cpu_idle) from [<c005f150>] (cpu_startup_entry+0x2c4/0x3f0)
[   31.228027] [<c005f150>] (cpu_startup_entry) from [<400086c4>] (0x400086c4)
[   31.234968] ---[ end Kernel panic - not syncing: Fatal exception

Fixes: 7cc560d ("clk: s2mps11: Add support for s2mps11")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
186d7b3
@torvalds torvalds pushed a commit that referenced this pull request Oct 29, 2014
@pranith pranith powerpc: Wire up sys_bpf() syscall
This patch wires up the new syscall sys_bpf() on powerpc.

Passes the tests in samples/bpf:

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

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

Passes the tests in samples/bpf:

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

Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
[mpe: test using samples/bpf]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
7a0faa9
@alfonsotames alfonsotames pushed a commit to alfonsotames/linux that referenced this pull request Dec 15, 2014
Xianzhong ENGR00309915 [#1087] enhanced video memory mutex
this patch can fix NULL pointer issue in GPU kernel driver with the following log

[<7f240438>] (gckEVENT_AddList+0x0/0x810 [galcore]) from [<7f239ebc>] (gckCOMMAND_Commit+0xf28/0x118c [galcore])
[<7f238f94>] (gckCOMMAND_Commit+0x0/0x118c [galcore]) from [<7f2362dc>] (gckKERNEL_Dispatch+0x120c/0x24e4 [galcore])
[<7f2350d0>] (gckKERNEL_Dispatch+0x0/0x24e4 [galcore]) from [<7f222280>] (drv_ioctl+0x390/0x540 [galcore])
[<7f221ef0>] (drv_ioctl+0x0/0x540 [galcore]) from [<800facd0>] (vfs_ioctl+0x30/0x44)

The false code is at 0x217bc where the 0-pointer happens (r3 = 0)

gcuVIDMEM_NODE_PTR node = (gcuVIDMEM_NODE_PTR)(gcmUINT64_TO_PTR(Record->info.u.FreeVideoMemory.node));
   217b8:                e5953028             ldr           r3, [r5, #40]         ; 0x28

                if (node->VidMem.memory->object.type == gcvOBJ_VIDMEM)
   217bc:                e5932000             ldr           r2, [r3]
   217c0:                e5922000             ldr           r2, [r2]
   217c4:                e152000a             cmp       r2, sl
                {
                     gcmkVERIFY_OK(gckKERNEL_RemoveProcessDB(Event->kernel,

Date: Apr 23, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
(cherry picked from commit fcde214)
(cherry picked from commit 952142648d76fce2663ef649d9f988f1b7809815)
(cherry picked from commit 9d7b33678f1f944f75644e958c3ceeb7f2e4bac9)
1b41d9c
@Reichl Reichl pushed a commit to Reichl/linux-odroid that referenced this pull request Mar 5, 2015
Andrew Morton mm-clarify-__gfp_nofail-deprecation-status-checkpatch-fixes
WARNING: 'carefuly' may be misspelled - perhaps 'carefully'?
#40: FILE: include/linux/gfp.h:60:
+ * cannot handle allocation failures. New users should be evaluated carefuly

total: 0 errors, 1 warnings, 12 lines checked

./patches/mm-clarify-__gfp_nofail-deprecation-status.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: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
94fc233
@Reichl Reichl pushed a commit to Reichl/linux-odroid that referenced this pull request Mar 5, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
5cd36a6
@Reichl Reichl pushed a commit to Reichl/linux-odroid that referenced this pull request Mar 9, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d4565bc
@Reichl Reichl pushed a commit to Reichl/linux-odroid that referenced this pull request Mar 10, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ccedd34
@Reichl Reichl pushed a commit to Reichl/linux-odroid that referenced this pull request Mar 12, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
45e86ad
@jpoimboe jpoimboe pushed a commit that referenced this pull request Mar 25, 2015
Andrew Morton mm-clarify-__gfp_nofail-deprecation-status-checkpatch-fixes
WARNING: 'carefuly' may be misspelled - perhaps 'carefully'?
#40: FILE: include/linux/gfp.h:60:
+ * cannot handle allocation failures. New users should be evaluated carefuly

total: 0 errors, 1 warnings, 12 lines checked

./patches/mm-clarify-__gfp_nofail-deprecation-status.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: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
d8287a1
@jpoimboe jpoimboe pushed a commit that referenced this pull request Mar 25, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
f6127d5
@gthelen gthelen pushed a commit to gthelen/linux that referenced this pull request Apr 1, 2015
Andrew Morton tomoyo-reduce-mmap_sem-hold-for-mm-exe_file-checkpatch-fixes
Sumeone needs to buy a tab key.

WARNING: please, no spaces at the start of a line
#29: FILE: security/tomoyo/util.c:951:
+       struct file *exe_file;$

WARNING: please, no spaces at the start of a line
#30: FILE: security/tomoyo/util.c:952:
+       const char *cp;$

WARNING: please, no spaces at the start of a line
#31: FILE: security/tomoyo/util.c:953:
+       struct mm_struct *mm = current->mm;$

WARNING: please, no spaces at the start of a line
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)$

WARNING: suspect code indent for conditional statements (7, 15)
#40: FILE: security/tomoyo/util.c:955:
+       if (!mm)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#42: FILE: security/tomoyo/util.c:957:
+       exe_file = get_mm_exe_file(mm);$

WARNING: please, no spaces at the start of a line
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)$

WARNING: suspect code indent for conditional statements (7, 15)
#43: FILE: security/tomoyo/util.c:958:
+       if (!exe_file)
+	       return NULL;

WARNING: please, no spaces at the start of a line
#46: FILE: security/tomoyo/util.c:961:
+       cp = tomoyo_realpath_from_path(&exe_file->f_path);$

WARNING: please, no spaces at the start of a line
#47: FILE: security/tomoyo/util.c:962:
+       fput(exe_file);$

WARNING: please, no spaces at the start of a line
#48: FILE: security/tomoyo/util.c:963:
+       return cp;$

total: 0 errors, 11 warnings, 28 lines checked

./patches/tomoyo-reduce-mmap_sem-hold-for-mm-exe_file.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: Davidlohr Bueso <dbueso@suse.de>
Cc: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
007cca1
@krzk krzk pushed a commit to krzk/linux that referenced this pull request May 2, 2015
Andrew Morton mm-clarify-__gfp_nofail-deprecation-status-checkpatch-fixes
WARNING: 'carefuly' may be misspelled - perhaps 'carefully'?
#40: FILE: include/linux/gfp.h:60:
+ * cannot handle allocation failures. New users should be evaluated carefuly

total: 0 errors, 1 warnings, 12 lines checked

./patches/mm-clarify-__gfp_nofail-deprecation-status.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: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2bcaa02
@arunthomas arunthomas pushed a commit to arunthomas/linux that referenced this pull request Jun 3, 2015
@a0u a0u Enable interrupts within the page fault handler
* Avoid acquiring the mmap_sem semaphore in atomic context.
  This relieves a potential error condition detected when
  CONFIG_DEBUG_ATOMIC_SLEEP is selected:

	BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:20
	in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
	CPU: 0 PID: 1 Comm: init Not tainted 3.14.15-gae0c4a3-dirty #40
	Call Trace:
	[<ffffffff804327b4>] walk_stackframe+0x0/0xf8
	[<ffffffff80432974>] show_stack+0x3c/0x54
	[<ffffffff80622494>] dump_stack+0x2c/0x40
	[<ffffffff8045ceac>] __might_sleep+0xf4/0x118
	[<ffffffff80626680>] down_read+0x2c/0x4c
	[<ffffffff80432c8c>] do_page_fault+0xc8/0x3b8
	[<ffffffff80431418>] handle_syscall+0x2c/0x30
cb0db41
@Noltari Noltari pushed a commit to Noltari/linux that referenced this pull request Jun 18, 2015
Steve Cornelius crypto: caam - improve initalization for context state saves
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Cc: stable@vger.kernel.org
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
6fd4b15
@ddstreet ddstreet referenced this pull request in ddstreet/linux Jun 20, 2015
mmotm auto import linux-next
GIT c5901c20eb0341722035975a272a2a7b647fbb32

commit eeb64c14275e52740d6410632e62e0ad9b88ca70
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Sat Jun 6 11:44:39 2015 -0700

    tty/vt/keyboard: define LED triggers for VT keyboard lock states
    
    In addition to defining triggers for VT LED states, let's define triggers
    for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc.
    
    This permits to fix #7063 from userland by using a modifier to implement
    proper CapsLock behavior and have the keyboard caps lock led show that
    modifier state.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 5235552273e6b68abbed3b3047af6344e2e60c2c
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Mon Mar 16 21:19:44 2015 -0700

    tty/vt/keyboard: define LED triggers for VT LED states
    
    Now that input core allows controlling keyboards LEDs via standard LED
    subsystem triggers let's switch VT keyboard code to make use of this
    feature. We will define the following standard triggers: "kbd-scrollock",
    "kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default
    triggers for respective LEDs on keyboards.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

commit 10e87dc42a086c256b25334b6c1c89214feba9a7
Author: Andrew Duggan <aduggan@synaptics.com>
Date:   Tue Jun 16 14:08:41 2015 -0700

    HID: rmi: Disable populating F30 when the touchpad has physical buttons
    
    Physical buttons do not use F30 to report their state and in some cases the
    data reported in F30 is incorrect and inconsistent with what is reported by
    the HID descriptor. When physical buttons are present, ignore F30 and let
    hid-input report buttons based on what is defined in the HID descriptor.
    
    Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
    Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit ba8d134e75deb1904b146a4decb0bc6a217333cd
Author: Nishanth Menon <nm@ti.com>
Date:   Mon Apr 20 19:51:34 2015 -0500

    rtc: ds1307: Enable the mcp794xx alarm after programming time
    
    Alarm interrupt enable register is at offset 0x7, while the time
    registers for the alarm follow that. When we program Alarm interrupt
    enable prior to programming the time, it is possible that previous
    time value could be close or match at the time of alarm enable
    resulting in interrupt trigger which is unexpected (and does not match
    the time we expect it to trigger).
    
    To prevent this scenario from occuring, program the ALM0_EN bit only
    after the alarm time is appropriately programmed.
    
    Ofcourse, I2C programming is non-atomic, so there are loopholes where
    the interrupt wont trigger if the time requested is in the past at
    the time of programming the ALM0_EN bit. However, we will not have
    unexpected interrupts while the time is programmed after the interrupt
    are enabled.
    
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

commit b7ae128d728c42583dac9db48dce9a44bc0fb900
Author: Robert Richter <rrichter@cavium.com>
Date:   Fri Jun 5 19:49:26 2015 +0200

    ahci: Add support for Cavium's ThunderX host controller
    
    This patch adds support for Cavium's ThunderX host controller. The
    controller resides on the SoC and is a AHCI compatible SATA controller
    with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31.
    There can exists multiple SATA controllers on the SoC.
    
    The controller depends on MSI-X support since the PCI ECAM controller
    on the SoC does not implement MSI nor lagacy intx interrupt support.
    Thus, during device initialization, if MSI fails MSI-X will be used to
    enable the device's interrupts.
    
    The controller uses non-standard BAR0 for its register range. The
    already existing device lookup (vendor and device id) that is already
    implemented for other host controllers is used to change the PCI BAR.
    
    Signed-off-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit ee2aad42e4b6eaa9721196f07f7d5d8d049e6530
Author: Robert Richter <rrichter@cavium.com>
Date:   Fri Jun 5 19:49:25 2015 +0200

    ahci: Add generic MSI-X support for single interrupts to SATA PCI driver
    
    This patch adds generic MSI-X support for single interrupts to the
    SATA PCI driver. MSI-X support is needed for host controller that only
    have MSI-X support implemented, but no MSI or intx. This patch only
    adds support for single interrupts, multiple per-port MSI-X interrupts
    are not yet implemented.
    
    The new implementation still initializes MSIs first. Only if that
    fails, the code tries to enable MSI-X. If that fails too, setup is
    continued with intx interrupts.
    
    To not break other chips by this generic code change, there are the
    following precautions:
    
     * Interrupt ranges are not enabled at all.
    
     * Only single interrupt mode is enabled for msix cap devices. Thus,
       only one interrupt will be setup.
    
     * During the discussion with Tejun we agreed to change the init
       sequence from msix-msi-intx to msi-msix-intx. Thus, if a device
       offers msi and init does not fail, the msix init code will not be
       executed. This is equivalent to current code.
    
    With this, the code only setups single mode msix as a last resort if
    msi fails. No interrupt range is enabled at all. Only one interrupt
    will be enabled.
    
    tj: comment edits.
    
    Changes of the patch series:
    
    v5:
     * updated patch subject that the patch only implements single IRQ
     * moved Cavium specific code to a separate patch
     * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI
       instead of vendor/dev id
     * added more comments to the code
     * enable single msix support for all kind of devices (removing strict
       check)
     * rebased onto update libata/for-4.2 with patch 1, 2 applied
    
    v4:
     * removed implementation of ahci_init_intx()
     * improved patch descriptions
     * rebased onto libata/for-4.2
    
    v3:
     * store irq number in struct ahci_host_priv
     * change initialization order from msix-msi-intx to msi-msix-intx
     * improve comments in ahci_init_msix()
     * improve error message in ahci_init_msix()
     * do not enable MSI-X if MSI is actively disabled for the device
    
    v2:
     * determine irq vector from pci_dev->msi_list
    
    Based on a patch from Sunil Goutham <sgoutham@cavium.com>.
    
    Signed-off-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>

commit e0dd268a2c983acf2b52130b489b3b5724e26b39
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 12 00:35:43 2015 -0700

    leds: aat1290: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Signed-off-by: Bryan Wu <cooloney@gmail.com>

commit c8e27605c687d2d628217bef721e955d4baa1ce1
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jun 12 00:32:23 2015 -0700

    leds: ktd2692: pass flags parameter to devm_gpiod_get
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    In this case the driver cannot easily be simplified but as the flags
    parameter will become mandatory soon this change is necessary
    beforehand.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Signed-off-by: Bryan Wu <cooloney@gmail.com>

commit bc3e452003d02b8ec21546490aaed36003a83864
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    module: relocate module_init from init.h to module.h
    
    Modular users will always be users of init functionality, but
    users of init functionality are not necessarily always modules.
    
    Hence any functionality like module_init and module_exit would
    be more at home in the module.h file.  And module.h should
    explicitly include init.h to make the dependency clear.
    
    We've already done all the legwork needed to ensure that this
    move does not cause any build regressions due to implicit
    header file include assumptions about where module_init lives.
    
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Jun 15 09:56:26 2015 -0400

    MIPS: don't use module_init in non-modular cobalt/mtd.c file
    
    As of commit 34b1252bd91851f77f89fbb6829a04efad900f41 ("MIPS:
    Cobalt: Do not build MTD platform device registration code as module.")
    this file became built-in instead of modular.  So we should also
    stop using module_init as an alias for __initcall as that can be
    rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.
    
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Mon Jun 15 16:48:22 2015 -0500

    drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
    
    This file is built for a bool Kconfig variable, and hence this
    code is either present or absent.  It currently can never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Bryan Wu <cooloney@gmail.com>
    Cc: Richard Purdie <rpurdie@rpsys.net>
    Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
    Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
    Cc: linux-leds@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 32e805e7c6a343894c95a3431973e8ddad4aa2cf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Jun 5 09:37:19 2015 -0400

    tile: add init.h to usb.c to avoid compile failure
    
    Pending header cleanups will reveal this file is using the
    init.h content implicitly with the following fail:
    
    arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default]
    arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall'
    arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default]
    arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used
    
    Explicitly add init.h to get arch_initcall and avoid this.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Chris Metcalf <cmetcalf@ezchip.com>
    Acked-by: Chris Metcalf <cmetcalf@ezchip.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 9b9cf81a2d1f5336de2bebae71a9f2b8d5f1a8de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    arm: fix implicit #include <linux/init.h> in entry asm.
    
    They use the "_INIT" macro and friends, and hence need to
    source this header file, vs. relying on getting it implicitly.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 70c4f78b23c69013c908222d55a07c96fea4bba1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:13:42 2015 -0400

    x86: replace __init_or_module with __init in non-modular vsmp_64.c
    
    The __init_or_module is from commit 05e12e1c4c09cd35ac9f4e6af1e
    ("x86: fix 27-rc crash on vsmp due to paravirt during module load").
    
    But as of commit 70511134f61bd6e5eed19f767381f9fb3e762d49
    ("Revert "x86: don't compile vsmp_64 for 32bit") this file became
    obj-y and hence is now only for built-in.  That makes any
    "_or_module" support no longer necessary.
    
    We need to distinguish between the two in order to do some header
    reorganization between init.h and module.h and we don't want to
    be including module.h in non-modular code.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 77459a0feca4ae8757a905fd1791f039479e8e1e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 3 11:20:05 2015 -0400

    drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver
    
    This driver builds based on obj-y and hence will not ever be
    modular.  Change it to use the non-modular registration so that it
    won't suffer a compile fail once a header move places the modular
    registration within the module.h file.
    
    Cc: "Emilio López" <emilio@elopez.com.ar>
    Cc: Mike Turquette <mturquette@linaro.org>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Acked-by: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Cc: linux-clk@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit e35415e59f86d6b546a3681e2cda4f22b5b142c0
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:58 2015 -0400

    drivers/power: Convert non-modular syscon-reboot to use builtin_platform_driver
    
    This file depends on Kconfig options all of which are a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Sebastian Reichel <sre@kernel.org>
    Acked-By: Sebastian Reichel <sre@kernel.org>
    Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: linux-pm@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 0159ae95e6a923f565937f10518aa3c919527733
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular soc-realview to use builtin_platform_driver
    
    This file depends on Kconfig SOC_REALVIEW which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: Axel Lin <axel.lin@ingics.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 7d4d9ed6ef5219857865dd57d425f9729d0a39ff
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/soc: Convert non-modular tegra/pmc to use builtin_platform_driver
    
    This file depends on Kconfig ARCH_TEGRA which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Thierry Reding <thierry.reding@gmail.com>
    Cc: Alexandre Courbot <gnurou@gmail.com>
    Cc: linux-tegra@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5b64127e0529387d4538ecc3dfd49248baf619c5
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver
    
    This file depends on a Kconfig option which is a bool, so
    we use the appropriate registration function, which avoids us
    relying on an implicit inclusion of <module.h> which we are
    doing currently.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'd be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Kukjin Kim <kgene@kernel.org>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 090d1cf103725f583b3f41fc3185698ae5a7aa64
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/cpuidle: Convert non-modular drivers to use builtin_platform_driver
    
    All these drivers are configured with Kconfig options that are
    declared as bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using the
    module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Michal Simek <michal.simek@xilinx.com>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1dda2b42db1bbc788bf6de0a8141a305484f963b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver
    
    This driver is configured with a Kconfig option that is
    declared as a bool.  Hence it is not possible for the code
    to be built as modular.  However the code is currently using
    the module_platform_driver() macro for driver registration.
    
    While this currently works, we really don't want to be including
    the module.h header in non-modular code, which we'll be forced
    to do, pending some upcoming code relocation from init.h into
    module.h.  So we fix it now by using the non-modular equivalent.
    And since we've already established that the code is non-modular,
    we can completely drop any code relating to module_exit.
    
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit f309d4443130bf814e991f836e919dca22df37ae
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:10:57 2015 -0400

    platform_device: better support builtin boilerplate avoidance
    
    We have macros that help reduce the boilerplate for modules
    that register with no extra init/exit complexity other than the
    most standard use case.  However we see an increasing number of
    non-modular drivers using these modular_driver() type register
    functions.
    
    There are several downsides to this:
    1) The code can appear modular to a reader of the code, and they
       won't know if the code really is modular without checking the
       Makefile and Kconfig to see if compilation is governed by a
       bool or tristate.
    2) Coders of drivers may be tempted to code up an __exit function
       that is never used, just in order to satisfy the required three
       args of the modular registration function.
    3) Non-modular code ends up including the <module.h> which increases
       CPP overhead that they don't need.
    4) It hinders us from performing better separation of the module
       init code and the generic init code.
    
    Here we introduce similar macros, with the mapping from module_driver
    to builtin_driver and similar, so that simple changes of:
    
      module_platform_driver()       --->  builtin_platform_driver()
      module_platform_driver_probe() --->  builtin_platform_driver_probe().
    
    can help us avoid #3 above, without having to code up the same
    __init functions and device_initcall() boilerplate.
    
    For non modular code, module_init becomes __initcall.  But direct use
    of __initcall is discouraged, vs. one of the priority categorized
    subgroups.  As __initcall gets mapped onto device_initcall, our
    use of device_initcall directly in this change means that the
    runtime impact is zero -- drivers will remain at level 6 in the
    initcall ordering.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit ca41d24cf56458a699b44e918c5a19b7077df422
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling
    
    This was using module_init, but the current Kconfig situation is
    as follows:
    
    In arch/x86/kernel/cpu/Makefile:
    
      obj-$(CONFIG_CPU_SUP_INTEL)    += perf_event_intel_pt.o perf_event_intel_bts.o
    
    and in arch/x86/Kconfig.cpu:
    
      config CPU_SUP_INTEL
            default y
            bool "Support Intel processors" if PROCESSOR_SELECT
    
    So currently, the end user can not build this code into a module.
    If in the future, there is desire for this to be modular, then
    it can be changed to include <linux/module.h> and use module_init.
    
    But currently, in the non-modular case, a module_init becomes a
    device_initcall.  But this really isn't a device, so we should
    choose a more appropriate initcall bucket to put it in.
    
    The obvious choice here seems to be arch_initcall, but that does
    make it earlier than it was currently through device_initcall.
    As long as perf_pmu_register() is functional, we should be OK.
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 44c5af96de8230ff7268500f48995f9fea5cffe7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    mm/page_owner.c: use late_initcall to hook in enabling
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    In order of execution, our close choices are:
    
     fs_initcall(fn)
     rootfs_initcall(fn)
     device_initcall(fn)
     late_initcall(fn)
    
    ..and since the initcall here goes after debugfs, we really
    should be post-rootfs, which means late_initcall makes the
    most sense here.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-mm@kvack.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:57:34 2015 -0400

    lib/list_sort: use late_initcall to hook in self tests
    
    This was using module_init, but there is no way this code can
    be modular.  In the non-modular case, a module_init becomes a
    device_initcall, but this really isn't a device.   So we should
    choose a more appropriate initcall bucket to put it in.
    
    Assuming boot time self tests need to be observed over a console
    to be useful, and that the console device could possibly not be
    fully functional until after device_initcall, we move this to the
    late_initcall bucket, which is immediately after device_initcall.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 89f08f64408b630df7d559223f63e616d0814509
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    arm: use subsys_initcall in non-modular pl320 IPC code
    
    The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX
    which is declared as a bool.  Hence the code is never going to be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for IPC code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no impact of that small difference is expected.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 6f114281c4ad543392f5b7c8345e11e103675cee
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: don't use module_init for non-modular core hugetlb code
    
    The hugetlbpage.o is obj-y (always built in).  It will never
    be modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 383d14a5365879bc193d29ad2ed17ac5299753c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    powerpc: use subsys_initcall for Freescale Local Bus
    
    The FSL_SOC option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    makes sense for bus code) will thus change this registration
    from level 6-device to level 4-subsys (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Scott Wood <scottwood@freescale.com>
    Acked-by: Scott Wood <scottwood@freescale.com>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1206f53589237b7e00b9b0a4e42815f14aedad2d
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:21 2015 -0400

    x86: don't use module_init for non-modular core bootflag code
    
    The bootflag.o is obj-y (always built in).  It will never be
    modular, so using module_init as an alias for __initcall is
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of arch_initcall (which
    makes sense for arch code) will thus change this registration
    from level 6-device to level 3-arch (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 55331060096f0e9a57356ec36476a49e4bf22bc1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    netfilter: don't use module_init/exit in core IPV4 code
    
    The file net/ipv4/netfilter.o is created based on whether
    CONFIG_NETFILTER is set.  However that is defined as a bool, and
    hence this file with the core netfilter hooks will never be
    modular.  So using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Also add an inclusion of init.h, as
    that was previously implicit here in the netfilter.c file.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of subsys_initcall (which
    seems to make sense for netfilter code) will thus change this
    registration from level 6-device to level 4-subsys (i.e. slightly
    earlier).  However no observable impact of that small difference
    has been observed during testing, or is expected. (i.e. the
    location of the netfilter messages in dmesg remains unchanged
    with respect to all the other surrounding messages.)
    
    As for the module_exit, rather than replace it with __exitcall,
    we simply remove it, since it appears only UML does anything
    with those, and even for UML, there is no relevant cleanup
    to be done here.
    
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrick McHardy <kaber@trash.net>
    Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: netfilter-devel@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit c013d5a4581203e074a1065e17378984544fcaef
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    fs/notify: don't use module_init for non-modular inotify_user code
    
    The INOTIFY_USER option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of fs_initcall (which
    makes sense for fs code) will thus change this registration
    from level 6-device to level 5-fs (i.e. slightly earlier).
    However no observable impact of that small difference has
    been observed during testing, or is expected.
    
    Cc: John McCutchan <john@johnmccutchan.com>
    Cc: Robert Love <rlove@rlove.org>
    Cc: Eric Paris <eparis@parisplace.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a4bc6fc79f94c5b4f850aabca9c5249adc597094
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:08:20 2015 -0400

    mm: replace module_init usages with subsys_initcall in nommu.c
    
    Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals
    two more instances of module_init being used for code that can't
    possibly be modular, as CONFIG_MMU is either on or off.
    
    We replace them with subsys_initcall as per what was done in other
    mmu-enabled code.
    
    Note that direct use of __initcall is discouraged, vs.  one of the
    priority categorized subgroups.  As __initcall gets mapped onto
    device_initcall, our use of subsys_initcall (which makes sense for these
    files) will thus change this registration from level 6-device to level
    4-subsys (i.e.  slightly earlier).
    
    One might think that core_initcall (l2) or postcore_initcall (l3) would
    be more appropriate for anything in mm/ but if we look at the actual init
    functions themselves, we see they are just sysctl setup stuff, and
    hence the choice of subsys_initcall (l4) seems reasonable.  At the same
    time it minimizes the risk of changing the priority too drastically all
    at once.  We can adjust further in the future.
    
    Also, a couple instances of missing ";" at EOL are fixed.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-mm@kvack.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Sun Jun 14 16:55:25 2015 -0400

    cris: don't use module_init for non-modular core eeprom.c code
    
    The eeprom.c code is compiled based on the Kconfig setting
    ETRAX_I2C_EEPROM, which is bool.  So the code is either built in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Mikael Starvik <starvik@axis.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: linux-cris-kernel@axis.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4d38e5c48f4095be21343869ad741676ab4e518f
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Jun 5 22:17:18 2015 +0100

    tty/metag_da: Avoid module_init/module_exit in non-modular code
    
    The metag_da TTY driver can't get built as a module at the moment, but
    it still uses module_init() and module_exit(). Those macros are moving
    to module.h which isn't included by metag_da.c, which will result in the
    following build warnings (remarkably no build errors) and an apparent
    failure to boot as the TTY driver won't be loaded.
    
    drivers/tty/metag_da.c:660: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’
    drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:661: warning: data definition has no type or storage class
    drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’
    drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration
    drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
    drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
    drivers/tty/metag_da.c In function ‘dash_console_write’:
    drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type
    
    Instead of just adding the module.h include, now would be a good time to
    remove the use of these macros, replacing the module_init with
    device_initcall, and removing the exit function altogether since it
    isn't needed. If module support is added later the code can always be
    resurrected.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Cc: linux-metag@vger.kernel.org
    Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 791ed0bb5558dfdc4040563bd0b7dc24450fa732
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:51 2015 -0400

    drivers/clk: don't use module_init in clk-nomadik.c which is non-modular
    
    The clk-nomadik.o is built for ARCH_NOMADIK -- which is bool, and
    hence this code is either present or absent.  It will never be
    modular, so using module_init as an alias for __initcall can be
    somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Mike Turquette <mturquette@linaro.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    xtensa: don't use module_init for non-modular core network.c code
    
    The network.c code is piggybacking off of the arch independent
    CONFIG_NET, which is bool.  So the code is either built in or
    absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Chris Zankel <chris@zankel.net>
    Cc: Max Filippov <jcmvbkbc@gmail.com>
    Cc: Thomas Meyer <thomas@m3y3r.de>
    Cc: linux-xtensa@linux-xtensa.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit b205118bdb4b515b4b4f5058aa9f5a12668386c3
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    sh: don't use module_init in non-modular psw.c code
    
    The psw.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: linux-sh@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    mn10300: don't use module_init in non-modular flash.c code
    
    The flash.o is built for obj-y -- and hence this code is always
    present.  It will never be modular, so using module_init as an alias
    for __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Acked-by: David Howells <dhowells@redhat.com>
    Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
    Cc: linux-am33-list@redhat.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 15becabd89fa3fec6aa864fbd1b50b5b1871eee2
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc64: don't use module_init for non-modular core perf code
    
    The perf.c code depends on CONFIG_64BIT, so it is either built-in
    or absent.  It will never be modular, so using module_init as an
    alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.  Aside from it not making sense, it also
    causes a ~10% increase in CPP overhead due to module.h having a
    large list of headers itself -- for example compare line counts:
    
     device_initcall() and <linux/init.h>
    	20238 arch/parisc/kernel/perf.i
    
     module_init() and <linux/module.h>
    	22194 arch/parisc/kernel/perf.i
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: linux-parisc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit aed6850a1390c2b208b91b2fae0199fc14b94a26
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    parisc: don't use module_init for non-modular core pdc_cons code
    
    The pdc_cons.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: linux-parisc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 73de14e8cdc733bbc8eda006f813d5aa51511139
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    cris: don't use module_init for non-modular core intmem.c code
    
    The intmem.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Mikael Starvik <starvik@axis.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.com>
    Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: linux-cris-kernel@axis.com
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 2a177fd1d92f669f8f493a61e195ff4e3c50f95f
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:50 2015 -0400

    ia64: don't use module_init in non-modular sim/simscsi.c code
    
    The simscsi.o is built for HP_SIMSCSI -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    And since it can't be modular, we remove all the __exitcall
    stuff related to module_exit() -- it is dead code that won't
    ever be executed.
    
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: linux-ia64@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    ia64: don't use module_init for non-modular core kernel/mca.c code
    
    The mca.c code is always built in.  It will never be modular,
    so using module_init as an alias for __initcall is rather
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Direct use of __initcall is discouraged, vs prioritized ones.
    Use of device_initcall is consistent with what __initcall
    maps onto, and hence does not change the init order, making the
    impact of this change zero.   Should someone with real hardware
    for boot testing want to change it later to arch_initcall or
    something different, they can do that at a later date.
    
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: linux-ia64@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4a0ece7ceceab251e92e7f98e7926642a065727b
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    arm: don't use module_init in non-modular mach-vexpress/spc.c code
    
    The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Russell King <linux@arm.linux.org.uk>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a390a2f18147533359d4e45cb13438d42580da84
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: don't use module_init in non-modular 83xx suspend code
    
    The suspend.o is built for SUSPEND -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Scott Wood <scottwood@freescale.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 8f6b9512ceadc6bd52777c299111dc642b4c65b6
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    powerpc: use device_initcall for registering rtc devices
    
    Currently these two RTC devices are in core platform code
    where it is not possible for them to be modular.  It will
    never be modular, so using module_init as an alias for
    __initcall can be somewhat misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- they will remain at level 6 in initcall ordering.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Geoff Levand <geoff@infradead.org>
    Acked-by: Geoff Levand <geoff@infradead.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit d54b675a6b0007422dc13acbecdb1ca2b1a53aeb
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular devicetree.c code
    
    The devicetree.o is built for "OF" -- which is bool, and hence
    this code is either present or absent.  It will never be modular,
    so using module_init as an alias for __initcall can be somewhat
    misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:05:49 2015 -0400

    x86: don't use module_init in non-modular intel_mid_vrtc.c
    
    The X86_INTEL_MID option is bool, and hence this code is either
    present or absent.  It will never be modular, so using
    module_init as an alias for __initcall is rather misleading.
    
    Fix this up now, so that we can relocate module_init from
    init.h into module.h in the future.  If we don't do this, we'd
    have to add module.h to obviously non-modular code, and that
    would be a worse thing.
    
    Note that direct use of __initcall is discouraged, vs. one
    of the priority categorized subgroups.  As __initcall gets
    mapped onto device_initcall, our use of device_initcall
    directly in this change means that the runtime impact is
    zero -- it will remain at level 6 in initcall ordering.
    
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: x86@kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 7cac34370a4dde12e6430c2f0985926d4ef0f459
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri Jun 5 11:25:18 2015 -0400

    frv: add module.h to mb93090-mb00/flash.c to avoid compile fail
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 743492ccd53008736f169f242479bac6245f8379
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Wed Jun 3 15:45:21 2015 -0400

    drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
    
    This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ")
    and also contains modular function calls so it should explicitly include
    module.h to avoid compile breakage during pending header shuffles.
    
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Kukjin Kim <kgene@kernel.org>
    Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
    Cc: linux-pm@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-samsung-soc@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a7e9bc55cc144dc40e809e579bd932ef2ec324de
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/staging: include <module.h> for modular android tegra_ion code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "Arve Hj�nnev�g" <arve@android.com>
    Cc: Riley Andrews <riandrews@android.com>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Thierry Reding <thierry.reding@gmail.com>
    Cc: Alexandre Courbot <gnurou@gmail.com>
    Cc: devel@driverdev.osuosl.org
    Cc: linux-tegra@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 88775588b71d28a9020a7faa4ad95bbf76d8bb45
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 21:29:53 2015 -0400

    crypto/asymmetric_keys: pkcs7_key_type needs module.h
    
    This driver builds off of the tristate CONFIG_PKCS7_TEST_KEY and calls
    module_init and module_exit. So it should explicitly include module.h
    to avoid compile breakage during header shuffles done in the future.
    
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: linux-crypto@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 0bbad249a6a4934203b50d574f5d5f9f480b389e
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    sh: mach-highlander/psw.c is tristate and should use module.h
    
    This file is controlled by a tristate Kconfig option, and hence
    needs to include module.h so that it can get module_init() once
    we relocate it from init.h into module.h in the future.
    
    Note that module_exit() appears to be missing from the driver, so
    it is questionable whether it would actually work for a removal
    and reload cycle if it was configured for a modular build.
    
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: linux-sh@vger.kernel.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit ca1c8e93c37e5a5e27e6149cd3612eb2247e0e4a
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/regulator: include <module.h> for modular max77802 code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Liam Girdwood <lgirdwood@gmail.com>
    Cc: Mark Brown <broonie@kernel.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 5468f887bc861b2fe2fa24a44bc6a616a5d33a73
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:31 2015 -0400

    drivers/pcmcia: include <module.h> for modular xxs1500_ss code
    
    This file is built off of a tristate Kconfig option and also contains
    modular function calls so it should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    Cc: Wolfram Sang <wsa@the-dreams.de>
    Acked-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: linux-pcmcia@lists.infradead.org
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit a1a0bec593623f49740d7900e4b862c534f219bf
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/hsi: include <module.h> for modular omap_ssi code
    
    These files are built off of a tristate Kconfig option and also contain
    modular function calls so they should explicitly include module.h to
    avoid compile breakage during header shuffles done in the future.
    
    We change the one header file wich gives us coverage on both files:
       drivers/hsi/controllers/omap_ssi.c
       drivers/hsi/controllers/omap_ssi_port.c
    
    Cc: Sebastian Reichel <sre@kernel.org>
    Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 00fe614863eed7ca39fc72a307c6dff57b690476
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Fri May 1 20:02:30 2015 -0400

    drivers/gpu: in…
1fed0d9
@nirobin nirobin pushed a commit to nirobin/linux that referenced this pull request Jun 25, 2015
Russell King - ARM Linux ARM: VFP: fix emulation of second VFP instruction
Martin Storsjö reports that the sequence:

	ee312ac1	vsub.f32	s4, s3, s2
	ee702ac0	vsub.f32	s5, s1, s0
	e59f0028	ldr		r0, [pc, #40]
	ee111a90	vmov		r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

	VFP: bounce: trigger ee111a90 fpexc d0000780
	VFP: emulate: INST=0xee312ac1 SCR=0x00000000
	...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Cc: <stable@vger.kernel.org>
Reported-by: Martin Storsjö <martin@martin.st>
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
8aa4264
@damentz damentz referenced this pull request in zen-kernel/zen-kernel Jun 30, 2015
Steve Cornelius crypto: caam - improve initalization for context state saves
commit 6fd4b15 upstream.

Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
47c3d19
@dledford dledford added a commit to dledford/linux that referenced this pull request Jul 11, 2015
Haggai Eran IB/ucma: Fix lockdep warning in ucma_lock_files
The ucma_lock_files() locks the mut mutex on two files, e.g. for migrating
an ID. Use mutex_lock_nested() to prevent the warning below.

 =============================================
 [ INFO: possible recursive locking detected ]
 4.1.0-rc6-hmm+ #40 Tainted: G           O
 ---------------------------------------------
 pingpong_rpc_se/10260 is trying to acquire lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]

 but task is already holding lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&file->mut);
   lock(&file->mut);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by pingpong_rpc_se/10260:
  #0:  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 stack backtrace:
 CPU: 0 PID: 10260 Comm: pingpong_rpc_se Tainted: G           O    4.1.0-rc6-hmm+ #40
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
  ffff8801f85b63d0 ffff880195677b58 ffffffff81668f49 0000000000000001
  ffffffff825cbbe0 ffff880195677c38 ffffffff810bb991 ffff880100000000
  ffff880100000000 ffff880100000001 ffff8801f85b7010 ffffffff8121bee9
 Call Trace:
  [<ffffffff81668f49>] dump_stack+0x4f/0x6e
  [<ffffffff810bb991>] __lock_acquire+0x741/0x1820
  [<ffffffff8121bee9>] ? dput+0x29/0x320
  [<ffffffff810bcb38>] lock_acquire+0xc8/0x240
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff8166b901>] ? mutex_lock_nested+0x291/0x3e0
  [<ffffffff8166b6d5>] mutex_lock_nested+0x65/0x3e0
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff810baeed>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff8166b66e>] ? mutex_unlock+0xe/0x10
  [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffffa0478474>] ucma_write+0xa4/0xb0 [rdma_ucm]
  [<ffffffff81200674>] __vfs_write+0x34/0x100
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff810ec055>] ? current_kernel_time+0xc5/0xe0
  [<ffffffff812aa4d3>] ? security_file_permission+0x23/0x90
  [<ffffffff8120088d>] ? rw_verify_area+0x5d/0xe0
  [<ffffffff812009bb>] vfs_write+0xab/0x120
  [<ffffffff81201519>] SyS_write+0x59/0xd0
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff8166ffee>] system_call_fastpath+0x12/0x76

Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
e6aed0b
@dledford dledford added a commit to dledford/linux that referenced this pull request Jul 14, 2015
Haggai Eran IB/ucma: Fix lockdep warning in ucma_lock_files
The ucma_lock_files() locks the mut mutex on two files, e.g. for migrating
an ID. Use mutex_lock_nested() to prevent the warning below.

 =============================================
 [ INFO: possible recursive locking detected ]
 4.1.0-rc6-hmm+ #40 Tainted: G           O
 ---------------------------------------------
 pingpong_rpc_se/10260 is trying to acquire lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]

 but task is already holding lock:
  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(&file->mut);
   lock(&file->mut);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 1 lock held by pingpong_rpc_se/10260:
  #0:  (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm]

 stack backtrace:
 CPU: 0 PID: 10260 Comm: pingpong_rpc_se Tainted: G           O    4.1.0-rc6-hmm+ #40
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
  ffff8801f85b63d0 ffff880195677b58 ffffffff81668f49 0000000000000001
  ffffffff825cbbe0 ffff880195677c38 ffffffff810bb991 ffff880100000000
  ffff880100000000 ffff880100000001 ffff8801f85b7010 ffffffff8121bee9
 Call Trace:
  [<ffffffff81668f49>] dump_stack+0x4f/0x6e
  [<ffffffff810bb991>] __lock_acquire+0x741/0x1820
  [<ffffffff8121bee9>] ? dput+0x29/0x320
  [<ffffffff810bcb38>] lock_acquire+0xc8/0x240
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff8166b901>] ? mutex_lock_nested+0x291/0x3e0
  [<ffffffff8166b6d5>] mutex_lock_nested+0x65/0x3e0
  [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffff810baeed>] ? trace_hardirqs_on+0xd/0x10
  [<ffffffff8166b66e>] ? mutex_unlock+0xe/0x10
  [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm]
  [<ffffffffa0478474>] ucma_write+0xa4/0xb0 [rdma_ucm]
  [<ffffffff81200674>] __vfs_write+0x34/0x100
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff810ec055>] ? current_kernel_time+0xc5/0xe0
  [<ffffffff812aa4d3>] ? security_file_permission+0x23/0x90
  [<ffffffff8120088d>] ? rw_verify_area+0x5d/0xe0
  [<ffffffff812009bb>] vfs_write+0xab/0x120
  [<ffffffff81201519>] SyS_write+0x59/0xd0
  [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110
  [<ffffffff8166ffee>] system_call_fastpath+0x12/0x76

Signed-off-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
31b57b8
@kernelOfTruth kernelOfTruth added a commit to kernelOfTruth/linux that referenced this pull request Jul 15, 2015
Michal Hocko [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
 #0 [ffff88177374ac60] __schedule at ffffffff815ab152
 #1 [ffff88177374acb0] schedule at ffffffff815ab76e
 #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5
 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a
 #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6
 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5
 #6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f
 #7 [ffff88177374ae50] shrink_page_list at ffffffff81135445
 #8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845
 #9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead
 #10 [ffff88177374b150] shrink_zone at ffffffff811360c3
 #11 [ffff88177374b220] shrink_zones at ffffffff81136eff
 #12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f
 #13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 [ffff88177374b380] try_charge at ffffffff81189423
 #15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5
 #16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d
 #17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618
 #18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b
 #19 [ffff88177374b560] grow_dev_page at ffffffff811c8297
 #20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6
 #21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1
 #22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c
 #23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09
 #25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848
 #26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7
 #27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa
 #28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b
 #29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5
 #30 [ffff88177374bb20] do_writepages at ffffffff8112c490
 #31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199
 #32 [ffff88177374bb80] filemap_flush at ffffffff8112041c
 #33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1
 #34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91
 #35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32
 #36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5
 #37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc
 #38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e
 #39 [ffff88177374bf70] sys_rename at ffffffff8119e51e
 #40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away. The heuristic was introduced by e62e384
("memcg: prevent OOM with too many dirty pages") and it was applied
only when may_enter_fs was specified. The code has been changed by
c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
which has removed the __GFP_FS restriction with a reasoning that we
do not get into the fs code. But this is not sufficient apparently
because the fs doesn't necessarily submit pages marked PG_writeback
for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2)
before we go to wait on the writeback. The page fault path, which is the
only path that triggers memcg oom killer since 3.12, shouldn't require
GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue
which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable # 3.6+
[tytso@mit.edu: check for __GFP_FS rather than __GFP_IO]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
---
 mm/vmscan.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)
042e907
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Jul 17, 2015
Steve Cornelius crypto: caam - improve initalization for context state saves
[ Upstream commit 6fd4b15 ]

Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Cc: stable@vger.kernel.org
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
431685c
@shenki shenki pushed a commit to shenki/linux that referenced this pull request Jul 17, 2015
Steve Cornelius crypto: caam - improve initalization for context state saves
BugLink: http://bugs.launchpad.net/bugs/1471170

commit 6fd4b15 upstream.

Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final). Certain values in this state
block are loaded for processing using an inline-if, and when this
is done, the potential for uninitialized data can pose conflicts.
Therefore, this patch improves initialization of state data to
prevent false assignments using uninitialized data in the state block.

This patch addresses the following traceback, originating in
ahash_final_ctx(), although a problem like this could certainly
exhibit other symptoms:

kernel BUG at arch/arm/mm/dma-mapping.c:465!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP
Modules linked in:
CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
sp : e423fd98  ip : 60000013  fp : 0000001c
r10: e4191b84  r9 : 00000020  r8 : 00000009
r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 00000015
Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
Stack: (0xe423fd98 to 0xe4240000)
fd80:                                                       11807fd1 80048544
fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
[<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
[<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
[<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
[<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
[<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
[<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
[<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
[<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
[<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
[<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
---[ end trace d52a403a1d1eaa86 ]---

Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
cea8a60
@martinezjavier martinezjavier pushed a commit to martinezjavier/linux that referenced this pull request Jul 30, 2015
Michal Hocko mm, vmscan: do not wait for page writeback for GFP_NOFS allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
 #0 [ffff88177374ac60] __schedule at ffffffff815ab152
 #1 [ffff88177374acb0] schedule at ffffffff815ab76e
 #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5
 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a
 #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6
 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5
 #6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f
 #7 [ffff88177374ae50] shrink_page_list at ffffffff81135445
 #8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845
 #9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead
 #10 [ffff88177374b150] shrink_zone at ffffffff811360c3
 #11 [ffff88177374b220] shrink_zones at ffffffff81136eff
 #12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f
 #13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 [ffff88177374b380] try_charge at ffffffff81189423
 #15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5
 #16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d
 #17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618
 #18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b
 #19 [ffff88177374b560] grow_dev_page at ffffffff811c8297
 #20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6
 #21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1
 #22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c
 #23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09
 #25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848
 #26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7
 #27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa
 #28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b
 #29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5
 #30 [ffff88177374bb20] do_writepages at ffffffff8112c490
 #31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199
 #32 [ffff88177374bb80] filemap_flush at ffffffff8112041c
 #33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1
 #34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91
 #35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32
 #36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5
 #37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc
 #38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e
 #39 [ffff88177374bf70] sys_rename at ffffffff8119e51e
 #40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away. The heuristic was introduced by e62e384
("memcg: prevent OOM with too many dirty pages") and it was applied
only when may_enter_fs was specified. The code has been changed by
c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
which has removed the __GFP_FS restriction with a reasoning that we
do not get into the fs code. But this is not sufficient apparently
because the fs doesn't necessarily submit pages marked PG_writeback
for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2)
before we go to wait on the writeback. The page fault path, which is the
only path that triggers memcg oom killer since 3.12, shouldn't require
GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue
which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
[tytso@mit.edu: check for __GFP_FS rather than __GFP_IO]
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Marian Marinov <mm@1h.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>	[3.6+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
b2f3b4a
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Jul 31, 2015
Michal Hocko mm, vmscan: do not wait for page writeback for GFP_NOFS allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
 #0 [ffff88177374ac60] __schedule at ffffffff815ab152
 #1 [ffff88177374acb0] schedule at ffffffff815ab76e
 #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5
 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a
 #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6
 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5
 #6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f
 #7 [ffff88177374ae50] shrink_page_list at ffffffff81135445
 #8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845
 #9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead
 #10 [ffff88177374b150] shrink_zone at ffffffff811360c3
 #11 [ffff88177374b220] shrink_zones at ffffffff81136eff
 #12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f
 #13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 [ffff88177374b380] try_charge at ffffffff81189423
 #15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5
 #16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d
 #17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618
 #18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b
 #19 [ffff88177374b560] grow_dev_page at ffffffff811c8297
 #20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6
 #21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1
 #22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c
 #23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09
 #25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848
 #26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7
 #27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa
 #28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b
 #29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5
 #30 [ffff88177374bb20] do_writepages at ffffffff8112c490
 #31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199
 #32 [ffff88177374bb80] filemap_flush at ffffffff8112041c
 #33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1
 #34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91
 #35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32
 #36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5
 #37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc
 #38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e
 #39 [ffff88177374bf70] sys_rename at ffffffff8119e51e
 #40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away. The heuristic was introduced by e62e384
("memcg: prevent OOM with too many dirty pages") and it was applied
only when may_enter_fs was specified. The code has been changed by
c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
which has removed the __GFP_FS restriction with a reasoning that we
do not get into the fs code. But this is not sufficient apparently
because the fs doesn't necessarily submit pages marked PG_writeback
for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2)
before we go to wait on the writeback. The page fault path, which is the
only path that triggers memcg oom killer since 3.12, shouldn't require
GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue
which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
[tytso@mit.edu: check for __GFP_FS rather than __GFP_IO]
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Marian Marinov <mm@1h.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>	[3.6+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
b94cce9
@torvalds torvalds added a commit that referenced this pull request Aug 5, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ecf5fc6
@ddstreet ddstreet pushed a commit to ddstreet/linux that referenced this pull request Aug 6, 2015
mmotm auto import origin
GIT 4469942

commit fc1a812
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Aug 4 10:58:26 2015 -0600

    KVM: MTRR: Use default type for non-MTRR-covered gfn before WARN_ON
    
    The patch was munged on commit to re-order these tests resulting in
    excessive warnings when trying to do device assignment.  Return to
    original ordering: https://lkml.org/lkml/2015/7/15/769
    
    Fixes: 3e5d2fd ("KVM: MTRR: simplify kvm_mtrr_get_guest_memory_type")
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

commit ecf5fc6
Author: Michal Hocko <mhocko@suse.cz>
Date:   Tue Aug 4 14:36:58 2015 -0700

    mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
    
    Nikolay has reported a hang when a memcg reclaim got stuck with the
    following backtrace:
    
    PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
      #0 __schedule at ffffffff815ab152
      #1 schedule at ffffffff815ab76e
      #2 schedule_timeout at ffffffff815ae5e5
      #3 io_schedule_timeout at ffffffff815aad6a
      #4 bit_wait_io at ffffffff815abfc6
      #5 __wait_on_bit at ffffffff815abda5
      #6 wait_on_page_bit at ffffffff8111fd4f
      #7 shrink_page_list at ffffffff81135445
      #8 shrink_inactive_list at ffffffff81135845
      #9 shrink_lruvec at ffffffff81135ead
     #10 shrink_zone at ffffffff811360c3
     #11 shrink_zones at ffffffff81136eff
     #12 do_try_to_free_pages at ffffffff8113712f
     #13 try_to_free_mem_cgroup_pages at ffffffff811372be
     #14 try_charge at ffffffff81189423
     #15 mem_cgroup_try_charge at ffffffff8118c6f5
     #16 __add_to_page_cache_locked at ffffffff8112137d
     #17 add_to_page_cache_lru at ffffffff81121618
     #18 pagecache_get_page at ffffffff8112170b
     #19 grow_dev_page at ffffffff811c8297
     #20 __getblk_slow at ffffffff811c91d6
     #21 __getblk_gfp at ffffffff811c92c1
     #22 ext4_ext_grow_indepth at ffffffff8124565c
     #23 ext4_ext_create_new_leaf at ffffffff81246ca8
     #24 ext4_ext_insert_extent at ffffffff81246f09
     #25 ext4_ext_map_blocks at ffffffff8124a848
     #26 ext4_map_blocks at ffffffff8121a5b7
     #27 mpage_map_one_extent at ffffffff8121b1fa
     #28 mpage_map_and_submit_extent at ffffffff8121f07b
     #29 ext4_writepages at ffffffff8121f6d5
     #30 do_writepages at ffffffff8112c490
     #31 __filemap_fdatawrite_range at ffffffff81120199
     #32 filemap_flush at ffffffff8112041c
     #33 ext4_alloc_da_blocks at ffffffff81219da1
     #34 ext4_rename at ffffffff81229b91
     #35 ext4_rename2 at ffffffff81229e32
     #36 vfs_rename at ffffffff811a08a5
     #37 SYSC_renameat2 at ffffffff811a3ffc
     #38 sys_renameat2 at ffffffff811a408e
     #39 sys_rename at ffffffff8119e51e
     #40 system_call_fastpath at ffffffff815afa89
    
    Dave Chinner has properly pointed out that this is a deadlock in the
    reclaim code because ext4 doesn't submit pages which are marked by
    PG_writeback right away.
    
    The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
    with too many dirty pages") and it was applied only when may_enter_fs
    was specified.  The code has been changed by c3b94f4 ("memcg:
    further prevent OOM with too many dirty pages") which has removed the
    __GFP_FS restriction with a reasoning that we do not get into the fs
    code.  But this is not sufficient apparently because the fs doesn't
    necessarily submit pages marked PG_writeback for IO right away.
    
    ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
    submit the bio.  Instead it tries to map more pages into the bio and
    mpage_map_one_extent might trigger memcg charge which might end up
    waiting on a page which is marked PG_writeback but hasn't been submitted
    yet so we would end up waiting for something that never finishes.
    
    Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
    before we go to wait on the writeback.  The page fault path, which is
    the only path that triggers memcg oom killer since 3.12, shouldn't
    require GFP_NOFS and so we shouldn't reintroduce the premature OOM
    killer issue which was originally addressed by the heuristic.
    
    As per David Chinner the xfs is doing similar thing since 2.6.15 already
    so ext4 is not the only affected filesystem.  Moreover he notes:
    
    : For example: IO completion might require unwritten extent conversion
    : which executes filesystem transactions and GFP_NOFS allocations. The
    : writeback flag on the pages can not be cleared until unwritten
    : extent conversion completes. Hence memory reclaim cannot wait on
    : page writeback to complete in GFP_NOFS context because it is not
    : safe to do so, memcg reclaim or otherwise.
    
    Cc: stable@vger.kernel.org # 3.9+
    [tytso@mit.edu: corrected the control flow]
    Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
    Reported-by: Nikolay Borisov <kernel@kyup.com>
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit fcdf31a
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Fri Jul 31 14:30:42 2015 +0100

    xen/events/fifo: Handle linked events when closing a port
    
    An event channel bound to a CPU that was offlined may still be linked
    on that CPU's queue.  If this event channel is closed and reused,
    subsequent events will be lost because the event channel is never
    unlinked and thus cannot be linked onto the correct queue.
    
    When a channel is closed and the event is still linked into a queue,
    ensure that it is unlinked before completing.
    
    If the CPU to which the event channel bound is online, spin until the
    event is handled by that CPU. If that CPU is offline, it can't handle
    the event, so clear the event queue during the close, dropping the
    events.
    
    This fixes the missing interrupts (and subsequent disk stalls etc.)
    when offlining a CPU.
    
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>

commit 6ea76f3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Aug 3 17:24:11 2015 +0200

    drm/atomic-helpers: Make encoder picking more robust
    
    We've had a few issues with atomic where subtle bugs in the encoder
    picking logic lead to accidental self-stealing of the encoder,
    resulting in a NULL connector_state->crtc in update_connector_routing
    and subsequent.
    
    Linus applied some duct-tape for an mst regression in
    
    commit 27667f4
    Author: Linus Torvalds <torvalds@linux-foundation.org>
    Date:   Wed Jul 29 22:18:16 2015 -0700
    
        i915: temporary fix for DP MST docking station NULL pointer dereference
    
    But that was incomplete (the code will still oops when debuggin is
    enabled) and mangled the state even further. So instead WARN and bail
    out as the more future-proof option.
    
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 42639ba
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Aug 3 17:24:10 2015 +0200

    drm/dp-mst: Remove debug WARN_ON
    
    Apparently been in there since forever and fairly easy to hit when
    hotplugging really fast. I can do that since my mst hub has a manual
    button to flick the hpd line for reprobing. The resulting WARNING spam
    isn't pretty.
    
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 459485a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Aug 3 17:24:09 2015 +0200

    drm/i915: Fixup dp mst encoder selection
    
    In
    
    commit 8c7b5cc
    Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
    Date:   Tue Apr 21 17:13:19 2015 +0300
    
        drm/i915: Use atomic helpers for computing changed flags
    
    we've switched over to the atomic version to compute the
    crtc->encoder->connector routing from the i915 variant. That one
    relies upon the ->best_encoder callback, but the i915-private version
    relied upon intel_find_encoder. Which didn't matter except for dp mst,
    where the encoder depends upon the selected crtc.
    
    Fix this functional bug by implemented a correct atomic-state based
    encoder selector for dp mst.
    
    Note that we can't get rid of the legacy best_encoder callback since
    the fbdev emulation uses that still. That means it's incorrect there
    still, but that's been the case ever since i915 dp mst support was
    merged so not a regression. Best to fix that by converting fbdev over
    to atomic too.
    
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 3b8a684
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Aug 3 17:24:08 2015 +0200

    drm/atomic-helper: Add an atomice best_encoder callback
    
    With legacy helpers all the routing was already set up when calling
    best_encoder and so could be inspected. But with atomic it's staged,
    hence we need a new atomic compliant callback for drivers which need
    to inspect the requested state and can't just decided the best encoder
    statically.
    
    This is needed to fix up i915 dp mst where we need to pick the right
    encoder depending upon the requested CRTC for the connector.
    
    v2: Don't forget to amend the kerneldoc
    
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

commit 5413fcd
Author: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Date:   Mon Aug 3 12:40:51 2015 +0200

    Adding YAMA hooks also when YAMA is not stacked.
    
    Without this patch YAMA will not work at all if it is chosen
    as the primary LSM instead of being "stacked".
    
    Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: James Morris <james.l.morris@oracle.com>

commit 49895bc
Author: NeilBrown <neilb@suse.com>
Date:   Mon Aug 3 17:09:57 2015 +1000

    md/raid5: don't let shrink_slab shrink too far.
    
    I have a report of drop_one_stripe() called from
    raid5_cache_scan() apparently finding ->max_nr_stripes == 0.
    
    This should not be allowed.
    
    So add a test to keep max_nr_stripes above min_nr_stripes.
    
    Also use a 'mask' rather than a 'mod' in drop_one_stripe
    to ensure 'hash' is valid even if max_nr_stripes does reach zero.
    
    
    Fixes: edbe83a ("md/raid5: allow the stripe_cache to grow and shrink.")
    Cc: stable@vger.kernel.org (4.1 - please release with 2d5b569)
    Reported-by: Tomas Papan <tomas.papan@gmail.com>
    Signed-off-by: NeilBrown <neilb@suse.com>

commit b6878d9
Author: Benjamin Randazzo <benjamin@randazzo.fr>
Date:   Sat Jul 25 16:36:50 2015 +0200

    md: use kzalloc() when bitmap is disabled
    
    In drivers/md/md.c get_bitmap_file() uses kmalloc() for creating a
    mdu_bitmap_file_t called "file".
    
    5769         file = kmalloc(sizeof(*file), GFP_NOIO);
    5770         if (!file)
    5771                 return -ENOMEM;
    
    This structure is copied to user space at the end of the function.
    
    5786         if (err == 0 &&
    5787             copy_to_user(arg, file, sizeof(*file)))
    5788                 err = -EFAULT
    
    But if bitmap is disabled only the first byte of "file" is initialized
    with zero, so it's possible to read some bytes (up to 4095) of kernel
    space memory from user space. This is an information leak.
    
    5775         /* bitmap disabled, zero the first byte and copy out */
    5776         if (!mddev->bitmap_info.file)
    5777                 file->pathname[0] = '\0';
    
    Signed-off-by: Benjamin Randazzo <benjamin@randazzo.fr>
    Signed-off-by: NeilBrown <neilb@suse.com>

commit 423f04d
Author: NeilBrown <neilb@suse.com>
Date:   Mon Jul 27 11:48:52 2015 +1000

    md/raid1: extend spinlock to protect raid1_end_read_request against inconsistencies
    
    raid1_end_read_request() assumes that the In_sync bits are consistent
    with the ->degaded count.
    raid1_spare_active updates the In_sync bit before the ->degraded count
    and so exposes an inconsistency, as does error()
    So extend the spinlock in raid1_spare_active() and error() to hide those
    inconsistencies.
    
    This should probably be part of
      Commit: 34cab6f ("md/raid1: fix test for 'was read error from
      last working device'.")
    as it addresses the same issue.  It fixes the same bug and should go
    to -stable for same reasons.
    
    Fixes: 7607305 ("md/raid1: clean up read_balance.")
    Cc: stable@vger.kernel.org (v3.0+)
    Signed-off-by: NeilBrown <neilb@suse.com>

commit e331146
Author: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date:   Mon Jul 27 17:30:48 2015 +0300

    i2c: fix leaked device refcount on of_find_i2c_* error path
    
    If of_find_i2c_device_by_node() or of_find_i2c_adapter_by_node() find
    a device by node, but its type does not match, a reference to that
    device is still held. This change fixes the problem.
    
    Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 8fcd461
Author: Jeff Layton <jlayton@poochiereds.net>
Date:   Thu Jul 30 06:57:46 2015 -0400

    nfsd: do nfs4_check_fh in nfs4_check_file instead of nfs4_check_olstateid
    
    Currently, preprocess_stateid_op calls nfs4_check_olstateid which
    verifies that the open stateid corresponds to the current filehandle in the
    call by calling nfs4_check_fh.
    
    If the stateid is a NFS4_DELEG_STID however, then no such check is done.
    This could cause incorrect enforcement of permissions, because the
    nfsd_permission() call in nfs4_check_file uses current the current
    filehandle, but any subsequent IO operation will use the file descriptor
    in the stateid.
    
    Move the call to nfs4_check_fh into nfs4_check_file instead so that it
    can be done for all stateid types.
    
    Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
    Cc: stable@vger.kernel.org
    [bfields: moved fh check to avoid NULL deref in special stateid case]
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit e952849
Author: Masanari Iida <standby24x7@gmail.com>
Date:   Tue Jul 28 20:11:23 2015 +0900

    i2c: Fix typo in i2c-bfin-twi.c
    
    This patch fix some typos found in a printk message and
    MODULE_DESCRIPTION.
    
    Signed-off-by: Masanari Iida <standby24x7@gmail.com>
    Acked-by: Sonic Zhang <sonic.zhang@analog.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 828e66c
Author: Jan Luebbe <jlu@pengutronix.de>
Date:   Wed Jul 8 16:35:27 2015 +0200

    i2c: omap: fix bus recovery setup
    
    At least on the AM335x, enabling OMAP_I2C_SYSTEST_ST_EN is not enough to
    allow direct access to the SCL and SDA pins. In addition to ST_EN, we
    need to set the TMODE to 0b11 (Loop back & SDA/SCL IO mode select).
    Also, as the reset values of SCL_O and SDA_O are 0 (which means "drive
    low level"), we need to set them to 1 (which means "high-impedance") to
    avoid unwanted changes on the pins.
    
    As a precaution, reset all these bits to their default values after
    recovery is complete.
    
    Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
    Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 8b06260
Author: Jan Luebbe <jlu@pengutronix.de>
Date:   Wed Jul 8 16:35:06 2015 +0200

    i2c: core: only use set_scl for bus recovery after calling prepare_recovery
    
    Using set_scl may be ineffective before calling the driver specific
    prepare_recovery callback, which might change into a test mode. So
    instead of setting SCL in i2c_generic_scl_recovery, move it to
    i2c_generic_recovery (after the optional prepare_recovery).
    
    Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit d12c0aa
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Mon Jul 27 00:18:51 2015 +0300

    misc: eeprom: at24: clean up at24_bin_write()
    
    The change removes redundant sysfs binary file boundary check, since
    this task is already done on caller side in fs/sysfs/file.c
    
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 1f02329
Author: Vladimir Zapolskiy <vz@mleia.com>
Date:   Mon Jul 27 00:16:31 2015 +0300

    i2c: slave eeprom: clean up sysfs bin attribute read()/write()
    
    The change removes redundant sysfs binary file boundary checks,
    since this task is already done on caller side in fs/sysfs/file.c
    
    Note, on file size overflow read() now returns 0, and this is a
    correct and expected EOF notification according to POSIX.
    
    Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

commit 2761713
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Thu Jul 16 17:36:11 2015 +0300

    rbd: fix copyup completion race
    
    For write/discard obj_requests that involved a copyup method call, the
    opcode of the first op is CEPH_OSD_OP_CALL and the ->callback is
    rbd_img_obj_copyup_callback().  The latter frees copyup pages, sets
    ->xferred and delegates to rbd_img_obj_callback(), the "normal" image
    object callback, for reporting to block layer and putting refs.
    
    rbd_osd_req_callback() however treats CEPH_OSD_OP_CALL as a trivial op,
    which means obj_request is marked done in rbd_osd_trivial_callback(),
    *before* ->callback is invoked and rbd_img_obj_copyup_callback() has
    a chance to run.  Marking obj_request done essentially means giving
    rbd_img_obj_callback() a license to end it at any moment, so if another
    obj_request from the same img_request is being completed concurrently,
    rbd_img_obj_end_request() may very well be called on such prematurally
    marked done request:
    
    <obj_request-1/2 reply>
    handle_reply()
      rbd_osd_req_callback()
        rbd_osd_trivial_callback()
        rbd_obj_request_complete()
        rbd_img_obj_copyup_callback()
        rbd_img_obj_callback()
                                        <obj_request-2/2 reply>
                                        handle_reply()
                                          rbd_osd_req_callback()
                                            rbd_osd_trivial_callback()
          for_each_obj_request(obj_request->img_request) {
            rbd_img_obj_end_request(obj_request-1/2)
            rbd_img_obj_end_request(obj_request-2/2) <--
          }
    
    Calling rbd_img_obj_end_request() on such a request leads to trouble,
    in particular because its ->xfferred is 0.  We report 0 to the block
    layer with blk_update_request(), get back 1 for "this request has more
    data in flight" and then trip on
    
        rbd_assert(more ^ (which == img_request->obj_request_count));
    
    with rhs (which == ...) being 1 because rbd_img_obj_end_request() has
    been called for both requests and lhs (more) being 1 because we haven't
    got a chance to set ->xfferred in rbd_img_obj_copyup_callback() yet.
    
    To fix this, leverage that rbd wants to call class methods in only two
    cases: one is a generic method call wrapper (obj_request is standalone)
    and the other is a copyup (obj_request is part of an img_request).  So
    make a dedicated handler for CEPH_OSD_OP_CALL and directly invoke
    rbd_img_obj_copyup_callback() from it if obj_request is part of an
    img_request, similar to how CEPH_OSD_OP_READ handler invokes
    rbd_img_obj_request_read_callback().
    
    Since rbd_img_obj_copyup_callback() is now being called from the OSD
    request callback (only), it is renamed to rbd_osd_copyup_callback().
    
    Cc: Alex Elder <elder@linaro.org>
    Cc: stable@vger.kernel.org # 3.10+, needs backporting for < 3.18
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Alex Elder <elder@linaro.org>

commit fc927cd
Author: Yan, Zheng <zyan@redhat.com>
Date:   Mon Jul 20 09:50:58 2015 +0800

    ceph: always re-send cap flushes when MDS recovers
    
    commit e548e9b makes the kclient
    only re-send cap flush once during MDS failover. If the kclient sends
    a cap flush after MDS enters reconnect stage but before MDS recovers.
    The kclient will skip re-sending the same cap flush when MDS recovers.
    
    This causes problem for newly created inode. The MDS handles cap
    flushes before replaying unsafe requests, so it's possible that MDS
    find corresponding inode is missing when handling cap flush. The fix
    is reverting to old behaviour: always re-send when MDS recovers
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit f6762cb
Author: Yan, Zheng <zyan@redhat.com>
Date:   Tue Jul 7 16:18:46 2015 +0800

    ceph: fix ceph_encode_locks_to_buffer()
    
    posix locks should be in ctx->flc_posix list
    
    Signed-off-by: Yan, Zheng <zyan@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

commit 586b7cc
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Tue Jul 28 15:03:05 2015 +0200

    KVM: s390: Fix hang VCPU hang/loop regression
    
    commit 785dbef ("KVM: s390: optimize round trip time in request
    handling") introduced a regression. This regression was seen with
    CPU hotplug in the guest and switching between 1 or 2 CPUs. This will
    set/reset the IBS control via synced request.
    
    Whenever we make a synced request, we first set the vcpu->requests
    bit and then block the vcpu. The handler, on the other hand, unblocks
    itself, processes vcpu->requests (by clearing them) and unblocks itself
    once again.
    
    Now, if the requester sleeps between setting of vcpu->requests and
    blocking, the handler will clear the vcpu->requests bit and try to
    unblock itself (although no bit is set). When the requester wakes up,
    it blocks the VCPU and we have a blocked VCPU without requests.
    
    Solution is to always unset the block bit.
    
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
    Fixes: 785dbef ("KVM: s390: optimize round trip time in request handling")

commit fe0d34d
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Jul 29 05:52:14 2015 +0930

    module: weaken locking assertion for oops path.
    
    We don't actually hold the module_mutex when calling find_module_all
    from module_kallsyms_lookup_name: that's because it's used by the oops
    code and we don't want to deadlock.
    
    However, access to the list read-only is safe if preempt is disabled,
    so we can weaken the assertion.  Keep a strong version for external
    callers though.
    
    Fixes: 0be964b ("module: Sanitize RCU usage and locking")
    Reported-by: He Kuang <hekuang@huawei.com>
    Cc: stable@kernel.org
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

commit 17fb874
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Jul 24 13:13:30 2015 +0200

    hwrng: core - correct error check of kthread_run call
    
    The kthread_run() function can return two different error values
    but the hwrng core only checks for -ENOMEM. If the other error
    value -EINTR is returned it is assigned to hwrng_fill and later
    used on a kthread_stop() call which naturally crashes.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit f898c52
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Jul 22 18:05:35 2015 +0800

    crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer
    
    This patch removes a bogus BUG_ON in the ablkcipher path that
    triggers when the destination buffer is different from the source
    buffer and is scattered.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 6f043b5
Author: Tadeusz Struk <tadeusz.struk@intel.com>
Date:   Tue Jul 21 22:07:47 2015 -0700

    crypto: qat - Fix invalid synchronization between register/unregister sym algs
    
    The synchronization method used atomic was bogus.
    Use a proper synchronization with mutex.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 3d1450d
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Jul 7 20:26:07 2015 +0200

    Makefile: Force gzip and xz on module install
    
    Running `make modules_install` ordinarily will overwrite existing
    modules. This is the desired behavior, and is how pretty much every
    other `make install` target works.
    
    However, if CONFIG_MODULE_COMPRESS is enabled, modules are passed
    through gzip and xz which then do the file writing. Both gzip and xz
    will error out if the file already exists, unless -f is passed.
    
    This patch adds -f so that the behavior is uniform.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Michal Marek <mmarek@suse.com>

commit 6dd3f13
Author: Michal Marek <mmarek@suse.com>
Date:   Thu Jul 16 18:23:53 2015 +0200

    kbuild: Do not pick up ARCH_{CPP,A,C}FLAGS from the environment
    
    Initialize the ARCH_* overrides before including the arch Makefile, to
    avoid picking up the values from the environment. The variables can
    still be overriden on the make command line, but this won't happen
    by accident.
    
    Signed-off-by: Michal Marek <mmarek@suse.com>

commit 1ca4b88
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Thu Jul 9 17:38:26 2015 +0800

    nfsd: Fix a file leak on nfsd4_layout_setlease failure
    
    If nfsd4_layout_setlease fails, nfsd will not put ls->ls_file.
    
    Fix commit c5c707f "nfsd: implement pNFS layout recalls".
    
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit c2227a3
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Tue Jul 7 10:16:37 2015 +0800

    nfsd: Drop BUG_ON and ignore SECLABEL on absent filesystem
    
    On an absent filesystem (one served by another server), we need to be
    able to handle requests for certain attributest (like fs_locations, so
    the client can find out which server does have the filesystem), but
    others we can't.
    
    We forgot to take that into account when adding another attribute
    bitmask work for the SECURITY_LABEL attribute.
    
    There an export entry with the "refer" option can result in:
    
    [   88.414272] kernel BUG at fs/nfsd/nfs4xdr.c:2249!
    [   88.414828] invalid opcode: 0000 [#1] SMP
    [   88.415368] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nfsd xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi iosf_mbi ppdev btrfs coretemp crct10dif_pclmul crc32_pclmul crc32c_intel xor ghash_clmulni_intel raid6_pq vmw_balloon parport_pc parport i2c_piix4 shpchp vmw_vmci acpi_cpufreq auth_rpcgss nfs_acl lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi mptscsih serio_raw mptbase e1000 scsi_transport_spi ata_generic pata_acpi [last unloaded: nfsd]
    [   88.417827] CPU: 0 PID: 2116 Comm: nfsd Not tainted 4.0.7-300.fc22.x86_64 #1
    [   88.418448] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
    [   88.419093] task: ffff880079146d50 ti: ffff8800785d8000 task.ti: ffff8800785d8000
    [   88.419729] RIP: 0010:[<ffffffffa04b3c10>]  [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd]
    [   88.420376] RSP: 0000:ffff8800785db998  EFLAGS: 00010206
    [   88.421027] RAX: 0000000000000001 RBX: 000000000018091a RCX: ffff88006668b980
    [   88.421676] RDX: 00000000fffef7fc RSI: 0000000000000000 RDI: ffff880078d05000
    [   88.422315] RBP: ffff8800785dbb58 R08: ffff880078d043f8 R09: ffff880078d4a000
    [   88.422968] R10: 0000000000010000 R11: 0000000000000002 R12: 0000000000b0a23a
    [   88.423612] R13: ffff880078d05000 R14: ffff880078683100 R15: ffff88006668b980
    [   88.424295] FS:  0000000000000000(0000) GS:ffff88007c600000(0000) knlGS:0000000000000000
    [   88.424944] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   88.425597] CR2: 00007f40bc370f90 CR3: 0000000035af5000 CR4: 00000000001407f0
    [   88.426285] Stack:
    [   88.426921]  ffff8800785dbaa8 ffffffffa049e4af ffff8800785dba08 ffffffff813298f0
    [   88.427585]  ffff880078683300 ffff8800769b0de8 0000089d00000001 0000000087f805e0
    [   88.428228]  ffff880000000000 ffff880079434a00 0000000000000000 ffff88006668b980
    [   88.428877] Call Trace:
    [   88.429527]  [<ffffffffa049e4af>] ? exp_get_by_name+0x7f/0xb0 [nfsd]
    [   88.430168]  [<ffffffff813298f0>] ? inode_doinit_with_dentry+0x210/0x6a0
    [   88.430807]  [<ffffffff8123833e>] ? d_lookup+0x2e/0x60
    [   88.431449]  [<ffffffff81236133>] ? dput+0x33/0x230
    [   88.432097]  [<ffffffff8123f214>] ? mntput+0x24/0x40
    [   88.432719]  [<ffffffff812272b2>] ? path_put+0x22/0x30
    [   88.433340]  [<ffffffffa049ac87>] ? nfsd_cross_mnt+0xb7/0x1c0 [nfsd]
    [   88.433954]  [<ffffffffa04b54e0>] nfsd4_encode_dirent+0x1b0/0x3d0 [nfsd]
    [   88.434601]  [<ffffffffa04b5330>] ? nfsd4_encode_getattr+0x40/0x40 [nfsd]
    [   88.435172]  [<ffffffffa049c991>] nfsd_readdir+0x1c1/0x2a0 [nfsd]
    [   88.435710]  [<ffffffffa049a530>] ? nfsd_direct_splice_actor+0x20/0x20 [nfsd]
    [   88.436447]  [<ffffffffa04abf30>] nfsd4_encode_readdir+0x120/0x220 [nfsd]
    [   88.437011]  [<ffffffffa04b58cd>] nfsd4_encode_operation+0x7d/0x190 [nfsd]
    [   88.437566]  [<ffffffffa04aa6dd>] nfsd4_proc_compound+0x24d/0x6f0 [nfsd]
    [   88.438157]  [<ffffffffa0496103>] nfsd_dispatch+0xc3/0x220 [nfsd]
    [   88.438680]  [<ffffffffa006f0cb>] svc_process_common+0x43b/0x690 [sunrpc]
    [   88.439192]  [<ffffffffa0070493>] svc_process+0x103/0x1b0 [sunrpc]
    [   88.439694]  [<ffffffffa0495a57>] nfsd+0x117/0x190 [nfsd]
    [   88.440194]  [<ffffffffa0495940>] ? nfsd_destroy+0x90/0x90 [nfsd]
    [   88.440697]  [<ffffffff810bb728>] kthread+0xd8/0xf0
    [   88.441260]  [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
    [   88.441762]  [<ffffffff81789e58>] ret_from_fork+0x58/0x90
    [   88.442322]  [<ffffffff810bb650>] ? kthread_worker_fn+0x180/0x180
    [   88.442879] Code: 0f 84 93 05 00 00 83 f8 ea c7 85 a0 fe ff ff 00 00 27 30 0f 84 ba fe ff ff 85 c0 0f 85 a5 fe ff ff e9 e3 f9 ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 be 04 00 00 00 4c 89 ef 4c 89 8d 68 fe
    [   88.444052] RIP  [<ffffffffa04b3c10>] nfsd4_encode_fattr+0x820/0x1f00 [nfsd]
    [   88.444658]  RSP <ffff8800785db998>
    [   88.445232] ---[ end trace 6cb9d0487d94a29f ]---
    
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 929423f
Author: Juergen Gross <jgross@suse.com>
Date:   Mon Jul 20 13:49:39 2015 +0200

    xen: release lock occasionally during ballooning
    
    When dom0 is being ballooned balloon_process() will hold the balloon
    mutex until it is finished. This will block e.g. creation of new
    domains as the device backends for the new domain need some
    autoballooned pages for the ring buffers.
    
    Avoid this by releasing the balloon mutex from time to time during
    ballooning. Adjust the comment above balloon_process() regarding
    multiple instances of balloon_process().
    
    Instead of open coding it, just use cond_resched().
    
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>

commit c9ddbac
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Tue Jul 14 18:27:46 2015 -0500

    PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition
    
    09a2c73 ("PCI: Remove unused PCI_MSIX_FLAGS_BIRMASK definition")
    removed PCI_MSIX_FLAGS_BIRMASK from an exported header because it was
    unused in the kernel.  But that breaks user programs that were using it
    (QEMU in particular).
    
    Restore the PCI_MSIX_FLAGS_BIRMASK definition.
    
    [bhelgaas: changelog]
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org	# v3.13+

commit 30b03d0
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date:   Fri Jun 26 03:28:24 2015 +0200

    xen/gntdevt: Fix race condition in gntdev_release()
    
    While gntdev_release() is called the MMU notifier is still registered
    and can traverse priv->maps list even if no pages are mapped (which is
    the case -- gntdev_release() is called after all). But
    gntdev_release() will clear that list, so make sure that only one of
    those things happens at the same time.
    
    Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
4d39819
@0xAX 0xAX pushed a commit to 0xAX/linux that referenced this pull request Aug 15, 2015
Michal Hocko mm, vmscan: do not wait for page writeback for GFP_NOFS allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:
PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
 #0 [ffff88177374ac60] __schedule at ffffffff815ab152
 #1 [ffff88177374acb0] schedule at ffffffff815ab76e
 #2 [ffff88177374acd0] schedule_timeout at ffffffff815ae5e5
 #3 [ffff88177374ad70] io_schedule_timeout at ffffffff815aad6a
 #4 [ffff88177374ada0] bit_wait_io at ffffffff815abfc6
 #5 [ffff88177374adb0] __wait_on_bit at ffffffff815abda5
 #6 [ffff88177374ae00] wait_on_page_bit at ffffffff8111fd4f
 #7 [ffff88177374ae50] shrink_page_list at ffffffff81135445
 #8 [ffff88177374af50] shrink_inactive_list at ffffffff81135845
 #9 [ffff88177374b060] shrink_lruvec at ffffffff81135ead
 #10 [ffff88177374b150] shrink_zone at ffffffff811360c3
 #11 [ffff88177374b220] shrink_zones at ffffffff81136eff
 #12 [ffff88177374b2a0] do_try_to_free_pages at ffffffff8113712f
 #13 [ffff88177374b300] try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 [ffff88177374b380] try_charge at ffffffff81189423
 #15 [ffff88177374b430] mem_cgroup_try_charge at ffffffff8118c6f5
 #16 [ffff88177374b470] __add_to_page_cache_locked at ffffffff8112137d
 #17 [ffff88177374b4e0] add_to_page_cache_lru at ffffffff81121618
 #18 [ffff88177374b510] pagecache_get_page at ffffffff8112170b
 #19 [ffff88177374b560] grow_dev_page at ffffffff811c8297
 #20 [ffff88177374b5c0] __getblk_slow at ffffffff811c91d6
 #21 [ffff88177374b600] __getblk_gfp at ffffffff811c92c1
 #22 [ffff88177374b630] ext4_ext_grow_indepth at ffffffff8124565c
 #23 [ffff88177374b690] ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 [ffff88177374b6e0] ext4_ext_insert_extent at ffffffff81246f09
 #25 [ffff88177374b750] ext4_ext_map_blocks at ffffffff8124a848
 #26 [ffff88177374b870] ext4_map_blocks at ffffffff8121a5b7
 #27 [ffff88177374b910] mpage_map_one_extent at ffffffff8121b1fa
 #28 [ffff88177374b950] mpage_map_and_submit_extent at ffffffff8121f07b
 #29 [ffff88177374b9b0] ext4_writepages at ffffffff8121f6d5
 #30 [ffff88177374bb20] do_writepages at ffffffff8112c490
 #31 [ffff88177374bb30] __filemap_fdatawrite_range at ffffffff81120199
 #32 [ffff88177374bb80] filemap_flush at ffffffff8112041c
 #33 [ffff88177374bb90] ext4_alloc_da_blocks at ffffffff81219da1
 #34 [ffff88177374bbb0] ext4_rename at ffffffff81229b91
 #35 [ffff88177374bcd0] ext4_rename2 at ffffffff81229e32
 #36 [ffff88177374bce0] vfs_rename at ffffffff811a08a5
 #37 [ffff88177374bd60] SYSC_renameat2 at ffffffff811a3ffc
 #38 [ffff88177374bf60] sys_renameat2 at ffffffff811a408e
 #39 [ffff88177374bf70] sys_rename at ffffffff8119e51e
 #40 [ffff88177374bf80] system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away. The heuristic was introduced by e62e384
("memcg: prevent OOM with too many dirty pages") and it was applied
only when may_enter_fs was specified. The code has been changed by
c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
which has removed the __GFP_FS restriction with a reasoning that we
do not get into the fs code. But this is not sufficient apparently
because the fs doesn't necessarily submit pages marked PG_writeback
for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio. Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by __GFP_FS check (for case 2)
before we go to wait on the writeback. The page fault path, which is the
only path that triggers memcg oom killer since 3.12, shouldn't require
GFP_NOFS and so we shouldn't reintroduce the premature OOM killer issue
which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem. Moreover he notes:
: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
[tytso@mit.edu: check for __GFP_FS rather than __GFP_IO]
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reported-by: Nikolay Borisov <kernel@kyup.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Marian Marinov <mm@1h.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>	[3.6+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
794510a
@0xAX 0xAX pushed a commit to 0xAX/linux that referenced this pull request Aug 15, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit ecf5fc6)
7cfd164
@quinte17 quinte17 pushed a commit to quinte17/linux-stable that referenced this pull request Aug 17, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
commit ecf5fc6 upstream.

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
7f488aa
@otavio otavio pushed a commit to Freescale/linux-fslc that referenced this pull request Aug 21, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
commit ecf5fc6 upstream.

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
0fa4301
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Aug 26, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
commit ecf5fc6 upstream.

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
022d35a
@coldnew coldnew pushed a commit that referenced this pull request Sep 6, 2015
Xianzhong ENGR00309915 [#1087] enhanced video memory mutex
this patch can fix NULL pointer issue in GPU kernel driver with the following log

[<7f240438>] (gckEVENT_AddList+0x0/0x810 [galcore]) from [<7f239ebc>] (gckCOMMAND_Commit+0xf28/0x118c [galcore])
[<7f238f94>] (gckCOMMAND_Commit+0x0/0x118c [galcore]) from [<7f2362dc>] (gckKERNEL_Dispatch+0x120c/0x24e4 [galcore])
[<7f2350d0>] (gckKERNEL_Dispatch+0x0/0x24e4 [galcore]) from [<7f222280>] (drv_ioctl+0x390/0x540 [galcore])
[<7f221ef0>] (drv_ioctl+0x0/0x540 [galcore]) from [<800facd0>] (vfs_ioctl+0x30/0x44)

The false code is at 0x217bc where the 0-pointer happens (r3 = 0)

gcuVIDMEM_NODE_PTR node = (gcuVIDMEM_NODE_PTR)(gcmUINT64_TO_PTR(Record->info.u.FreeVideoMemory.node));
   217b8:                e5953028             ldr           r3, [r5, #40]         ; 0x28

                if (node->VidMem.memory->object.type == gcvOBJ_VIDMEM)
   217bc:                e5932000             ldr           r2, [r3]
   217c0:                e5922000             ldr           r2, [r2]
   217c4:                e152000a             cmp       r2, sl
                {
                     gcmkVERIFY_OK(gckKERNEL_RemoveProcessDB(Event->kernel,

Date: Apr 23, 2014
Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
fcde214
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Sep 7, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
[ Upstream commit ecf5fc6 ]

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1f020ce
@sunny256 sunny256 pushed a commit to sunny256/linux that referenced this pull request Sep 7, 2015
Michal Hocko mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
commit ecf5fc6 upstream.

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f4 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f4 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
56c6503
@0day-ci 0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jan 7, 2016
@huangrui huangrui perf/x86/amd/power: Add AMD accumulated power reporting mechanism
Introduce an AMD accumlated power reporting mechanism for Carrizo
(Family 15h, Model 60h) processor that should be used to calculate the
average power consumed by a processor during a measurement interval.
The feature of accumulated power mechanism is indicated by CPUID
Fn8000_0007_EDX[12].

---------------------------------------------------------------------
* Tsample: compute unit power accumulator sample period
* Tref: the PTSC counter period
* PTSC: performance timestamp counter
* N: the ratio of compute unit power accumulator sample period to the
  PTSC period
* Jmax: max compute unit accumulated power which is indicated by
  MaxCpuSwPwrAcc MSR C001007b
* Jx/Jy: compute unit accumulated power which is indicated by
  CpuSwPwrAcc MSR C001007a
* Tx/Ty: the value of performance timestamp counter which is indicated
  by CU_PTSC MSR C0010280
* PwrCPUave: CPU average power

i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007.
	N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]].

ii. Read the full range of the cumulative energy value from the new
MSR MaxCpuSwPwrAcc.
	Jmax = value returned.
iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC.
	Jx = value read from CpuSwPwrAcc and Tx = value read from
PTSC.

iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC.
	Jy = value read from CpuSwPwrAcc and Ty = value read from
PTSC.

v. Calculate the average power consumption for a compute unit over
time period (y-x). Unit of result is uWatt.
	if (Jy < Jx) // Rollover has occurred
		Jdelta = (Jy + Jmax) - Jx
	else
		Jdelta = Jy - Jx
	PwrCPUave = N * Jdelta * 1000 / (Ty - Tx)
----------------------------------------------------------------------

This feature will be implemented both on hwmon and perf that discussed
in mail list before. At current design, it provides one event to
report per package/processor power consumption by counting each
compute unit power value.

Simple example:

root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' make -j4
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  SKIPPED include/generated/compile.h
  Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready  (#40)
  MODPOST 4225 modules

 Performance counter stats for 'system wide':

            183.44 mWatts power/power-pkg/

     341.837270111 seconds time elapsed

root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' sleep 10

 Performance counter stats for 'system wide':

              0.18 mWatts power/power-pkg/

      10.012551815 seconds time elapsed

Reference:
http://lkml.kernel.org/r/20150831160622.GA29830@nazgul.tnic

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Ingo Molnar <mingo@kernel.org>
Suggested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Cc: Guenter Roeck <linux@roeck-us.net>
71d7877