Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

[PATCH] ATH6KL: "Fix the byte alignment rule to avoid loss of bytes in a TCP segment" #27

Merged
merged 1 commit into from

3 participants

@kingpotato

I found the driver bug which occur loss of some bytes on the TCP/IP stack.

Either first 3 bytes of the first received tcp segment or last one
over MTU size file can be loss due to the byte alignment problem.
Although ATH6KL_HTC_ALIGN_BYTES was defined
for 'extra bytes for htc header alignment'
in the patch "Fix buffer alignment for scatter-gather I/O"(1df94a8),
there exists the bytes loss issue which means that it will be truncated
3 bytes in the transmitted file contents if a file which
has over MTU size is transferred through TCP/IP stack.
It doesn't look like TCP/IP stack bug of 3.5 or the latest version of
kernel but the byte alignment issue.
This patch is to use the roundup() function for the byte alignment
rather than the predefined ATH6KL_HTC_ALIGN_BYTES.

Signed-off-by: Myoungje Kim mjei78@gmail.com

@kingpotato kingpotato ath6kl: Fix the byte alignment rule to avoid loss of bytes in a TCP s…
…egment

Either first 3 bytes of the first received tcp segment or last one
over MTU size file can be loss due to the byte alignment problem.
Although ATH6KL_HTC_ALIGN_BYTES was defined
for 'extra bytes for htc header alignment'
in the patch "Fix buffer alignment for scatter-gather I/O"(1df94a8),
there exists the bytes loss issue which means that it will be truncated
3 bytes in the transmitted file contents if a file which
has over MTU size is transferred through TCP/IP stack.
It doesn't look like TCP/IP stack bug of 3.5 or the latest version of
kernel but the byte alignment issue.
This patch is to use the roundup() function for the byte alignment
rather than the predefined ATH6KL_HTC_ALIGN_BYTES.

Signed-off-by: Myoungje Kim <mjei78@gmail.com>
189fc7c
@whyrusleeping

Linus doesnt like github pull requests...

@jbrandeb jbrandeb referenced this pull request from a commit in jbrandeb/lls
Inderpal Singh regulator: s5m8767: Fix probe failure due to stack corruption
The function sec_reg_read invokes regmap_read which expects unsigned int *
as the destination address. The existing driver is passing address of local
variable "val" which is u8. This causes the stack corruption and following
dump is observed during probe.

Hence change "val" from u8 to unsigned int.

Unable to handle kernel paging request at virtual address 02410020
pgd = c0004000
[02410020] *pgd=00000000
Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0    Not tainted  (3.6.0-00696-g98a28b18-dirty #27)
PC is at 0x2410020
LR is at _regulator_get_voltage+0x3c/0x70
pc : [<02410020>]    lr : [<c02395d4>]    psr: 20000013
sp : cf839b68  ip : 00000000  fp : cf92d410
r10: 0000cfd0  r9 : c06d9878  r8 : 0000f0a0
r7 : cf839b70  r6 : cf92d400  r5 : 00000011  r4 : cf000000
r3 : 02410020  r2 : 00000000  r1 : 00000048  r0 : cf000000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
...........................
.................................

[<c02395d4>] (_regulator_get_voltage+0x3c/0x70) from [<c023ad80>] (print_constraints+0x50/0x36c)
[<c023ad80>] (print_constraints+0x50/0x36c) from [<c023e504>] (set_machine_constraints+0xe8/0x2b0)
[<c023e504>] (set_machine_constraints+0xe8/0x2b0) from [<c023e9c8>] (regulator_register+0x2fc/0x604)
[<c023e9c8>] (regulator_register+0x2fc/0x604) from [<c049d628>] (s5m8767_pmic_probe+0x688/0x718)
[<c049d628>] (s5m8767_pmic_probe+0x688/0x718) from [<c029915c>] (platform_drv_probe+0x18/0x1c)
[<c029915c>] (platform_drv_probe+0x18/0x1c) from [<c0297dd0>] (really_probe+0x68/0x1f4)
[<c0297dd0>] (really_probe+0x68/0x1f4) from [<c0298070>] (driver_probe_device+0x30/0x48)

Signed-off-by: Inderpal Singh <inderpal.singh@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
3ef3039
@noamc noamc referenced this pull request from a commit in EZchip/linux
@olofj olofj block: uninitialized ioc->nr_tasks triggers WARN_ON
Hi,

I'm using the old-fashioned 'dump' backup tool, and I noticed that it spews the
below warning as of 3.5-rc1 and later (3.4 is fine):

[   10.886893] ------------[ cut here ]------------
[   10.886904] WARNING: at include/linux/iocontext.h:140 copy_process+0x1488/0x1560()
[   10.886905] Hardware name: Bochs
[   10.886906] Modules linked in:
[   10.886908] Pid: 2430, comm: dump Not tainted 3.5.0-rc7+ #27
[   10.886908] Call Trace:
[   10.886911]  [<ffffffff8107ce8a>] warn_slowpath_common+0x7a/0xb0
[   10.886912]  [<ffffffff8107ced5>] warn_slowpath_null+0x15/0x20
[   10.886913]  [<ffffffff8107c088>] copy_process+0x1488/0x1560
[   10.886914]  [<ffffffff8107c244>] do_fork+0xb4/0x340
[   10.886918]  [<ffffffff8108effa>] ? recalc_sigpending+0x1a/0x50
[   10.886919]  [<ffffffff8108f6b2>] ? __set_task_blocked+0x32/0x80
[   10.886920]  [<ffffffff81091afa>] ? __set_current_blocked+0x3a/0x60
[   10.886923]  [<ffffffff81051db3>] sys_clone+0x23/0x30
[   10.886925]  [<ffffffff8179bd73>] stub_clone+0x13/0x20
[   10.886927]  [<ffffffff8179baa2>] ? system_call_fastpath+0x16/0x1b
[   10.886928] ---[ end trace 32a14af7ee6a590b ]---

Reproducing is easy, I can hit it on a KVM system with a very basic
config (x86_64 make defconfig + enable the drivers needed). To hit it,
just install dump (on debian/ubuntu, not sure what the package might be
called on Fedora), and:

dump -o -f /tmp/foo /

You'll see the warning in dmesg once it forks off the I/O process and
starts dumping filesystem contents.

I bisected it down to the following commit:

commit f6e8d01
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Mar 5 13:15:26 2012 -0800

    block: add io_context->active_ref

    Currently ioc->nr_tasks is used to decide two things - whether an ioc
    is done issuing IOs and whether it's shared by multiple tasks.  This
    patch separate out the first into ioc->active_ref, which is acquired
    and released using {get|put}_io_context_active() respectively.

    This will be used to associate bio's with a given task.  This patch
    doesn't introduce any visible behavior change.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

It seems like the init of ioc->nr_tasks was removed in that patch,
so it starts out at 0 instead of 1.

Tejun, is the right thing here to add back the init, or should something else
be done?

The below patch removes the warning, but I haven't done any more extensive
testing on it.

Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
4638a83
@vineetgarc vineetgarc referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@hardkernel hardkernel referenced this pull request from a commit in hardkernel/linux
@olofj olofj block: uninitialized ioc->nr_tasks triggers WARN_ON
commit 4638a83 upstream.

Hi,

I'm using the old-fashioned 'dump' backup tool, and I noticed that it spews the
below warning as of 3.5-rc1 and later (3.4 is fine):

[   10.886893] ------------[ cut here ]------------
[   10.886904] WARNING: at include/linux/iocontext.h:140 copy_process+0x1488/0x1560()
[   10.886905] Hardware name: Bochs
[   10.886906] Modules linked in:
[   10.886908] Pid: 2430, comm: dump Not tainted 3.5.0-rc7+ #27
[   10.886908] Call Trace:
[   10.886911]  [<ffffffff8107ce8a>] warn_slowpath_common+0x7a/0xb0
[   10.886912]  [<ffffffff8107ced5>] warn_slowpath_null+0x15/0x20
[   10.886913]  [<ffffffff8107c088>] copy_process+0x1488/0x1560
[   10.886914]  [<ffffffff8107c244>] do_fork+0xb4/0x340
[   10.886918]  [<ffffffff8108effa>] ? recalc_sigpending+0x1a/0x50
[   10.886919]  [<ffffffff8108f6b2>] ? __set_task_blocked+0x32/0x80
[   10.886920]  [<ffffffff81091afa>] ? __set_current_blocked+0x3a/0x60
[   10.886923]  [<ffffffff81051db3>] sys_clone+0x23/0x30
[   10.886925]  [<ffffffff8179bd73>] stub_clone+0x13/0x20
[   10.886927]  [<ffffffff8179baa2>] ? system_call_fastpath+0x16/0x1b
[   10.886928] ---[ end trace 32a14af7ee6a590b ]---

Reproducing is easy, I can hit it on a KVM system with a very basic
config (x86_64 make defconfig + enable the drivers needed). To hit it,
just install dump (on debian/ubuntu, not sure what the package might be
called on Fedora), and:

dump -o -f /tmp/foo /

You'll see the warning in dmesg once it forks off the I/O process and
starts dumping filesystem contents.

I bisected it down to the following commit:

commit f6e8d01
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Mar 5 13:15:26 2012 -0800

    block: add io_context->active_ref

    Currently ioc->nr_tasks is used to decide two things - whether an ioc
    is done issuing IOs and whether it's shared by multiple tasks.  This
    patch separate out the first into ioc->active_ref, which is acquired
    and released using {get|put}_io_context_active() respectively.

    This will be used to associate bio's with a given task.  This patch
    doesn't introduce any visible behavior change.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

It seems like the init of ioc->nr_tasks was removed in that patch,
so it starts out at 0 instead of 1.

Tejun, is the right thing here to add back the init, or should something else
be done?

The below patch removes the warning, but I haven't done any more extensive
testing on it.

Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bd60cd2
@swarren swarren referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@swarren swarren referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@torvalds torvalds referenced this pull request from a commit
@JoePerches JoePerches checkpatch: fix stringification macro defect
Fix checkpatch misreporting defect with stringification macros

ERROR: Macros with complex values should be enclosed in parenthesis
  #27: FILE: arch/arm/include/asm/kgdb.h:41:
  +#define ___to_string(X) #X

Signed-off-by: Joe Perches <joe@perches.com>
Reported-by: Vincent Stehlé <v-stehle@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
e942e2c
@tom3q tom3q referenced this pull request from a commit in tom3q/linux
@JoePerches JoePerches checkpatch: fix stringification macro defect
Fix checkpatch misreporting defect with stringification macros

ERROR: Macros with complex values should be enclosed in parenthesis
  #27: FILE: arch/arm/include/asm/kgdb.h:41:
  +#define ___to_string(X) #X

Signed-off-by: Joe Perches <joe@perches.com>
Reported-by: Vincent Stehlé <v-stehle@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
35630f4
@hzhuang1 hzhuang1 referenced this pull request from a commit in hzhuang1/linux
@JoePerches JoePerches checkpatch: fix stringification macro defect
Fix checkpatch misreporting defect with stringification macros

ERROR: Macros with complex values should be enclosed in parenthesis
  #27: FILE: arch/arm/include/asm/kgdb.h:41:
  +#define ___to_string(X) #X

Signed-off-by: Joe Perches <joe@perches.com>
Reported-by: Vincent Stehlé <v-stehle@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
718db2b
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
Borislav Petkov x86: Improve the printout of the SMP bootup CPU table
As the new x86 CPU bootup printout format code maintainer, I am
taking immediate action to improve and clean (and thus indulge
my OCD) the reporting of the cores when coming up online.

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

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

and this:

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

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

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

and drop useless elements.

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

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: huawei.libin@huawei.com
Cc: wangyijing@huawei.com
Cc: fenghua.yu@intel.com
Cc: guohanjun@huawei.com
Cc: paul.gortmaker@windriver.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>
a17bce4
@Naoya-Horiguchi Naoya-Horiguchi referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@torvalds torvalds merged commit 189fc7c into torvalds:master
@johnweber johnweber referenced this pull request from a commit in wandboard-org/linux
Robin Gong ENGR00285897 mx6 busfreq: fix system crash while enter low bus with '…
…maxcpus=1'

Use for_each_online_cpu instead of for_each_present_cpu to take this case,
otherwise system will crash as below when go into low bus with 'maxcpus=1'
setting in command line.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted 3.10.17-16647-g0868f35 #27
Workqueue: events reduce_bus_freq_handler
task: ac156d80 ti: ac2a2000 task.ti: ac2a2000
PC is at update_ddr_freq+0x98/0x2d0
LR is at 0x0
pc : [<80021928>]    lr : [<00000000>]    psr: 400f0013
sp : ac2a3e98  ip : 00000000  fp : 814db740
r10: 016e3600  r9 : 00000000  r8 : 00000000
r7 : 814de900  r6 : 80c60cc0  r5 : 0000000f  r4 : 80c60dc0
r3 : 00000000  r2 : 80c60dc0  r1 : 80c60d34  r0 : 00000000
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 3c49404a  DAC: 00000015
Process kworker/0:2 (pid: 68, stack limit = 0xac2a2238)
Stack: (0xac2a3e98 to 0xac2a4000)
3e80:                                                       00000000 00000000
3ea0: 00000000 00000000 00000001 80c60cc0 80c603a4 80c60cc0 814de900 00000000
3ec0: 00000000 ac2a2038 814db740 80020154 00000064 ac02f6c0 00000004 80c2103c
3ee0: 80c60d38 814db740 814de900 80020628 ac135780 8003d7ac 00000001 ac083eb8
3f00: 00000000 00000000 00000003 ac135780 814db754 ac135798 ac2a2000 ac2a2030
3f20: 00000001 ac2a2000 814db740 8003e4b8 8003e380 00000000 00000000 80c5fcc1
3f40: ac2a3f64 ac083ea0 00000000 ac135780 8003e380 00000000 00000000 00000000
3f60: 00000000 800437e0 fd7efff9 00000000 7faf7bfd ac135780 00000000 00000000
3f80: ac2a3f80 ac2a3f80 00000000 00000000 ac2a3f90 ac2a3f90 ac2a3fac ac083ea0
3fa0: 8004372c 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 fffc7fae d4cadbdb
[<80021928>] (update_ddr_freq+0x98/0x2d0) from [<80020154>] (reduce_bus_freq+
0x58/0x518)
[<80020154>] (reduce_bus_freq+0x58/0x518) from [<80020628>] (reduce_bus_freq_
handler+0x14/0x24)
[<80020628>] (reduce_bus_freq_handler+0x14/0x24) from [<8003d7ac>] (process_one
_work+0x10c/0x374)
[<8003d7ac>] (process_one_work+0x10c/0x374) from [<8003e4b8>] (worker_thread+
0x138/0x3fc)
[<8003e4b8>] (worker_thread+0x138/0x3fc) from [<800437e0>] (kthread+0xb4/0xb8)
[<800437e0>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
Code: e5940014 e3002dc0 e594e018 e34820c6 (e5835000)
---[ end trace 206df98575045d04 ]---
Unable to handle kernel paging request at virtual address ffffffec
pgd = 80004000
[ffffffec] *pgd=3ff7e821, *pte=00000000, *ppte=00000000

Signed-off-by: Robin Gong <b38343@freescale.com>
c63529a
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
Trond Myklebust SUNRPC: Fix memory reclaim deadlocks in rpciod
Junxiao Bi reports seeing the following deadlock:

@ crash> bt 1539
@ PID: 1539   TASK: ffff88178f64a040  CPU: 1   COMMAND: "rpciod/1"
@  #0 [ffff88178f64d2c0] schedule at ffffffff8145833a
@  #1 [ffff88178f64d348] io_schedule at ffffffff8145842c
@  #2 [ffff88178f64d368] sync_page at ffffffff810d8161
@  #3 [ffff88178f64d378] __wait_on_bit at ffffffff8145895b
@  #4 [ffff88178f64d3b8] wait_on_page_bit at ffffffff810d82fe
@  #5 [ffff88178f64d418] wait_on_page_writeback at ffffffff810e2a1a
@  #6 [ffff88178f64d438] shrink_page_list at ffffffff810e34e1
@  #7 [ffff88178f64d588] shrink_list at ffffffff810e3dbe
@  #8 [ffff88178f64d6f8] shrink_zone at ffffffff810e425e
@  #9 [ffff88178f64d7b8] do_try_to_free_pages at ffffffff810e4978
@ #10 [ffff88178f64d828] try_to_free_pages at ffffffff810e4c31
@ #11 [ffff88178f64d8c8] __alloc_pages_nodemask at ffffffff810de370
@ #12 [ffff88178f64d978] kmem_getpages at ffffffff8110e18b
@ #13 [ffff88178f64d9a8] fallback_alloc at ffffffff8110e35e
@ #14 [ffff88178f64da08] ____cache_alloc_node at ffffffff8110e51f
@ #15 [ffff88178f64da48] __kmalloc at ffffffff8110efba
@ #16 [ffff88178f64da98] xs_setup_xprt at ffffffffa00a563f [sunrpc]
@ #17 [ffff88178f64dad8] xs_setup_tcp at ffffffffa00a7648 [sunrpc]
@ #18 [ffff88178f64daf8] xprt_create_transport at ffffffffa00a478f [sunrpc]
@ #19 [ffff88178f64db18] rpc_create at ffffffffa00a2d7a [sunrpc]
@ #20 [ffff88178f64dbf8] rpcb_create at ffffffffa00b026b [sunrpc]
@ #21 [ffff88178f64dc98] rpcb_getport_async at ffffffffa00b0c94 [sunrpc]
@ #22 [ffff88178f64ddf8] call_bind at ffffffffa00a11f8 [sunrpc]
@ #23 [ffff88178f64de18] __rpc_execute at ffffffffa00a88ef [sunrpc]
@ #24 [ffff88178f64de58] rpc_async_schedule at ffffffffa00a9187 [sunrpc]
@ #25 [ffff88178f64de78] worker_thread at ffffffff81072ed2
@ #26 [ffff88178f64dee8] kthread at ffffffff81076df3
@ #27 [ffff88178f64df48] kernel_thread at ffffffff81012e2a
@ crash>

Junxiao notes that the problem is not limited to the rpcbind client. In
fact we can trigger the exact same problem when trying to reconnect to
the server, and we find ourselves calling sock_alloc().

The following solution should work for all kernels that support the
PF_MEMALLOC_NOIO flag (i.e. Linux 3.9 and newer).

Link: http://lkml.kernel.org/r/53F6F772.6020708@oracle.com
Reported-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: stable@vger.kernel.org # 3.9+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
852a8b2
@aryabinin aryabinin referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@n-aizu n-aizu referenced this pull request from a commit in n-aizu/linux
Robin Gong Freescale: ENGR00285897 mx6 busfreq: fix system crash while enter low…
… bus with 'maxcpus=1'

Use for_each_online_cpu instead of for_each_present_cpu to take this case,
otherwise system will crash as below when go into low bus with 'maxcpus=1'
setting in command line.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 817 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted 3.10.17-16647-g0868f35 #27
Workqueue: events reduce_bus_freq_handler
task: ac156d80 ti: ac2a2000 task.ti: ac2a2000
PC is at update_ddr_freq+0x98/0x2d0
LR is at 0x0
pc : [<80021928>]    lr : [<00000000>]    psr: 400f0013
sp : ac2a3e98  ip : 00000000  fp : 814db740
r10: 016e3600  r9 : 00000000  r8 : 00000000
r7 : 814de900  r6 : 80c60cc0  r5 : 0000000f  r4 : 80c60dc0
r3 : 00000000  r2 : 80c60dc0  r1 : 80c60d34  r0 : 00000000
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 3c49404a  DAC: 00000015
Process kworker/0:2 (pid: 68, stack limit = 0xac2a2238)
Stack: (0xac2a3e98 to 0xac2a4000)
3e80:                                                       00000000 00000000
3ea0: 00000000 00000000 00000001 80c60cc0 80c603a4 80c60cc0 814de900 00000000
3ec0: 00000000 ac2a2038 814db740 80020154 00000064 ac02f6c0 00000004 80c2103c
3ee0: 80c60d38 814db740 814de900 80020628 ac135780 8003d7ac 00000001 ac083eb8
3f00: 00000000 00000000 00000003 ac135780 814db754 ac135798 ac2a2000 ac2a2030
3f20: 00000001 ac2a2000 814db740 8003e4b8 8003e380 00000000 00000000 80c5fcc1
3f40: ac2a3f64 ac083ea0 00000000 ac135780 8003e380 00000000 00000000 00000000
3f60: 00000000 800437e0 fd7efff9 00000000 7faf7bfd ac135780 00000000 00000000
3f80: ac2a3f80 ac2a3f80 00000000 00000000 ac2a3f90 ac2a3f90 ac2a3fac ac083ea0
3fa0: 8004372c 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 fffc7fae d4cadbdb
[<80021928>] (update_ddr_freq+0x98/0x2d0) from [<80020154>] (reduce_bus_freq+
0x58/0x518)
[<80020154>] (reduce_bus_freq+0x58/0x518) from [<80020628>] (reduce_bus_freq_
handler+0x14/0x24)
[<80020628>] (reduce_bus_freq_handler+0x14/0x24) from [<8003d7ac>] (process_one
_work+0x10c/0x374)
[<8003d7ac>] (process_one_work+0x10c/0x374) from [<8003e4b8>] (worker_thread+
0x138/0x3fc)
[<8003e4b8>] (worker_thread+0x138/0x3fc) from [<800437e0>] (kthread+0xb4/0xb8)
[<800437e0>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
Code: e5940014 e3002dc0 e594e018 e34820c6 (e5835000)
---[ end trace 206df98575045d04 ]---
Unable to handle kernel paging request at virtual address ffffffec
pgd = 80004000
[ffffffec] *pgd=3ff7e821, *pte=00000000, *ppte=00000000

Signed-off-by: Robin Gong <b38343@freescale.com>
c9aa101
@swarren swarren referenced this pull request from a commit in swarren/linux-tegra
@newbg newbg bonding: fix div by zero while enslaving and transmitting
The problem is that the slave is first linked and slave_cnt is
incremented afterwards leading to a div by zero in the modes that use it
as a modulus. What happens is that in bond_start_xmit()
bond_has_slaves() is used to evaluate further transmission and it becomes
true after the slave is linked in, but when slave_cnt is used in the xmit
path it is still 0, so fetch it once and transmit based on that. Since
it is used only in round-robin and XOR modes, the fix is only for them.
Thanks to Eric Dumazet for pointing out the fault in my first try to fix
this.

Call trace (took it out of net-next kernel, but it's the same with net):
[46934.330038] divide error: 0000 [#1] SMP
[46934.330041] Modules linked in: bonding(O) 9p fscache
snd_hda_codec_generic crct10dif_pclmul
[46934.330041] bond0: Enslaving eth1 as an active interface with an up
link
[46934.330051]  ppdev joydev crc32_pclmul crc32c_intel 9pnet_virtio
ghash_clmulni_intel snd_hda_intel 9pnet snd_hda_controller parport_pc
serio_raw pcspkr snd_hda_codec parport virtio_balloon virtio_console
snd_hwdep snd_pcm pvpanic i2c_piix4 snd_timer i2ccore snd soundcore
virtio_blk virtio_net virtio_pci virtio_ring virtio ata_generic
pata_acpi floppy [last unloaded: bonding]
[46934.330053] CPU: 1 PID: 3382 Comm: ping Tainted: G           O
3.17.0-rc4+ #27
[46934.330053] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[46934.330054] task: ffff88005aebf2c0 ti: ffff88005b728000 task.ti:
ffff88005b728000
[46934.330059] RIP: 0010:[<ffffffffa0198c33>]  [<ffffffffa0198c33>]
bond_start_xmit+0x1c3/0x450 [bonding]
[46934.330060] RSP: 0018:ffff88005b72b7f8  EFLAGS: 00010246
[46934.330060] RAX: 0000000000000679 RBX: ffff88004b077000 RCX:
000000000000002a
[46934.330061] RDX: 0000000000000000 RSI: ffff88004b3f0500 RDI:
ffff88004b077940
[46934.330061] RBP: ffff88005b72b830 R08: 00000000000000c0 R09:
ffff88004a83e000
[46934.330062] R10: 000000000000ffff R11: ffff88004b1f12c0 R12:
ffff88004b3f0500
[46934.330062] R13: ffff88004b3f0500 R14: 000000000000002a R15:
ffff88004b077940
[46934.330063] FS:  00007fbd91a4c740(0000) GS:ffff88005f080000(0000)
knlGS:0000000000000000
[46934.330064] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[46934.330064] CR2: 00007f803a8bb000 CR3: 000000004b2c9000 CR4:
00000000000406e0
[46934.330069] Stack:
[46934.330071]  ffffffff811e6169 00000000e772fa05 ffff88004b077000
ffff88004b3f0500
[46934.330072]  ffffffff81d17d18 000000000000002a 0000000000000000
ffff88005b72b8a0
[46934.330073]  ffffffff81620108 ffffffff8161fe0e ffff88005b72b8c4
ffff88005b302000
[46934.330073] Call Trace:
[46934.330077]  [<ffffffff811e6169>] ?
__kmalloc_node_track_caller+0x119/0x300
[46934.330084]  [<ffffffff81620108>] dev_hard_start_xmit+0x188/0x410
[46934.330086]  [<ffffffff8161fe0e>] ? harmonize_features+0x2e/0x90
[46934.330088]  [<ffffffff81620b06>] __dev_queue_xmit+0x456/0x590
[46934.330089]  [<ffffffff81620c50>] dev_queue_xmit+0x10/0x20
[46934.330090]  [<ffffffff8168f022>] arp_xmit+0x22/0x60
[46934.330091]  [<ffffffff8168f090>] arp_send.part.16+0x30/0x40
[46934.330092]  [<ffffffff8168f1e5>] arp_solicit+0x115/0x2b0
[46934.330094]  [<ffffffff8160b5d7>] ? copy_skb_header+0x17/0xa0
[46934.330096]  [<ffffffff8162875a>] neigh_probe+0x4a/0x70
[46934.330097]  [<ffffffff8162979c>] __neigh_event_send+0xac/0x230
[46934.330098]  [<ffffffff8162a00b>] neigh_resolve_output+0x13b/0x220
[46934.330100]  [<ffffffff8165f120>] ? ip_forward_options+0x1c0/0x1c0
[46934.330101]  [<ffffffff81660478>] ip_finish_output+0x1f8/0x860
[46934.330102]  [<ffffffff81661f08>] ip_output+0x58/0x90
[46934.330103]  [<ffffffff81661602>] ? __ip_local_out+0xa2/0xb0
[46934.330104]  [<ffffffff81661640>] ip_local_out_sk+0x30/0x40
[46934.330105]  [<ffffffff81662a66>] ip_send_skb+0x16/0x50
[46934.330106]  [<ffffffff81662ad3>] ip_push_pending_frames+0x33/0x40
[46934.330107]  [<ffffffff8168854c>] raw_sendmsg+0x88c/0xa30
[46934.330110]  [<ffffffff81612b31>] ? skb_recv_datagram+0x41/0x60
[46934.330111]  [<ffffffff816875a9>] ? raw_recvmsg+0xa9/0x1f0
[46934.330113]  [<ffffffff816978d4>] inet_sendmsg+0x74/0xc0
[46934.330114]  [<ffffffff81697a9b>] ? inet_recvmsg+0x8b/0xb0
[46934.330115] bond0: Adding slave eth2
[46934.330116]  [<ffffffff8160357c>] sock_sendmsg+0x9c/0xe0
[46934.330118]  [<ffffffff81603248>] ?
move_addr_to_kernel.part.20+0x28/0x80
[46934.330121]  [<ffffffff811b4477>] ? might_fault+0x47/0x50
[46934.330122]  [<ffffffff816039b9>] ___sys_sendmsg+0x3a9/0x3c0
[46934.330125]  [<ffffffff8144a14a>] ? n_tty_write+0x3aa/0x530
[46934.330127]  [<ffffffff810d1ae4>] ? __wake_up+0x44/0x50
[46934.330129]  [<ffffffff81242b38>] ? fsnotify+0x238/0x310
[46934.330130]  [<ffffffff816048a1>] __sys_sendmsg+0x51/0x90
[46934.330131]  [<ffffffff816048f2>] SyS_sendmsg+0x12/0x20
[46934.330134]  [<ffffffff81738b29>] system_call_fastpath+0x16/0x1b
[46934.330144] Code: 48 8b 10 4c 89 ee 4c 89 ff e8 aa bc ff ff 31 c0 e9
1a ff ff ff 0f 1f 00 4c 89 ee 4c 89 ff e8 65 fb ff ff 31 d2 4c 89 ee 4c
89 ff <f7> b3 64 09 00 00 e8 02 bd ff ff 31 c0 e9 f2 fe ff ff 0f 1f 00
[46934.330146] RIP  [<ffffffffa0198c33>] bond_start_xmit+0x1c3/0x450
[bonding]
[46934.330146]  RSP <ffff88005b72b7f8>

CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
Fixes: 278b208 ("bonding: initial RCU conversion")
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
9a72c2d
@koct9i koct9i referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@aryabinin aryabinin referenced this pull request from a commit in aryabinin/linux
mmotm auto import