* Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Linus Walleij @ 2014-11-27 13:28 UTC (permalink / raw)
To: Roger Quadros
Cc: Marc Kleine-Budde, wg, Wolfram Sang, Tony Lindgren,
Thomas Gleixner, Mugunthan V N, George Cherian, Felipe Balbi,
Sekhar Nori, Nishanth Menon, Sergei Shtylyov, Linux-OMAP,
linux-can, netdev@vger.kernel.org
In-Reply-To: <546606F4.6020102@ti.com>
On Fri, Nov 14, 2014 at 2:43 PM, Roger Quadros <rogerq@ti.com> wrote:
> On 11/13/2014 06:03 PM, Marc Kleine-Budde wrote:
>> On 11/13/2014 04:23 PM, Roger Quadros wrote:
>> I just stumbled over pinctrl_pm_select_sleep_state(), is it possible to
>> integrate this into runtime pm?
>>
>> http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1282
>
> I think those functions are there for the same reason but not sure why aren't
> they used in runtime pm core.
>
> Linus W. any hints?
It is not used from PM core because there are cases where
you may want to put pins to sleep for completely PM-core
unrelated things.
Things like turning off a serial port from userspace,
for example. That should put the pins to sleep.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [patch net-next v4 15/21] rocker: introduce rocker switch driver
From: Jamal Hadi Salim @ 2014-11-27 13:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417084826-9875-16-git-send-email-jiri@resnulli.us>
On 11/27/14 05:40, Jiri Pirko wrote:
> This patch introduces the first driver to benefit from the switchdev
> infrastructure and to implement newly introduced switch ndos. This is a
> driver for emulated switch chip implemented in qemu:
> https://github.com/sfeldma/qemu-rocker/
>
> This patch is a result of joint work with Scott Feldman.
>
I would like to review the rocking rocks rocker later (sorry dont have
time right now but would love to).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 13/21] bridge: add new hwmode swdev
From: Sergei Shtylyov @ 2014-11-27 13:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417084826-9875-14-git-send-email-jiri@resnulli.us>
Hello.
On 11/27/2014 1:40 PM, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
> Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> with basic bridging function offloaded to HW. Add new "swdev" for full
> switch device offloads.
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> v3->v4:
> -no change
> new in v3
> ---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index da17e45..60425ca 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -105,6 +105,7 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> +#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
Please use tabs for indentation.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-27 13:32 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <20141127130345.GB27041@casper.infradead.org>
On 11/27/14 08:03, Thomas Graf wrote:
> So what is your name suggestion?
>
I would have gone for _offload_ either as a prefix or suffix
somewhere.
cheers,
jamal
^ permalink raw reply
* bug in networking code causes GPF
From: Дениска-редиска @ 2014-11-27 13:35 UTC (permalink / raw)
To: linux-net, netdev, linux-kernel
hello,
i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
[354497.931834] general protection fault: 0000 [#1] SMP
[354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
[354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
[354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
[354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
[354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
[354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
[354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
[354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
[354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
[354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
[354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
[354497.932973] Stack:
[354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
[354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
[354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
[354497.933304] Call Trace:
[354497.933347] <IRQ>
[354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
[354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
[354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
[354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
[354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
[354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
[354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
[354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
[354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
[354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
[354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
[354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
[354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
[354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
[354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
[354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
[354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
[354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
[354497.934441] <EOI>
[354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
[354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
[354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
[354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
[354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
[354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
[354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
[354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
[354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
[354497.935456] RSP <ffff88021fd03b98>
[354497.935965] ---[ end trace 7d6f660245b2d541 ]---
[354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
[354498.016801] Rebooting in 10 seconds.
[674944.621564] general protection fault: 0000 [#1] SMP
[674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
[674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
[674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
[674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
[674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
[674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
[674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
[674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
[674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
[674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
[674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
[674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
[674944.622701] Stack:
[674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
[674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
[674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
[674944.623031] Call Trace:
[674944.623077] <IRQ>
[674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
[674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
[674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
[674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
[674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
[674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
[674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
[674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
[674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
[674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
[674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
[674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
[674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
[674944.623906] <EOI>
[674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
[674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
[674944.624536] RSP <ffff88021fc03ce8>
[674944.625020] ---[ end trace 8035e2b5322bab00 ]---
[674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
[674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[674944.706711] Rebooting in 10 seconds.
[7523332.314991] general protection fault: 0000 [#1] SMP
[7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
[7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
[7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
[7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
[7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
[7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
[7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
[7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
[7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
[7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
[7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
[7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
[7523332.317679] Stack:
[7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
[7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
[7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
[7523332.318026] Call Trace:
[7523332.318072] <IRQ>
[7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
[7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
[7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
[7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
[7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
[7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
[7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
[7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
[7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
[7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
[7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
[7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
[7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
[7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
[7523332.318999] <EOI>
[7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
[7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
[7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
[7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
[7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
[7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
[7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
[7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
[7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
[7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
[7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
[7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
[7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
[7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
[7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
[7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
[7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
[7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
[7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
[7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
[7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
[7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
[7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
[7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
[7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
[7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
[7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
[7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
[7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
[7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
[7523332.321579] RSP <ffff88021fa03bf8>
[7523332.322094] ---[ end trace 0e21b79561002306 ]---
[7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [patch net-next v4 09/21] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Jiri Pirko @ 2014-11-27 13:43 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl, hemal
In-Reply-To: <547723AC.1070907@mojatatu.com>
Thu, Nov 27, 2014 at 02:14:20PM CET, jhs@mojatatu.com wrote:
>On 11/27/14 05:40, Jiri Pirko wrote:
>>From: Scott Feldman <sfeldma@gmail.com>
>>
>>To notify switch driver of change in STP state of bridge port, add new
>>.ndo op and provide switchdev wrapper func to call ndo op. Use it in bridge
>>code then.
>>
>
>As it stands right now we are going to pollute the ndo ops and grow
>it fatter like the skb (its probably as fat).
>If i am not mistaken ethtool has some scheme it uses to pass opaque
>objects to different functions. Having a generic
>set/get_netdev_offload_attr() would be the right thing to do.
>An {id, *value} or {id, len, *value} or a void * would do.
>So not objecting - but not ACKing either.
Yeah, this will be changed in future when more and more info will need
to be passed to offloads.
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-11-27 13:50 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Thomas Graf, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <547727F0.7020105@mojatatu.com>
Thu, Nov 27, 2014 at 02:32:32PM CET, jhs@mojatatu.com wrote:
>On 11/27/14 08:03, Thomas Graf wrote:
>
>>So what is your name suggestion?
>>
>
>I would have gone for _offload_ either as a prefix or suffix
>somewhere.
$ git grep offload net
Wouldn't it be confusing to add this another different "offload". That's
just confusing.
I still like "switch" the best. If it passes packets around, it's a
"switch", +-. Everybody understand what's going on if you use "switch".
If you use "offload", everybody is confused...
>
>cheers,
>jamal
^ permalink raw reply
* Re: bug in networking code causes GPF
From: Daniel Borkmann @ 2014-11-27 13:54 UTC (permalink / raw)
To: Дениска-редиска
Cc: linux-net, netdev, linux-kernel, minipli, fw
In-Reply-To: <1417095336.547728a8852ee@mail.inbox.lv>
On 11/27/2014 02:35 PM, Дениска-редиска wrote:
> hello,
>
> i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
> Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
>
> There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
Hmm, looks pretty much like ...
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54903
... which was a bug in the grsec patch set.
Does your grsec kernel have:
commit 0fa213cce614ad25a79acbd06f37f1e9022134d9
Author: Brad Spengler <spender@grsecurity.net>
Date: Fri Oct 31 17:29:20 2014 -0400
From: Mathias Krause <minipli@googlemail.com>
To: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>, Mathias Krause
<minipli@googlemail.com>
Subject: [PATCH] pax: don't sanitize RCU slab caches
We cannot sanitize SLAB_DESTROY_BY_RCU slab caches in kmem_cache_free()
as there might be readers in this RCU period, wanting to access the
object.
Fix this, for now, by marking those with SLAB_NO_SANITIZE. Hopefully we
can have a real fix later on. But this should fix the RCU stalls and
netfilter conntrack related problems.
This patch should go on top of the previous patch.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
> [354497.931834] general protection fault: 0000 [#1] SMP
> [354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
> [354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> [354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
> [354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
> [354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
> [354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
> [354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
> [354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
> [354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
> [354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> [354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
> [354497.932973] Stack:
> [354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
> [354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
> [354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
> [354497.933304] Call Trace:
> [354497.933347] <IRQ>
> [354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
> [354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
> [354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
> [354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> [354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
> [354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> [354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
> [354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
> [354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
> [354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
> [354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
> [354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
> [354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
> [354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
> [354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
> [354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
> [354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
> [354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
> [354497.934441] <EOI>
> [354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
> [354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> [354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
> [354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
> [354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> [354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
> [354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
> [354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
> [354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
> [354497.935456] RSP <ffff88021fd03b98>
> [354497.935965] ---[ end trace 7d6f660245b2d541 ]---
> [354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
> [354498.016801] Rebooting in 10 seconds.
>
>
> [674944.621564] general protection fault: 0000 [#1] SMP
> [674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
> [674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> [674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
> [674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
> [674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
> [674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
> [674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
> [674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
> [674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
> [674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
> [674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
> [674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
> [674944.622701] Stack:
> [674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
> [674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
> [674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
> [674944.623031] Call Trace:
> [674944.623077] <IRQ>
> [674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
> [674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
> [674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
> [674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
> [674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
> [674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
> [674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
> [674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
> [674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
> [674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
> [674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
> [674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
> [674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
> [674944.623906] <EOI>
> [674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
> [674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
> [674944.624536] RSP <ffff88021fc03ce8>
> [674944.625020] ---[ end trace 8035e2b5322bab00 ]---
> [674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
> [674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> [674944.706711] Rebooting in 10 seconds.
>
>
> [7523332.314991] general protection fault: 0000 [#1] SMP
> [7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
> [7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
> [7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
> [7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
> [7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
> [7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
> [7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
> [7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
> [7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
> [7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
> [7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
> [7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
> [7523332.317679] Stack:
> [7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
> [7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
> [7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
> [7523332.318026] Call Trace:
> [7523332.318072] <IRQ>
> [7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
> [7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> [7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> [7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> [7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> [7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
> [7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
> [7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
> [7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
> [7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
> [7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
> [7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
> [7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
> [7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
> [7523332.318999] <EOI>
> [7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
> [7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
> [7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
> [7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> [7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> [7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> [7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> [7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
> [7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
> [7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
> [7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
> [7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
> [7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
> [7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
> [7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
> [7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
> [7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
> [7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
> [7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
> [7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
> [7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
> [7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
> [7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
> [7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
> [7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
> [7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
> [7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
> [7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
> [7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
> [7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
> [7523332.321579] RSP <ffff88021fa03bf8>
> [7523332.322094] ---[ end trace 0e21b79561002306 ]---
> [7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 14:06 UTC (permalink / raw)
To: John W. Linville, Grazvydas Ignotas, linux-wireless, netdev,
linux-kernel, Ming Lei, Greg Kroah-Hartman
Cc: Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
[-- Attachment #1: Type: Text/Plain, Size: 1673 bytes --]
Hello,
wifi driver wl1251 needs NVS calibration data for working. These
data are loaded by driver via request_firmware from userspace
file: ti-connectivity/wl1251-nvs.bin. In linux-fimrware git tree
there is generic wl1251-nvs.bin file which is used by default.
Driver wl1251 is used on Nokia N900 cellphone for its wifi chip.
This cellphone has one special MTD partition (called CAL) where
are stored some configuration data in special binary (key-value)
format. And there is also stored correct calibration data for
specific device (each device has different data). It is preferred
to use those data instead generic one (provided by linux-firmware
git tree).
Now my question is: How to correctly load calibration data from
special Nokia N900 CAL partition into wl1251 kernel driver?
By default kernel reads ti-connectivity/wl1251-nvs.bin file from
VFS if exists without any userspace support. If it fails then it
fallback to loading via udev.
Reading correct data from CAL partition is not easy (structure is
difficult), but there is open source program which can parse CAL
partition and write NVS data to stdout. So adding this CAL parser
into kernel is not good idea (program is GPLv3+ code --
incompatible with kernel).
So how to solve this problem? How to load correct NVS data from
CAL partition into wl1251 driver?
It is possible to tell kernel to use some helper userspace
program for loading data and if it fails then fallback to direct
loading? E.g first try to use model specific data and if it fails
for some reasons then fallback to reading genetic data.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 14:21 UTC (permalink / raw)
To: Pali Rohár
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <201411271506.20457@pali>
On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Hello,
>
> wifi driver wl1251 needs NVS calibration data for working. These
> data are loaded by driver via request_firmware from userspace
> file: ti-connectivity/wl1251-nvs.bin. In linux-fimrware git tree
> there is generic wl1251-nvs.bin file which is used by default.
>
> Driver wl1251 is used on Nokia N900 cellphone for its wifi chip.
> This cellphone has one special MTD partition (called CAL) where
> are stored some configuration data in special binary (key-value)
> format. And there is also stored correct calibration data for
> specific device (each device has different data). It is preferred
> to use those data instead generic one (provided by linux-firmware
> git tree).
>
> Now my question is: How to correctly load calibration data from
> special Nokia N900 CAL partition into wl1251 kernel driver?
It is better to let user space script handle the request.
>
> By default kernel reads ti-connectivity/wl1251-nvs.bin file from
> VFS if exists without any userspace support. If it fails then it
> fallback to loading via udev.
You can remove or rename this file so that loading from user space
can be triggered.
>
> Reading correct data from CAL partition is not easy (structure is
> difficult), but there is open source program which can parse CAL
> partition and write NVS data to stdout. So adding this CAL parser
> into kernel is not good idea (program is GPLv3+ code --
> incompatible with kernel).
>
> So how to solve this problem? How to load correct NVS data from
> CAL partition into wl1251 driver?
>
> It is possible to tell kernel to use some helper userspace
> program for loading data and if it fails then fallback to direct
> loading? E.g first try to use model specific data and if it fails
> for some reasons then fallback to reading genetic data.
One solution is to introduce request_firmware_user() and let
this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
has to be enabled.
If request_firmware_user() fails, request_firmware_direct() can be
tried further.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Quentin Lambert @ 2014-11-27 14:36 UTC (permalink / raw)
To: David Laight, 'Joe Perches', Alexei Starovoitov
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FDA63@AcuExch.aculab.com>
On 27/11/2014 13:25, David Laight wrote:
> From: Joe Perches
>> On Wed, 2014-11-26 at 10:34 -0800, Alexei Starovoitov wrote:
>>> On Wed, Nov 26, 2014 at 10:02 AM, Joe Perches <joe@perches.com> wrote:
>>>> On Wed, 2014-11-26 at 09:23 -0800, Alexei Starovoitov wrote:
>>>>> On Wed, Nov 26, 2014 at 8:58 AM, Joe Perches <joe@perches.com> wrote:
>>>>>> Is there any value in reordering these tests for frequency
>>>>>> or maybe using | instead of || to avoid multiple jumps?
>>>>> probably not. It's not a critical path.
>>>>> compiler may fuse conditions depending on values anyway.
>>>>> If it was a critical path, we could have used
>>>>> (1 << reg) & mask trick.
>>>>> I picked explicit 'return true' else 'return false' here,
>>>>> because it felt easier to read. Just a matter of taste.
>>>> There is a size difference though: (allyesconfig)
>>>>
>>>> $ size arch/x86/net/built-in.o*
>>>> text data bss dec hex filename
>>>> 12999 1012 4336 18347 47ab arch/x86/net/built-in.o.new
>>>> 13177 1076 4592 18845 499d arch/x86/net/built-in.o.old
>>> interesting. Compiler obviously thinks that 178 byte increase
>>> with -O2 is the right trade off. Which I agree with :)
>>>
>>> If I think dropping 'inline' and using -Os will give bigger savings...
>> This was allyesconfig which already uses -Os
>>
>> Using -O2, there is no difference using inline
>> or not, but the size delta with the bitmask is
>> much larger
>>
>> $ size arch/x86/net/built-in.o* (allyesconfig, but not -Os)
>> text data bss dec hex filename
>> 13410 820 3624 17854 45be arch/x86/net/built-in.o.new
>> 16130 884 4200 21214 52de arch/x86/net/built-in.o.old
>> 16130 884 4200 21214 52de arch/x86/net/built-in.o.static
> That is quite a big % change in the code size.
> Why the change in data?
>
> David
>
>
>
Do you want me to propose a second version, or should I just
drop it all together ?
I am a new contributor so I have no experience in that sort of thing.
Quentin
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 14:43 UTC (permalink / raw)
To: Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <CACVXFVMr8jH1ZzyPNG91VDK8DuVjQsHn9ks62sSNjOfUnNsURQ@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 2970 bytes --]
On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
<pali.rohar@gmail.com> wrote:
> > Hello,
> >
> > wifi driver wl1251 needs NVS calibration data for working.
> > These data are loaded by driver via request_firmware from
> > userspace file: ti-connectivity/wl1251-nvs.bin. In
> > linux-fimrware git tree there is generic wl1251-nvs.bin
> > file which is used by default.
> >
> > Driver wl1251 is used on Nokia N900 cellphone for its wifi
> > chip. This cellphone has one special MTD partition (called
> > CAL) where are stored some configuration data in special
> > binary (key-value) format. And there is also stored correct
> > calibration data for specific device (each device has
> > different data). It is preferred to use those data instead
> > generic one (provided by linux-firmware git tree).
> >
> > Now my question is: How to correctly load calibration data
> > from special Nokia N900 CAL partition into wl1251 kernel
> > driver?
>
> It is better to let user space script handle the request.
>
Yes, this makes sense. Implementing CAL parser in kernel wl1251
driver would be hard...
> > By default kernel reads ti-connectivity/wl1251-nvs.bin file
> > from VFS if exists without any userspace support. If it
> > fails then it fallback to loading via udev.
>
> You can remove or rename this file so that loading from user
> space can be triggered.
>
It is no so easy... In case when CAL does not contains NVS data
then we want to use this generic NVS file. And telling everybody
to rename this is file is not good solution...
> > Reading correct data from CAL partition is not easy
> > (structure is difficult), but there is open source program
> > which can parse CAL partition and write NVS data to stdout.
> > So adding this CAL parser into kernel is not good idea
> > (program is GPLv3+ code -- incompatible with kernel).
> >
> > So how to solve this problem? How to load correct NVS data
> > from CAL partition into wl1251 driver?
> >
> > It is possible to tell kernel to use some helper userspace
> > program for loading data and if it fails then fallback to
> > direct loading? E.g first try to use model specific data
> > and if it fails for some reasons then fallback to reading
> > genetic data.
>
> One solution is to introduce request_firmware_user() and let
> this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
> has to be enabled.
>
> If request_firmware_user() fails, request_firmware_direct()
> can be tried further.
>
> Thanks,
> Ming Lei
Ok, new kernel function which will change order of loading
firmware should work.
Which userspace helper programs for (automatic) firmware loading
are used? Can be udev configured to use own program for loading
firmware instead that udev integrated which looking for firmware
only in /lib/firmware files?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v3] can: Convert to runtime_pm
From: Michal Simek @ 2014-11-27 14:46 UTC (permalink / raw)
To: Kedareswara rao Appana, wg, mkl, michal.simek, soren.brinkmann,
grant.likely, robh+dt
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, devicetree,
Kedareswara rao Appana
In-Reply-To: <1417093733-29576-1-git-send-email-appanad@xilinx.com>
On 11/27/2014 02:08 PM, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the driver,
> use the runtime_pm framework. This consolidates the actions for
> runtime PM in the appropriate callbacks and makes the driver more
> readable and mantainable.
>
> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v3:
> - Converted the driver to use runtime_pm.
> Changes for v2:
> - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
> drivers/net/can/xilinx_can.c | 119 +++++++++++++++++++++++++----------------
> 1 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
> index 8a998e3..1be28ed 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
> #include <linux/can/dev.h>
> #include <linux/can/error.h>
> #include <linux/can/led.h>
> +#include <linux/pm_runtime.h>
>
> #define DRIVER_NAME "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
> u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
> void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
> u32 val);
> - struct net_device *dev;
> + struct device *dev;
> void __iomem *reg_base;
> unsigned long irq_flags;
> struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
> +
> ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> ndev->name, ndev);
> if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
> goto err;
> }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
> /* Set chip into reset mode */
> ret = set_reset_mode(ndev);
> if (ret < 0) {
> netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
> }
>
> /* Common open */
> ret = open_candev(ndev);
> if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
> ret = xcan_chip_start(ndev);
> if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
> err_candev:
> close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
> err_irq:
> free_irq(ndev->irq, ndev);
> err:
> + pm_runtime_put(priv->dev);
> +
> return ret;
> }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
> netif_stop_queue(ndev);
> napi_disable(&priv->napi);
> xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> free_irq(ndev->irq, ndev);
> close_candev(ndev);
>
> can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
> return 0;
> }
> @@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct net_device *ndev,
> struct xcan_priv *priv = netdev_priv(ndev);
> int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
>
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret)
> - goto err_clk;
>
> bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
> bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
> XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
>
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> + pm_runtime_put(priv->dev);
>
> return 0;
> -
> -err_clk:
> - clk_disable_unprepare(priv->can_clk);
> -err:
> - return ret;
> }
>
>
> @@ -967,15 +954,45 @@ static const struct net_device_ops xcan_netdev_ops = {
>
> /**
> * xcan_suspend - Suspend method for the driver
> - * @dev: Address of the platform_device structure
> + * @dev: Address of the net_device structure
This is just the device structure.
> *
> * Put the driver into low power mode.
> - * Return: 0 always
> + * Return: 0 on success and failure value on error
> */
> static int __maybe_unused xcan_suspend(struct device *dev)
> {
> - struct platform_device *pdev = dev_get_drvdata(dev);
> - struct net_device *ndev = platform_get_drvdata(pdev);
> + if (!device_may_wakeup(dev))
> + return pm_runtime_force_suspend(dev);
> +
> + return 0;
> +}
> +
> +/**
> + * xcan_resume - Resume from suspend
> + * @dev: Address of the net_device structure
ditto
> + *
> + * Resume operation after suspend.
> + * Return: 0 on success and failure value on error
> + */
> +static int __maybe_unused xcan_resume(struct device *dev)
> +{
> + if (!device_may_wakeup(dev))
> + return pm_runtime_force_resume(dev);
> +
> + return 0;
> +
> +}
> +
> +/**
> + * xcan_runtime_suspend - Runtime suspend method for the driver
> + * @dev: Address of the net_device structure
ditto.
> + *
> + * Put the driver into low power mode.
> + * Return: 0 always
> + */
> +static int __maybe_unused xcan_runtime_suspend(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> struct xcan_priv *priv = netdev_priv(ndev);
>
> if (netif_running(ndev)) {
> @@ -993,16 +1010,15 @@ static int __maybe_unused xcan_suspend(struct device *dev)
> }
>
> /**
> - * xcan_resume - Resume from suspend
> - * @dev: Address of the platformdevice structure
> + * xcan_runtime_resume - Runtime resume from suspend
> + * @dev: Address of the net_device structure
ditto.
Thanks,
Michal
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 15:13 UTC (permalink / raw)
To: Pali Rohár
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 10:43 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
>> On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Hello,
>> >
>> > wifi driver wl1251 needs NVS calibration data for working.
>> > These data are loaded by driver via request_firmware from
>> > userspace file: ti-connectivity/wl1251-nvs.bin. In
>> > linux-fimrware git tree there is generic wl1251-nvs.bin
>> > file which is used by default.
>> >
>> > Driver wl1251 is used on Nokia N900 cellphone for its wifi
>> > chip. This cellphone has one special MTD partition (called
>> > CAL) where are stored some configuration data in special
>> > binary (key-value) format. And there is also stored correct
>> > calibration data for specific device (each device has
>> > different data). It is preferred to use those data instead
>> > generic one (provided by linux-firmware git tree).
>> >
>> > Now my question is: How to correctly load calibration data
>> > from special Nokia N900 CAL partition into wl1251 kernel
>> > driver?
>>
>> It is better to let user space script handle the request.
>>
>
> Yes, this makes sense. Implementing CAL parser in kernel wl1251
> driver would be hard...
>
>> > By default kernel reads ti-connectivity/wl1251-nvs.bin file
>> > from VFS if exists without any userspace support. If it
>> > fails then it fallback to loading via udev.
>>
>> You can remove or rename this file so that loading from user
>> space can be triggered.
>>
>
> It is no so easy... In case when CAL does not contains NVS data
> then we want to use this generic NVS file. And telling everybody
> to rename this is file is not good solution...
>
>> > Reading correct data from CAL partition is not easy
>> > (structure is difficult), but there is open source program
>> > which can parse CAL partition and write NVS data to stdout.
>> > So adding this CAL parser into kernel is not good idea
>> > (program is GPLv3+ code -- incompatible with kernel).
>> >
>> > So how to solve this problem? How to load correct NVS data
>> > from CAL partition into wl1251 driver?
>> >
>> > It is possible to tell kernel to use some helper userspace
>> > program for loading data and if it fails then fallback to
>> > direct loading? E.g first try to use model specific data
>> > and if it fails for some reasons then fallback to reading
>> > genetic data.
>>
>> One solution is to introduce request_firmware_user() and let
>> this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
>> has to be enabled.
>>
>> If request_firmware_user() fails, request_firmware_direct()
>> can be tried further.
>>
>> Thanks,
>> Ming Lei
>
> Ok, new kernel function which will change order of loading
> firmware should work.
I mean you can do that in your driver.
>
> Which userspace helper programs for (automatic) firmware loading
> are used? Can be udev configured to use own program for loading
At default, udev had its builtin firmware helper, but some new
udev stops to handle firmware request.
If the udev you are using still supports to handle firmware request,
you can write your load helper and add your rule for handling
the special case. Otherwise, you need to write code to monitor
the netlink uevents from the kernel and handle your firmware
loading request.
Thanks,
Ming Lei
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:14 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> Which userspace helper programs for (automatic) firmware loading
> are used? Can be udev configured to use own program for loading
> firmware instead that udev integrated which looking for firmware
> only in /lib/firmware files?
The code to load firmware from userspace has been removed from udev, so
that's not going to work at all, sorry.
greg k-h
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:16 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271543.23527@pali>
On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
> > > Hello,
> > >
> > > wifi driver wl1251 needs NVS calibration data for working.
> > > These data are loaded by driver via request_firmware from
> > > userspace file: ti-connectivity/wl1251-nvs.bin. In
> > > linux-fimrware git tree there is generic wl1251-nvs.bin
> > > file which is used by default.
> > >
> > > Driver wl1251 is used on Nokia N900 cellphone for its wifi
> > > chip. This cellphone has one special MTD partition (called
> > > CAL) where are stored some configuration data in special
> > > binary (key-value) format. And there is also stored correct
> > > calibration data for specific device (each device has
> > > different data). It is preferred to use those data instead
> > > generic one (provided by linux-firmware git tree).
> > >
> > > Now my question is: How to correctly load calibration data
> > > from special Nokia N900 CAL partition into wl1251 kernel
> > > driver?
> >
> > It is better to let user space script handle the request.
> >
>
> Yes, this makes sense. Implementing CAL parser in kernel wl1251
> driver would be hard...
>
> > > By default kernel reads ti-connectivity/wl1251-nvs.bin file
> > > from VFS if exists without any userspace support. If it
> > > fails then it fallback to loading via udev.
> >
> > You can remove or rename this file so that loading from user
> > space can be triggered.
> >
>
> It is no so easy... In case when CAL does not contains NVS data
> then we want to use this generic NVS file. And telling everybody
> to rename this is file is not good solution...
But that's up to your system configuration, not the kernel. Make a
userspace package for the firmware that creates it in the format you
need it to be in, for the hardware you have, and then there would not be
any need for a kernel change, right?
greg k-h
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 15:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127151655.GB23064@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 2389 bytes --]
On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> >
> > <pali.rohar@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > wifi driver wl1251 needs NVS calibration data for
> > > > working. These data are loaded by driver via
> > > > request_firmware from userspace file:
> > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > tree there is generic wl1251-nvs.bin file which is used
> > > > by default.
> > > >
> > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > wifi chip. This cellphone has one special MTD partition
> > > > (called CAL) where are stored some configuration data
> > > > in special binary (key-value) format. And there is also
> > > > stored correct calibration data for specific device
> > > > (each device has different data). It is preferred to
> > > > use those data instead generic one (provided by
> > > > linux-firmware git tree).
> > > >
> > > > Now my question is: How to correctly load calibration
> > > > data from special Nokia N900 CAL partition into wl1251
> > > > kernel driver?
> > >
> > > It is better to let user space script handle the request.
> >
> > Yes, this makes sense. Implementing CAL parser in kernel
> > wl1251 driver would be hard...
> >
> > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > file from VFS if exists without any userspace support.
> > > > If it fails then it fallback to loading via udev.
> > >
> > > You can remove or rename this file so that loading from
> > > user space can be triggered.
> >
> > It is no so easy... In case when CAL does not contains NVS
> > data then we want to use this generic NVS file. And telling
> > everybody to rename this is file is not good solution...
>
> But that's up to your system configuration, not the kernel.
> Make a userspace package for the firmware that creates it in
> the format you need it to be in, for the hardware you have,
> and then there would not be any need for a kernel change,
> right?
>
> greg k-h
Not so simple as you think. Some parts of NVS data are configured
based on location and cellular station. Data are not static.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 15:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <20141127151448.GA23064@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 683 bytes --]
On Thursday 27 November 2014 16:14:48 Greg Kroah-Hartman wrote:
> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > Which userspace helper programs for (automatic) firmware
> > loading are used? Can be udev configured to use own program
> > for loading firmware instead that udev integrated which
> > looking for firmware only in /lib/firmware files?
>
> The code to load firmware from userspace has been removed from
> udev, so that's not going to work at all, sorry.
>
> greg k-h
Ok and how to load (dynamic) firmware files into kernel? What is
preferred way if not udev (because it removed that support)?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH net-next] netpoll: delete defconfig references to obsolete NETPOLL_TRAP
From: Paul Gortmaker @ 2014-11-27 15:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Paul Gortmaker
In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll:
Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this
Kconfig option was removed. So remove references to it from
all defconfigs as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/arm/configs/davinci_all_defconfig | 1 -
arch/powerpc/configs/85xx/ge_imp3a_defconfig | 1 -
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1 -
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 1 -
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1 -
arch/powerpc/configs/86xx/sbc8641d_defconfig | 1 -
arch/powerpc/configs/c2k_defconfig | 1 -
arch/powerpc/configs/ppc64_defconfig | 1 -
arch/powerpc/configs/ppc64e_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/powerpc/configs/pseries_defconfig | 1 -
arch/powerpc/configs/pseries_le_defconfig | 1 -
arch/tile/configs/tilegx_defconfig | 1 -
arch/tile/configs/tilepro_defconfig | 1 -
14 files changed, 14 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index f95f72d62db7..759f9b0053e2 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -97,7 +97,6 @@ CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
index dc939de9b5b0..b4c4b469e320 100644
--- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig
+++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
@@ -100,7 +100,6 @@ CONFIG_NETDEVICES=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_FS_ENET=y
diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
index e5a648115ada..7cb9719abf3d 100644
--- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
+++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
@@ -113,7 +113,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
index 8317b6010ba6..ecabf625d249 100644
--- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
@@ -114,7 +114,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 124d66f0282c..4a4a86fb0d3d 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -165,7 +165,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
diff --git a/arch/powerpc/configs/86xx/sbc8641d_defconfig b/arch/powerpc/configs/86xx/sbc8641d_defconfig
index 1e151594c691..99ea8746bbaf 100644
--- a/arch/powerpc/configs/86xx/sbc8641d_defconfig
+++ b/arch/powerpc/configs/86xx/sbc8641d_defconfig
@@ -167,7 +167,6 @@ CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
diff --git a/arch/powerpc/configs/c2k_defconfig b/arch/powerpc/configs/c2k_defconfig
index 59734916986a..8a08d6dcb0b4 100644
--- a/arch/powerpc/configs/c2k_defconfig
+++ b/arch/powerpc/configs/c2k_defconfig
@@ -211,7 +211,6 @@ CONFIG_MV643XX_ETH=y
# CONFIG_NETDEV_10000 is not set
# CONFIG_ATM_DRIVERS is not set
CONFIG_NETCONSOLE=m
-CONFIG_NETPOLL_TRAP=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_KEYBOARD is not set
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 20bc5e2d368d..5830d735c5c3 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -154,7 +154,6 @@ CONFIG_WINDFARM_PM121=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index c3a3269b0865..67885b2d70aa 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -103,7 +103,6 @@ CONFIG_NETDEVICES=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VORTEX=y
CONFIG_ACENIC=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index fec5870f1818..ad6d6b5af7d7 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -629,7 +629,6 @@ CONFIG_SLIP_SMART=y
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_VIRTIO_NET=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_JOYDEV=m
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index dd2a9cab4b50..1f97364017c7 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -133,7 +133,6 @@ CONFIG_DM_UEVENT=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/powerpc/configs/pseries_le_defconfig b/arch/powerpc/configs/pseries_le_defconfig
index d2008887eb8c..ac7ca5852827 100644
--- a/arch/powerpc/configs/pseries_le_defconfig
+++ b/arch/powerpc/configs/pseries_le_defconfig
@@ -134,7 +134,6 @@ CONFIG_DM_UEVENT=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_NETCONSOLE=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=m
CONFIG_VIRTIO_NET=m
CONFIG_VHOST_NET=m
diff --git a/arch/tile/configs/tilegx_defconfig b/arch/tile/configs/tilegx_defconfig
index 91de7dd7427f..37dc9364c4a1 100644
--- a/arch/tile/configs/tilegx_defconfig
+++ b/arch/tile/configs/tilegx_defconfig
@@ -218,7 +218,6 @@ CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=y
CONFIG_VETH=m
CONFIG_NET_DSA_MV88E6060=y
diff --git a/arch/tile/configs/tilepro_defconfig b/arch/tile/configs/tilepro_defconfig
index c7702b7ab7a5..76a2781dec2c 100644
--- a/arch/tile/configs/tilepro_defconfig
+++ b/arch/tile/configs/tilepro_defconfig
@@ -337,7 +337,6 @@ CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
-CONFIG_NETPOLL_TRAP=y
CONFIG_TUN=y
CONFIG_VETH=m
CONFIG_NET_DSA_MV88E6060=y
--
1.9.2
^ permalink raw reply related
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 15:34 UTC (permalink / raw)
To: Pali Rohár
Cc: Greg Kroah-Hartman, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271624.03066@pali>
On Thu, Nov 27, 2014 at 11:24 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 27 November 2014 16:14:48 Greg Kroah-Hartman wrote:
>> On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
>> > Which userspace helper programs for (automatic) firmware
>> > loading are used? Can be udev configured to use own program
>> > for loading firmware instead that udev integrated which
>> > looking for firmware only in /lib/firmware files?
>>
>> The code to load firmware from userspace has been removed from
>> udev, so that's not going to work at all, sorry.
>>
>> greg k-h
>
> Ok and how to load (dynamic) firmware files into kernel? What is
> preferred way if not udev (because it removed that support)?
As I said, it isn't difficult to write a helper with uevent monitor for
your case, and you can refer to mdev or android's implementation.
Thanks,
Ming Lei
^ permalink raw reply
* Re: bug in networking code causes GPF
From: Дениска-редиска @ 2014-11-27 15:41 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: linux-net, netdev, linux-kernel, minipli, fw
well, I will try to disable CONFIG_PAX_MEMORY_SANITIZE.
Will take some time to make sure that this resolve the issue
Цитирование Daniel Borkmann <dborkman@redhat.com> :
> On 11/27/2014 02:35 PM, Дениска-редиска wrote:
> > hello,
> >
> > i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
> > Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
> >
> > There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
> Hmm, looks pretty much like ...
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54903
> ... which was a bug in the grsec patch set.
> Does your grsec kernel have:
> commit 0fa213cce614ad25a79acbd06f37f1e9022134d9
> Author: Brad Spengler <spender@grsecurity.net>
> Date: Fri Oct 31 17:29:20 2014 -0400
> From: Mathias Krause <minipli@googlemail.com>
> To: PaX Team <pageexec@freemail.hu>
> Cc: Brad Spengler <spender@grsecurity.net>, Mathias Krause
> <minipli@googlemail.com>
> Subject: [PATCH] pax: don't sanitize RCU slab caches
> We cannot sanitize SLAB_DESTROY_BY_RCU slab caches in kmem_cache_free()
> as there might be readers in this RCU period, wanting to access the
> object.
> Fix this, for now, by marking those with SLAB_NO_SANITIZE. Hopefully we
> can have a real fix later on. But this should fix the RCU stalls and
> netfilter conntrack related problems.
> This patch should go on top of the previous patch.
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> > [354497.931834] general protection fault: 0000 [#1] SMP
> > [354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
> > [354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> > [354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
> > [354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
> > [354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
> > [354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
> > [354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > [354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
> > [354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
> > [354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
> > [354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> > [354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
> > [354497.932973] Stack:
> > [354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
> > [354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
> > [354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
> > [354497.933304] Call Trace:
> > [354497.933347] <IRQ>
> > [354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
> > [354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
> > [354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
> > [354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> > [354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
> > [354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> > [354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
> > [354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
> > [354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
> > [354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
> > [354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
> > [354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
> > [354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
> > [354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
> > [354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
> > [354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
> > [354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
> > [354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
> > [354497.934441] <EOI>
> > [354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
> > [354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> > [354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
> > [354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
> > [354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> > [354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
> > [354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
> > [354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
> > [354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
> > [354497.935456] RSP <ffff88021fd03b98>
> > [354497.935965] ---[ end trace 7d6f660245b2d541 ]---
> > [354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
> > [354498.016801] Rebooting in 10 seconds.
> >
> >
> > [674944.621564] general protection fault: 0000 [#1] SMP
> > [674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
> > [674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> > [674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
> > [674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
> > [674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
> > [674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
> > [674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
> > [674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
> > [674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
> > [674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
> > [674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
> > [674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
> > [674944.622701] Stack:
> > [674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
> > [674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
> > [674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
> > [674944.623031] Call Trace:
> > [674944.623077] <IRQ>
> > [674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
> > [674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
> > [674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
> > [674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
> > [674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
> > [674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
> > [674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
> > [674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
> > [674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
> > [674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
> > [674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
> > [674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
> > [674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
> > [674944.623906] <EOI>
> > [674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
> > [674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
> > [674944.624536] RSP <ffff88021fc03ce8>
> > [674944.625020] ---[ end trace 8035e2b5322bab00 ]---
> > [674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
> > [674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> > [674944.706711] Rebooting in 10 seconds.
> >
> >
> > [7523332.314991] general protection fault: 0000 [#1] SMP
> > [7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
> > [7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
> > [7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
> > [7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
> > [7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
> > [7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
> > [7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
> > [7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
> > [7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
> > [7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
> > [7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
> > [7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
> > [7523332.317679] Stack:
> > [7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
> > [7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
> > [7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
> > [7523332.318026] Call Trace:
> > [7523332.318072] <IRQ>
> > [7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
> > [7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> > [7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> > [7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> > [7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> > [7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
> > [7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
> > [7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
> > [7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
> > [7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
> > [7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
> > [7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
> > [7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
> > [7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
> > [7523332.318999] <EOI>
> > [7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
> > [7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
> > [7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
> > [7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> > [7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> > [7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> > [7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> > [7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
> > [7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
> > [7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
> > [7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
> > [7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
> > [7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
> > [7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
> > [7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
> > [7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
> > [7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
> > [7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
> > [7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
> > [7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
> > [7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
> > [7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> > [7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
> > [7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
> > [7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
> > [7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
> > [7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
> > [7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
> > [7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
> > [7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
> > [7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
> > [7523332.321579] RSP <ffff88021fa03bf8>
> > [7523332.322094] ---[ end trace 0e21b79561002306 ]---
> > [7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net] rtnetlink: release net refcnt on error in do_setlink()
From: Eric W. Biederman @ 2014-11-27 15:48 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <1417079775-9287-1-git-send-email-nicolas.dichtel@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> rtnl_link_get_net() holds a reference on the 'struct net', we need to release
> it in case of error.
>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Doh!
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
> net/core/rtnetlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index b9b7dfaf202b..76321ea442c3 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -1498,6 +1498,7 @@ static int do_setlink(const struct sk_buff *skb,
> goto errout;
> }
> if (!netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) {
> + put_net(net);
> err = -EPERM;
> goto errout;
> }
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Greg Kroah-Hartman @ 2014-11-27 15:58 UTC (permalink / raw)
To: Pali Rohár
Cc: Ming Lei, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Pavel Machek, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201411271622.58916@pali>
On Thu, Nov 27, 2014 at 04:22:58PM +0100, Pali Rohár wrote:
> On Thursday 27 November 2014 16:16:55 Greg Kroah-Hartman wrote:
> > On Thu, Nov 27, 2014 at 03:43:23PM +0100, Pali Rohár wrote:
> > > On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> > > > On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
> > >
> > > <pali.rohar@gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > wifi driver wl1251 needs NVS calibration data for
> > > > > working. These data are loaded by driver via
> > > > > request_firmware from userspace file:
> > > > > ti-connectivity/wl1251-nvs.bin. In linux-fimrware git
> > > > > tree there is generic wl1251-nvs.bin file which is used
> > > > > by default.
> > > > >
> > > > > Driver wl1251 is used on Nokia N900 cellphone for its
> > > > > wifi chip. This cellphone has one special MTD partition
> > > > > (called CAL) where are stored some configuration data
> > > > > in special binary (key-value) format. And there is also
> > > > > stored correct calibration data for specific device
> > > > > (each device has different data). It is preferred to
> > > > > use those data instead generic one (provided by
> > > > > linux-firmware git tree).
> > > > >
> > > > > Now my question is: How to correctly load calibration
> > > > > data from special Nokia N900 CAL partition into wl1251
> > > > > kernel driver?
> > > >
> > > > It is better to let user space script handle the request.
> > >
> > > Yes, this makes sense. Implementing CAL parser in kernel
> > > wl1251 driver would be hard...
> > >
> > > > > By default kernel reads ti-connectivity/wl1251-nvs.bin
> > > > > file from VFS if exists without any userspace support.
> > > > > If it fails then it fallback to loading via udev.
> > > >
> > > > You can remove or rename this file so that loading from
> > > > user space can be triggered.
> > >
> > > It is no so easy... In case when CAL does not contains NVS
> > > data then we want to use this generic NVS file. And telling
> > > everybody to rename this is file is not good solution...
> >
> > But that's up to your system configuration, not the kernel.
> > Make a userspace package for the firmware that creates it in
> > the format you need it to be in, for the hardware you have,
> > and then there would not be any need for a kernel change,
> > right?
> >
> > greg k-h
>
> Not so simple as you think. Some parts of NVS data are configured
> based on location and cellular station. Data are not static.
Then you need a dynamic program that you control, in userspace, to dump
the needed data into the kernel. Don't try to do it with "static"
firmware files. Use the binary sysfs file interface for this if you
want.
good luck,
greg k-h
^ permalink raw reply
* [PATCH] staging: r8188eu: Add new device ID for DLink GO-USB-N150
From: Larry Finger @ 2014-11-27 16:10 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
The DLink GO-USB-N150 with revision B1 uses this driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 65a257f..d3cbcc4 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -47,6 +47,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
+ {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
{} /* Terminating entry */
};
--
2.1.2
^ permalink raw reply related
* Re: [PATCH] staging: r8188eu: Add new device ID for DLink GO-USB-N150
From: Greg KH @ 2014-11-27 16:28 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, netdev
In-Reply-To: <1417104621-9504-1-git-send-email-Larry.Finger@lwfinger.net>
On Thu, Nov 27, 2014 at 10:10:21AM -0600, Larry Finger wrote:
> The DLink GO-USB-N150 with revision B1 uses this driver.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 65a257f..d3cbcc4 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -47,6 +47,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
> {USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
> {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
> {USB_DEVICE(0x2001, 0x3310)}, /* Dlink DWA-123 REV D1 */
> + {USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
> {USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
> {} /* Terminating entry */
> };
> --
> 2.1.2
Should this also go to stable kernels?
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox