* [PATCH] net: natsemi: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:16 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/natsemi/
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/natsemi/jazzsonic.c | 3 +--
drivers/net/ethernet/natsemi/xtsonic.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c b/drivers/net/ethernet/natsemi/jazzsonic.c
index c20766c..79257f7 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -83,8 +83,7 @@ static int jazzsonic_open(struct net_device* dev)
{
int retval;
- retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
- "sonic", dev);
+ retval = request_irq(dev->irq, sonic_interrupt, 0, "sonic", dev);
if (retval) {
printk(KERN_ERR "%s: unable to get IRQ %d.\n",
dev->name, dev->irq);
diff --git a/drivers/net/ethernet/natsemi/xtsonic.c b/drivers/net/ethernet/natsemi/xtsonic.c
index c2e0256..4da172a 100644
--- a/drivers/net/ethernet/natsemi/xtsonic.c
+++ b/drivers/net/ethernet/natsemi/xtsonic.c
@@ -95,8 +95,7 @@ static int xtsonic_open(struct net_device *dev)
{
int retval;
- retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
- "sonic", dev);
+ retval = request_irq(dev->irq, sonic_interrupt, 0, "sonic", dev);
if (retval) {
printk(KERN_ERR "%s: unable to get IRQ %d.\n",
dev->name, dev->irq);
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: pasemi: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:21 UTC (permalink / raw)
To: olof; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/pasemi/pasemi_mac.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/pasemi/pasemi_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
index c498181..5b65356 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1219,7 +1219,7 @@ static int pasemi_mac_open(struct net_device *dev)
snprintf(mac->tx_irq_name, sizeof(mac->tx_irq_name), "%s tx",
dev->name);
- ret = request_irq(mac->tx->chan.irq, pasemi_mac_tx_intr, IRQF_DISABLED,
+ ret = request_irq(mac->tx->chan.irq, pasemi_mac_tx_intr, 0,
mac->tx_irq_name, mac->tx);
if (ret) {
dev_err(&mac->pdev->dev, "request_irq of irq %d failed: %d\n",
@@ -1230,7 +1230,7 @@ static int pasemi_mac_open(struct net_device *dev)
snprintf(mac->rx_irq_name, sizeof(mac->rx_irq_name), "%s rx",
dev->name);
- ret = request_irq(mac->rx->chan.irq, pasemi_mac_rx_intr, IRQF_DISABLED,
+ ret = request_irq(mac->rx->chan.irq, pasemi_mac_rx_intr, 0,
mac->rx_irq_name, mac->rx);
if (ret) {
dev_err(&mac->pdev->dev, "request_irq of irq %d failed: %d\n",
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: smsc: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:27 UTC (permalink / raw)
To: steve.glendinning, davem
Cc: netdev, linux-kernel, will.deacon, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
code in drivers/net/ethernet/smsc/
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/smsc/smc91x.h | 2 +-
drivers/net/ethernet/smsc/smsc9420.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
index 370e13d..5730fe2 100644
--- a/drivers/net/ethernet/smsc/smc91x.h
+++ b/drivers/net/ethernet/smsc/smc91x.h
@@ -271,7 +271,7 @@ static inline void mcf_outsw(void *a, unsigned char *p, int l)
#define SMC_insw(a, r, p, l) mcf_insw(a + r, p, l)
#define SMC_outsw(a, r, p, l) mcf_outsw(a + r, p, l)
-#define SMC_IRQ_FLAGS (IRQF_DISABLED)
+#define SMC_IRQ_FLAGS 0
#else
diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index ffa5c4a..5f9e79f 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -1356,8 +1356,7 @@ static int smsc9420_open(struct net_device *dev)
smsc9420_reg_write(pd, INT_STAT, 0xFFFFFFFF);
smsc9420_pci_flush_write(pd);
- result = request_irq(irq, smsc9420_isr, IRQF_SHARED | IRQF_DISABLED,
- DRV_NAME, pd);
+ result = request_irq(irq, smsc9420_isr, IRQF_SHARED, DRV_NAME, pd);
if (result) {
smsc_warn(IFUP, "Unable to use IRQ = %d", irq);
result = -ENODEV;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: ps3_gelic: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:33 UTC (permalink / raw)
To: geoff; +Cc: netdev, cbe-oss-dev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/toshiba/ps3_gelic_net.c
It's a NOOP since 2.6.35 and I will remove it one day ;)
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 9c805e0..f7f2ef4 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1726,7 +1726,7 @@ static int ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
goto fail_alloc_irq;
}
result = request_irq(card->irq, gelic_card_interrupt,
- IRQF_DISABLED, netdev->name, card);
+ 0, netdev->name, card);
if (result) {
dev_info(ctodev(card), "%s:request_irq failed (%d)\n",
--
1.8.1.2
^ permalink raw reply related
* RE: [PATCH] net: fec: remove deprecated IRQF_DISABLED
From: Duan Fugang-B38611 @ 2013-09-13 4:45 UTC (permalink / raw)
To: Michael Opdenacker, davem@davemloft.net, Estevam Fabio-R49496
Cc: frank.li@freescale.net, jim_baxter@mentor.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1379043878-6376-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker [mailto:michael.opdenacker@free-electrons.com]
Data: Friday, September 13, 2013 11:45 AM
> To: davem@davemloft.net; Estevam Fabio-R49496
> Cc: frank.li@freescale.net; Duan Fugang-B38611; jim_baxter@mentor.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Opdenacker
> Subject: [PATCH] net: fec: remove deprecated IRQF_DISABLED
>
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/freescale/fec_main.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index f9aacf5..b2793b9 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2199,7 +2199,7 @@ fec_probe(struct platform_device *pdev)
> goto failed_irq;
> }
> ret = devm_request_irq(&pdev->dev, irq, fec_enet_interrupt,
> - IRQF_DISABLED, pdev->name, ndev);
> + 0, pdev->name, ndev);
> if (ret)
> goto failed_irq;
Can you remove the flag for all net driver such as:
/linux-next/linux-2.6$ grep -nr "IRQF_DISABLED" drivers/net/ethernet/
drivers/net/ethernet/adi/bfin_mac.c:533: IRQF_DISABLED, "EMAC_WAKE", dev);
drivers/net/ethernet/adi/bfin_mac.c:1689: IRQF_DISABLED, "EMAC_RX", ndev);
drivers/net/ethernet/lantiq_etop.c:285: request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
drivers/net/ethernet/lantiq_etop.c:294: request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
drivers/net/ethernet/micrel/ks8851_mll.c:918:#define KS_INT_FLAGS (IRQF_DISABLED|IRQF_TRIGGER_LOW)
drivers/net/ethernet/pasemi/pasemi_mac.c:1222: ret = request_irq(mac->tx->chan.irq, pasemi_mac_tx_intr, IRQF_DISABLED,
drivers/net/ethernet/pasemi/pasemi_mac.c:1233: ret = request_irq(mac->rx->chan.irq, pasemi_mac_rx_intr, IRQF_DISABLED,
drivers/net/ethernet/amd/sun3lance.c:361: if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3 Lance", dev) < 0) {
drivers/net/ethernet/dec/tulip/de4x5.c:356: Added IRQF_DISABLED temporary fix from
drivers/net/ethernet/dec/tulip/de4x5.c:1324: if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
drivers/net/ethernet/freescale/fec_main.c:2212: IRQF_DISABLED, pdev->name, ndev);
drivers/net/ethernet/smsc/smc91x.h:274:#define SMC_IRQ_FLAGS (IRQF_DISABLED)
drivers/net/ethernet/smsc/smsc9420.c:1359: result = request_irq(irq, smsc9420_isr, IRQF_SHARED | IRQF_DISABLED,
drivers/net/ethernet/ibm/ehea/ehea_main.c:1288: IRQF_DISABLED, port->int_aff_name, port);
drivers/net/ethernet/ibm/ehea/ehea_main.c:1306: IRQF_DISABLED, pr->int_send_name,
drivers/net/ethernet/ibm/ehea/ehea_main.c:3323: ehea_interrupt_neq, IRQF_DISABLED,
drivers/net/ethernet/korina.c:999: IRQF_DISABLED, "Korina ethernet Rx", dev);
drivers/net/ethernet/korina.c:1006: IRQF_DISABLED, "Korina ethernet Tx", dev);
drivers/net/ethernet/korina.c:1015: IRQF_DISABLED, "Ethernet Overflow", dev);
drivers/net/ethernet/korina.c:1024: IRQF_DISABLED, "Ethernet Underflow", dev);
drivers/net/ethernet/marvell/pxa168_eth.c:1127: IRQF_DISABLED, dev->name, dev);
drivers/net/ethernet/natsemi/jazzsonic.c:86: retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
drivers/net/ethernet/natsemi/xtsonic.c:98: retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1729: IRQF_DISABLED, netdev->name, card);
drivers/net/ethernet/hp/hp100.c:1100: HP100_BUS_EISA ? IRQF_SHARED : IRQF_DISABLED,
drivers/net/ethernet/broadcom/bcm63xx_enet.c:929: ret = request_irq(priv->irq_rx, bcm_enet_isr_dma, IRQF_DISABLED,
drivers/net/ethernet/broadcom/bcm63xx_enet.c:935: IRQF_DISABLED, dev->name, dev);
drivers/net/ethernet/broadcom/bcm63xx_enet.c:2159: IRQF_DISABLED, dev->name, dev);
drivers/net/ethernet/broadcom/bcm63xx_enet.c:2165: IRQF_DISABLED, dev->name, dev);
Thanks,
Andy
^ permalink raw reply
* Re: [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Eric Dumazet @ 2013-09-13 5:40 UTC (permalink / raw)
To: Jun Chen; +Cc: edumazet, davem, netdev, linux-kernel
In-Reply-To: <1379065643.3390.3.camel@chenjun-workstation>
On Fri, 2013-09-13 at 05:47 -0400, Jun Chen wrote:
> On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> > On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > > When try to add node to list in __inet_hash_nolisten function, first get the
> > > list and then to lock for using, but in extremeness case, others can del this
> > > node before locking it, then the node should be null.So this patch try to lock
> > > firstly and then get the list for using to avoid this race condition.
> >
> > I suspect another bug. This should not happen.
> >
> > Care to describe the problem you got ?
> >
> > Thanks
> >
> >
>
> Ok, I just got this call stack and no more info, pls help to look it.
> thanks!
>
> <1>[ 88.548263] BUG: unable to handle kernel NULL pointer dereference at
> 00000004
> <1>[ 88.548490] IP: [] __inet_hash_nolisten+0xc1/0x140
> <4>[ 88.548617] *pde = 00000000
> <4>[ 88.549927] EIP is at __inet_hash_nolisten+0xc1/0x140
> <4>[ 88.550008] EAX: 00000000 EBX: e08c0000 ECX: edf846e0 EDX: e08c0020
> <4>[ 88.550055] ESI: c20213c0 EDI: edc12dc0 EBP: ce4bfdfc ESP: ce4bfde8
> <4>[ 88.550137] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
> <4>[ 88.550184] CR0: 80050033 CR2: 00000004 CR3: 2b4ff000 CR4: 001007d0
> <4>[ 88.550266] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> <4>[ 88.550346] DR6: ffff0ff0 DR7: 00000400
> <0>[ 88.550392] Process WebViewCoreThre (pid: 2137, ti=ce4be000
> task=eb193c80 task.ti=ce4be000)
> <0>[ 88.551746] Call Trace:
> <4>[ 88.551797] [] __inet_hash_connect+0x295/0x2d0
> <4>[ 88.551883] [] inet_hash_connect+0x40/0x50
> <4>[ 88.551932] [] ? inet_unhash+0x90/0x90
> <4>[ 88.551981] [] ? __inet_lookup_listener+0x1b0/0x1b0
> <4>[ 88.552067] [] tcp_v4_connect+0x247/0x4a0
> <4>[ 88.552117] [] ? lock_sock_nested+0x3e/0x50
> <4>[ 88.552205] [] inet_stream_connect+0xe2/0x290
> <4>[ 88.552254] [] ? _copy_from_user+0x35/0x50
> <4>[ 88.552342] [] sys_connect+0xb2/0xd0
> <4>[ 88.552393] [] ? alloc_file+0x20/0xa0
> <4>[ 88.552441] [] ? tcp_setsockopt+0x50/0x60
> <4>[ 88.552525] [] ? fget_light+0x44/0xe0
> <4>[ 88.552574] [] ? sock_common_setsockopt+0x27/0x40
> <4>[ 88.552659] [] ? _copy_from_user+0x35/0x50
> <4>[ 88.552708] [] sys_socketcall+0xab/0x2b0
> <4>[ 88.552790] [] ? trace_hardirqs_on_thunk+0xc/0x10
> <4>[ 88.552840] [] syscall_call+0x7/0xb
> <4>[ 88.552923] [] ? mutex_trylock+0x30/0x140
>
This makes no sense to me. This could be a random memory corruption.
Do you have disassembly of __inet_hash_nolisten ?
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Eric W. Biederman @ 2013-09-13 5:50 UTC (permalink / raw)
To: Francesco Ruggeri
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <CA+HUmGgyCsc-er6iB_mqg9whMyaquGWinkHOQEuEHbFCYVrXBw@mail.gmail.com>
Francesco Ruggeri <fruggeri@aristanetworks.com> writes:
> That would be great. There would still be one scenario to take care of though:
>
> - veth interfaces v0 and v1 are in namespaces ns0 and ns1.
> - process p0 unregisters v0, which also causes v1 to be unregistered.
> When p0 enters netdev_run_todo both v0 and v1 are in net_todo_list and
> have been unlisted from their namespaces.
> - then in p0's netdev_run_todo:
So I looked at this a little more and this problem appears largely
specific to veth. In the normal case the caller of dellink has to hold
a reference to the network namespace to find the device to delete.
So I think the solution is just to warp the interface of the second
device into the network namespace of the device we are actually
deleting.
I will buy that similar situations can happen with other virtual devices
that have one foot in two network namespaces, and I expect the same
solution will apply.
So the patch below looks like the solution. If there is more than one
device that needs this treatment perhaps the code should be moved
into a helper function rather than expanded inline.
Does this look like it will fix your issue?
Eric
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index da86652..5922066 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -423,6 +423,19 @@ static void veth_dellink(struct net_device *dev, struct list_head *head)
unregister_netdevice_queue(dev, head);
if (peer) {
+ struct net *net = dev_net(dev);
+ if (dev_net(peer) != net) {
+ /* Move the peer to the same net to avoid teardown races */
+ char peer_name[IFNAMSIZ];
+ int err;
+ snprintf(fb_name, IFNAMSIZ, "dev%d", peer->ifindex);
+ err = dev_change_net_namespace(peer, net, peer_name);
+ if (err) {
+ pr_emerg("%s: failed to move %s to peers net: %d\n",
+ __func__, peer->name, err);
+ BUG();
+ }
+ }
priv = netdev_priv(peer);
RCU_INIT_POINTER(priv->peer, NULL);
unregister_netdevice_queue(peer, head);
^ permalink raw reply related
* Re: [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Jun Chen @ 2013-09-13 14:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: edumazet, davem, netdev, linux-kernel
In-Reply-To: <1379050801.24408.29.camel@edumazet-glaptop>
On Thu, 2013-09-12 at 22:40 -0700, Eric Dumazet wrote:
> On Fri, 2013-09-13 at 05:47 -0400, Jun Chen wrote:
> > On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> > > On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > > > When try to add node to list in __inet_hash_nolisten function, first get the
> > > > list and then to lock for using, but in extremeness case, others can del this
> > > > node before locking it, then the node should be null.So this patch try to lock
> > > > firstly and then get the list for using to avoid this race condition.
> > >
> > > I suspect another bug. This should not happen.
> > >
> > > Care to describe the problem you got ?
> > >
> > > Thanks
> > >
> > >
> >
> > Ok, I just got this call stack and no more info, pls help to look it.
> > thanks!
> >
> > <1>[ 88.548263] BUG: unable to handle kernel NULL pointer dereference at
> > 00000004
> > <1>[ 88.548490] IP: [] __inet_hash_nolisten+0xc1/0x140
> > <4>[ 88.548617] *pde = 00000000
> > <4>[ 88.549927] EIP is at __inet_hash_nolisten+0xc1/0x140
> > <4>[ 88.550008] EAX: 00000000 EBX: e08c0000 ECX: edf846e0 EDX: e08c0020
> > <4>[ 88.550055] ESI: c20213c0 EDI: edc12dc0 EBP: ce4bfdfc ESP: ce4bfde8
> > <4>[ 88.550137] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
> > <4>[ 88.550184] CR0: 80050033 CR2: 00000004 CR3: 2b4ff000 CR4: 001007d0
> > <4>[ 88.550266] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > <4>[ 88.550346] DR6: ffff0ff0 DR7: 00000400
> > <0>[ 88.550392] Process WebViewCoreThre (pid: 2137, ti=ce4be000
> > task=eb193c80 task.ti=ce4be000)
> > <0>[ 88.551746] Call Trace:
> > <4>[ 88.551797] [] __inet_hash_connect+0x295/0x2d0
> > <4>[ 88.551883] [] inet_hash_connect+0x40/0x50
> > <4>[ 88.551932] [] ? inet_unhash+0x90/0x90
> > <4>[ 88.551981] [] ? __inet_lookup_listener+0x1b0/0x1b0
> > <4>[ 88.552067] [] tcp_v4_connect+0x247/0x4a0
> > <4>[ 88.552117] [] ? lock_sock_nested+0x3e/0x50
> > <4>[ 88.552205] [] inet_stream_connect+0xe2/0x290
> > <4>[ 88.552254] [] ? _copy_from_user+0x35/0x50
> > <4>[ 88.552342] [] sys_connect+0xb2/0xd0
> > <4>[ 88.552393] [] ? alloc_file+0x20/0xa0
> > <4>[ 88.552441] [] ? tcp_setsockopt+0x50/0x60
> > <4>[ 88.552525] [] ? fget_light+0x44/0xe0
> > <4>[ 88.552574] [] ? sock_common_setsockopt+0x27/0x40
> > <4>[ 88.552659] [] ? _copy_from_user+0x35/0x50
> > <4>[ 88.552708] [] sys_socketcall+0xab/0x2b0
> > <4>[ 88.552790] [] ? trace_hardirqs_on_thunk+0xc/0x10
> > <4>[ 88.552840] [] syscall_call+0x7/0xb
> > <4>[ 88.552923] [] ? mutex_trylock+0x30/0x140
> >
>
> This makes no sense to me. This could be a random memory corruption.
>
> Do you have disassembly of __inet_hash_nolisten ?
>
>
I had disassembled the __inet_hash_nolisten+0xc1,
the corruption is located on the:
__inet_hash_nolisten -->
__sk_nulls_add_node_rcu(sk, list); -->
__sk_nulls_add_node_rcu -->
static inline void hlist_nulls_add_head_rcu(struct hlist_nulls_node *n,
struct hlist_nulls_head *h)
{
...
if (!is_a_nulls(first))
first->pprev = &n->next; (this line trigger corruption)
...
}
Thanks!
^ permalink raw reply
* Re: [PATCH] net: fec: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 6:06 UTC (permalink / raw)
To: Duan Fugang-B38611
Cc: davem@davemloft.net, Estevam Fabio-R49496, frank.li@freescale.net,
jim_baxter@mentor.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <9848F2DB572E5649BA045B288BE08FBE016DAF7D@039-SN2MPN1-022.039d.mgd.msft.net>
Hi Andy,
Thank you for your time reviewing this patch.
On 09/13/2013 06:45 AM, Duan Fugang-B38611 wrote:
>
> Can you remove the flag for all net driver such as:
>
> /linux-next/linux-2.6$ grep -nr "IRQF_DISABLED" drivers/net/ethernet/
> drivers/net/ethernet/adi/bfin_mac.c:533: IRQF_DISABLED, "EMAC_WAKE", dev);
> drivers/net/ethernet/adi/bfin_mac.c:1689: IRQF_DISABLED, "EMAC_RX", ndev);
> drivers/net/ethernet/lantiq_etop.c:285: request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
> drivers/net/ethernet/lantiq_etop.c:294: request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
> drivers/net/ethernet/micrel/ks8851_mll.c:918:#define KS_INT_FLAGS (IRQF_DISABLED|IRQF_TRIGGER_LOW)
> drivers/net/ethernet/pasemi/pasemi_mac.c:1222: ret = request_irq(mac->tx->chan.irq, pasemi_mac_tx_intr, IRQF_DISABLED,
> drivers/net/ethernet/pasemi/pasemi_mac.c:1233: ret = request_irq(mac->rx->chan.irq, pasemi_mac_rx_intr, IRQF_DISABLED,
> drivers/net/ethernet/amd/sun3lance.c:361: if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3 Lance", dev) < 0) {
> drivers/net/ethernet/dec/tulip/de4x5.c:356: Added IRQF_DISABLED temporary fix from
> drivers/net/ethernet/dec/tulip/de4x5.c:1324: if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
> drivers/net/ethernet/freescale/fec_main.c:2212: IRQF_DISABLED, pdev->name, ndev);
> drivers/net/ethernet/smsc/smc91x.h:274:#define SMC_IRQ_FLAGS (IRQF_DISABLED)
> drivers/net/ethernet/smsc/smsc9420.c:1359: result = request_irq(irq, smsc9420_isr, IRQF_SHARED | IRQF_DISABLED,
> drivers/net/ethernet/ibm/ehea/ehea_main.c:1288: IRQF_DISABLED, port->int_aff_name, port);
> drivers/net/ethernet/ibm/ehea/ehea_main.c:1306: IRQF_DISABLED, pr->int_send_name,
> drivers/net/ethernet/ibm/ehea/ehea_main.c:3323: ehea_interrupt_neq, IRQF_DISABLED,
> drivers/net/ethernet/korina.c:999: IRQF_DISABLED, "Korina ethernet Rx", dev);
> drivers/net/ethernet/korina.c:1006: IRQF_DISABLED, "Korina ethernet Tx", dev);
> drivers/net/ethernet/korina.c:1015: IRQF_DISABLED, "Ethernet Overflow", dev);
> drivers/net/ethernet/korina.c:1024: IRQF_DISABLED, "Ethernet Underflow", dev);
> drivers/net/ethernet/marvell/pxa168_eth.c:1127: IRQF_DISABLED, dev->name, dev);
> drivers/net/ethernet/natsemi/jazzsonic.c:86: retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
> drivers/net/ethernet/natsemi/xtsonic.c:98: retval = request_irq(dev->irq, sonic_interrupt, IRQF_DISABLED,
> drivers/net/ethernet/toshiba/ps3_gelic_net.c:1729: IRQF_DISABLED, netdev->name, card);
> drivers/net/ethernet/hp/hp100.c:1100: HP100_BUS_EISA ? IRQF_SHARED : IRQF_DISABLED,
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:929: ret = request_irq(priv->irq_rx, bcm_enet_isr_dma, IRQF_DISABLED,
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:935: IRQF_DISABLED, dev->name, dev);
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:2159: IRQF_DISABLED, dev->name, dev);
> drivers/net/ethernet/broadcom/bcm63xx_enet.c:2165: IRQF_DISABLED, dev->name, dev);
Already done, through separate patches. Some have already been merged by
Dave Miller.
Cheers,
Michael.
--
Michael Opdenacker, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
^ permalink raw reply
* Re: [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Eric Dumazet @ 2013-09-13 6:12 UTC (permalink / raw)
To: Jun Chen; +Cc: edumazet, davem, netdev, linux-kernel
In-Reply-To: <1379080900.23597.18.camel@chenjun-workstation>
On Fri, 2013-09-13 at 10:01 -0400, Jun Chen wrote:
> On Thu, 2013-09-12 at 22:40 -0700, Eric Dumazet wrote:
> > On Fri, 2013-09-13 at 05:47 -0400, Jun Chen wrote:
> > > On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> > > > On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > > > > When try to add node to list in __inet_hash_nolisten function, first get the
> > > > > list and then to lock for using, but in extremeness case, others can del this
> > > > > node before locking it, then the node should be null.So this patch try to lock
> > > > > firstly and then get the list for using to avoid this race condition.
> > > >
> > > > I suspect another bug. This should not happen.
> > > >
> > > > Care to describe the problem you got ?
> > > >
> > > > Thanks
> > > >
> > > >
> > >
> > > Ok, I just got this call stack and no more info, pls help to look it.
> > > thanks!
> > >
> > > <1>[ 88.548263] BUG: unable to handle kernel NULL pointer dereference at
> > > 00000004
> > > <1>[ 88.548490] IP: [] __inet_hash_nolisten+0xc1/0x140
> > > <4>[ 88.548617] *pde = 00000000
> > > <4>[ 88.549927] EIP is at __inet_hash_nolisten+0xc1/0x140
> > > <4>[ 88.550008] EAX: 00000000 EBX: e08c0000 ECX: edf846e0 EDX: e08c0020
> > > <4>[ 88.550055] ESI: c20213c0 EDI: edc12dc0 EBP: ce4bfdfc ESP: ce4bfde8
> > > <4>[ 88.550137] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
> > > <4>[ 88.550184] CR0: 80050033 CR2: 00000004 CR3: 2b4ff000 CR4: 001007d0
> > > <4>[ 88.550266] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > > <4>[ 88.550346] DR6: ffff0ff0 DR7: 00000400
> > > <0>[ 88.550392] Process WebViewCoreThre (pid: 2137, ti=ce4be000
> > > task=eb193c80 task.ti=ce4be000)
> > > <0>[ 88.551746] Call Trace:
> > > <4>[ 88.551797] [] __inet_hash_connect+0x295/0x2d0
> > > <4>[ 88.551883] [] inet_hash_connect+0x40/0x50
> > > <4>[ 88.551932] [] ? inet_unhash+0x90/0x90
> > > <4>[ 88.551981] [] ? __inet_lookup_listener+0x1b0/0x1b0
> > > <4>[ 88.552067] [] tcp_v4_connect+0x247/0x4a0
> > > <4>[ 88.552117] [] ? lock_sock_nested+0x3e/0x50
> > > <4>[ 88.552205] [] inet_stream_connect+0xe2/0x290
> > > <4>[ 88.552254] [] ? _copy_from_user+0x35/0x50
> > > <4>[ 88.552342] [] sys_connect+0xb2/0xd0
> > > <4>[ 88.552393] [] ? alloc_file+0x20/0xa0
> > > <4>[ 88.552441] [] ? tcp_setsockopt+0x50/0x60
> > > <4>[ 88.552525] [] ? fget_light+0x44/0xe0
> > > <4>[ 88.552574] [] ? sock_common_setsockopt+0x27/0x40
> > > <4>[ 88.552659] [] ? _copy_from_user+0x35/0x50
> > > <4>[ 88.552708] [] sys_socketcall+0xab/0x2b0
> > > <4>[ 88.552790] [] ? trace_hardirqs_on_thunk+0xc/0x10
> > > <4>[ 88.552840] [] syscall_call+0x7/0xb
> > > <4>[ 88.552923] [] ? mutex_trylock+0x30/0x140
> > >
> >
> > This makes no sense to me. This could be a random memory corruption.
> >
> > Do you have disassembly of __inet_hash_nolisten ?
> >
> >
> I had disassembled the __inet_hash_nolisten+0xc1,
> the corruption is located on the:
>
> __inet_hash_nolisten -->
> __sk_nulls_add_node_rcu(sk, list); -->
> __sk_nulls_add_node_rcu -->
> static inline void hlist_nulls_add_head_rcu(struct hlist_nulls_node *n,
> struct hlist_nulls_head *h)
> {
> ...
> if (!is_a_nulls(first))
> first->pprev = &n->next; (this line trigger corruption)
> ...
> }
first is NULL, which is absolutely not possible.
You had a memory corruption on some sort.
^ permalink raw reply
* ICMP rate limiting in IPv4 but not in IPv6
From: Andy Johnson @ 2013-09-13 7:21 UTC (permalink / raw)
To: netdev
Hello,
I am trying to understand the difference between ICMP rate limiting
in IPv4 and in IPv6.
In IPv4 we have the ability to rate limit ICMPv4 while in IPv6 we do not have
this ability.
To be more code-oriented:
The icmpv4_xrlim_allow() method does inspect the rate mask,
(net->ipv4.sysctl_icmp_ratemask)
whereas the icmpv6_xrlim_allow() method does not inspect the rate mask.
I do not understand why, for example, we can rate limit ICMPv4 messages of
Echo Reply and not rate limit ICMPv6 messages of Echo Reply.
See: icmp_ratemask and icmp_ratelimit in Documentation/networking/ip-sysctl.txt
I believe there is some reason behind it (adding checking of rate mask
seems to me trivial). I try to figure out the reason behind this but I did not
find anything reasonable,
Does anybody happen to know ?
Regards,
Andy
^ permalink raw reply
* [patch -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 8:37 UTC (permalink / raw)
To: Jeff Kirsher
Cc: kernel-janitors, netdev, Patrick McHardy, e1000-devel,
Bruce Allan, Jesse Brandeburg, David S. Miller, John Ronciak,
Greg Kroah-Hartman
If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
wrap and the check on the next line can underflow. This is one of those
bugs which can be triggered by the user if you have namespaces
configured.
This is a static checker fix and I'm not sure what the impact is.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 95d5430..24e3883 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
{
struct igbvf_adapter *adapter = netdev_priv(netdev);
- int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+ unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH 4/7] ptp: switch to use gpiolib
From: Linus Walleij @ 2013-09-13 8:38 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-gpio@vger.kernel.org, Imre Kaloz, Krzysztof Halasa,
Alexandre Courbot, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org
In-Reply-To: <20130910141912.GB5088@netboy>
On Tue, Sep 10, 2013 at 4:19 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:
>> Hi Richard, I'm seeking an ACK on this patch to take it throug
>> the GPIO tree as part of a clean-out of custom GPIO implementations.
>
> I don't have this hardware for testing (it is really obsolete now),
> but the change looks okay to me.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Thanks, I have found numerous active hobbyists using the
IXP4-based NSLU2 NAS machine for various things - mostly
non-network related as it happens, so it'll be with us for a
while I think.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] net: smsc: remove deprecated IRQF_DISABLED
From: Will Deacon @ 2013-09-13 8:56 UTC (permalink / raw)
To: Michael Opdenacker
Cc: steve.glendinning@shawell.net, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davidb
In-Reply-To: <1379046467-6900-1-git-send-email-michael.opdenacker@free-electrons.com>
[adding David Brown]
On Fri, Sep 13, 2013 at 05:27:47AM +0100, Michael Opdenacker wrote:
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/smsc/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
> ---
> drivers/net/ethernet/smsc/smc91x.h | 2 +-
> drivers/net/ethernet/smsc/smsc9420.c | 3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> index 370e13d..5730fe2 100644
> --- a/drivers/net/ethernet/smsc/smc91x.h
> +++ b/drivers/net/ethernet/smsc/smc91x.h
> @@ -271,7 +271,7 @@ static inline void mcf_outsw(void *a, unsigned char *p, int l)
> #define SMC_insw(a, r, p, l) mcf_insw(a + r, p, l)
> #define SMC_outsw(a, r, p, l) mcf_outsw(a + r, p, l)
>
> -#define SMC_IRQ_FLAGS (IRQF_DISABLED)
> +#define SMC_IRQ_FLAGS 0
After this change, the only machine that defines the flags to anything other
than IRQF_TRIGGER_RISING is MSM, which uses IRQF_TRIGGER_HIGH. David: do
you actually need this? The irq_chip code under mach-msm doesn't seem to
distinguish between the two.
Will
^ permalink raw reply
* RE: [patch -stable] igbvf: integer wrapping bug setting the mtu
From: David Laight @ 2013-09-13 8:58 UTC (permalink / raw)
To: Dan Carpenter, Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, Alex Duyck, John Ronciak,
Tushar Dave, David S. Miller, Mitch Williams, Patrick McHardy,
Greg Kroah-Hartman, e1000-devel, netdev, kernel-janitors
In-Reply-To: <20130913083736.GK19211@elgon.mountain>
> If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
> wrap and the check on the next line can underflow. This is one of those
> bugs which can be triggered by the user if you have namespaces
> configured.
>
> This is a static checker fix and I'm not sure what the impact is.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> index 95d5430..24e3883 100644
> --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> @@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
> static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> {
> struct igbvf_adapter *adapter = netdev_priv(netdev);
> - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>
> if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
It is safer to check:
if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
David
^ permalink raw reply
* Re: [PATCH] Inet-hashtable: Change the range of sk->hash lock to avoid the race condition.
From: Jun Chen @ 2013-09-13 9:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: edumazet, davem, netdev, linux-kernel, Jun Chen
In-Reply-To: <1378987204.24408.1.camel@edumazet-glaptop>
On Thu, 2013-09-12 at 05:00 -0700, Eric Dumazet wrote:
> On Thu, 2013-09-12 at 12:32 -0400, Jun Chen wrote:
> > When try to add node to list in __inet_hash_nolisten function, first get the
> > list and then to lock for using, but in extremeness case, others can del this
> > node before locking it, then the node should be null.So this patch try to lock
> > firstly and then get the list for using to avoid this race condition.
>
> I suspect another bug. This should not happen.
>
> Care to describe the problem you got ?
>
> Thanks
>
>
Ok, I just got this call stack and no more info, pls help to look it.
thanks!
<1>[ 88.548263] BUG: unable to handle kernel NULL pointer dereference at
00000004
<1>[ 88.548490] IP: [] __inet_hash_nolisten+0xc1/0x140
<4>[ 88.548617] *pde = 00000000
<4>[ 88.549927] EIP is at __inet_hash_nolisten+0xc1/0x140
<4>[ 88.550008] EAX: 00000000 EBX: e08c0000 ECX: edf846e0 EDX: e08c0020
<4>[ 88.550055] ESI: c20213c0 EDI: edc12dc0 EBP: ce4bfdfc ESP: ce4bfde8
<4>[ 88.550137] DS: 007b ES: 007b FS: 00d8 GS: 003b SS: 0068
<4>[ 88.550184] CR0: 80050033 CR2: 00000004 CR3: 2b4ff000 CR4: 001007d0
<4>[ 88.550266] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
<4>[ 88.550346] DR6: ffff0ff0 DR7: 00000400
<0>[ 88.550392] Process WebViewCoreThre (pid: 2137, ti=ce4be000
task=eb193c80 task.ti=ce4be000)
<0>[ 88.551746] Call Trace:
<4>[ 88.551797] [] __inet_hash_connect+0x295/0x2d0
<4>[ 88.551883] [] inet_hash_connect+0x40/0x50
<4>[ 88.551932] [] ? inet_unhash+0x90/0x90
<4>[ 88.551981] [] ? __inet_lookup_listener+0x1b0/0x1b0
<4>[ 88.552067] [] tcp_v4_connect+0x247/0x4a0
<4>[ 88.552117] [] ? lock_sock_nested+0x3e/0x50
<4>[ 88.552205] [] inet_stream_connect+0xe2/0x290
<4>[ 88.552254] [] ? _copy_from_user+0x35/0x50
<4>[ 88.552342] [] sys_connect+0xb2/0xd0
<4>[ 88.552393] [] ? alloc_file+0x20/0xa0
<4>[ 88.552441] [] ? tcp_setsockopt+0x50/0x60
<4>[ 88.552525] [] ? fget_light+0x44/0xe0
<4>[ 88.552574] [] ? sock_common_setsockopt+0x27/0x40
<4>[ 88.552659] [] ? _copy_from_user+0x35/0x50
<4>[ 88.552708] [] sys_socketcall+0xab/0x2b0
<4>[ 88.552790] [] ? trace_hardirqs_on_thunk+0xc/0x10
<4>[ 88.552840] [] syscall_call+0x7/0xb
<4>[ 88.552923] [] ? mutex_trylock+0x30/0x140
^ permalink raw reply
* Re: [patch -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 9:54 UTC (permalink / raw)
To: David Laight
Cc: kernel-janitors, netdev, Patrick McHardy, e1000-devel,
Bruce Allan, Jesse Brandeburg, David S. Miller, John Ronciak,
Greg Kroah-Hartman
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B732F@saturn3.aculab.com>
On Fri, Sep 13, 2013 at 09:58:25AM +0100, David Laight wrote:
> > If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
> > wrap and the check on the next line can underflow. This is one of those
> > bugs which can be triggered by the user if you have namespaces
> > configured.
> >
> > This is a static checker fix and I'm not sure what the impact is.
> >
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> > diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
> > index 95d5430..24e3883 100644
> > --- a/drivers/net/ethernet/intel/igbvf/netdev.c
> > +++ b/drivers/net/ethernet/intel/igbvf/netdev.c
> > @@ -2342,7 +2342,7 @@ static struct net_device_stats *igbvf_get_stats(struct net_device *netdev)
> > static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> > {
> > struct igbvf_adapter *adapter = netdev_priv(netdev);
> > - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> >
> > if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> > dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
>
> It is safer to check:
> if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
>
I believe my fix is already 100% safe... Where is the bug in my code?
Your fix harder to read because of the additional math and because it's
checking "new_mtu" when we care about "max_frame".
regards,
dan carpenter
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH net 1/1] qlcnic: Fix VF reset recovery
From: Manish Chopra @ 2013-09-13 10:13 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev
o At the time of firmware hang "adapter->need_fw_reset" variable gets
set but after re-initialization of firmware OR at the time of VF
re-initialization that variable was not getting cleared which
was leading to failure in VF reset recovery.Fix it by clearing
this variable before re-initializing VF
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
---
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
index 652cc13..392b9bd 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c
@@ -1561,6 +1561,7 @@ static int qlcnic_sriov_vf_reinit_driver(struct qlcnic_adapter *adapter)
{
int err;
+ adapter->need_fw_reset = 0;
qlcnic_83xx_reinit_mbx_work(adapter->ahw->mailbox);
qlcnic_83xx_enable_mbx_interrupt(adapter);
--
1.5.6
^ permalink raw reply related
* RE: [patch -stable] igbvf: integer wrapping bug setting the mtu
From: David Laight @ 2013-09-13 10:55 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, Tushar Dave, David S. Miller, Mitch Williams,
Patrick McHardy, Greg Kroah-Hartman, e1000-devel, netdev,
kernel-janitors
In-Reply-To: <20130913095423.GH19256@mwanda>
> > > static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
> > > {
> > > struct igbvf_adapter *adapter = netdev_priv(netdev);
> > > - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > > + unsigned int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
> > >
> > > if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
> > > dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
> >
> > It is safer to check:
> > if ((new_mtu < 68) || (new_mtu > MAX_JUMBO_FRAME_SIZE - ETH_HLEN - ETH_FCS_LEN)) {
> >
>
> I believe my fix is already 100% safe... Where is the bug in my code?
>
> Your fix harder to read because of the additional math and because it's
> checking "new_mtu" when we care about "max_frame".
I don't like the window check on two variables.
However if ETH_HLEN and ETH_FCS_LEN are 'int' (not an unsigned type)
and 'new_mtu' is just below MAX_INT then the signed arithmetic
could overflow - generating an indeterminate value.
In which case 'max_frame' might not exceed MAX_JUMBO_FRAME_SIZE.
David
^ permalink raw reply
* Re: [PATCH net 0/4] bridge: Fix problems around the PVID
From: Toshiaki Makita @ 2013-09-13 12:06 UTC (permalink / raw)
To: David Miller
Cc: makita.toshiaki, vyasevic, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <20130912.160033.779509034953932316.davem@davemloft.net>
On Thu, 2013-09-12 at 16:00 -0400, David Miller wrote:
> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> Date: Tue, 10 Sep 2013 19:27:54 +0900
>
> > There seem to be some undesirable behaviors related with PVID.
> > 1. It has no effect assigning PVID to a port. PVID cannot be applied
> > to any frame regardless of whether we set it or not.
> > 2. FDB entries learned via frames applied PVID are registered with
> > VID 0 rather than VID value of PVID.
> > 3. We can set 0 or 4095 as a PVID that are not allowed in IEEE 802.1Q.
> > This leads interoperational problems such as sending frames with VID
> > 4095, which is not allowed in IEEE 802.1Q, and treating frames with VID
> > 0 as they belong to VLAN 0, which is expected to be handled as they have
> > no VID according to IEEE 802.1Q.
> >
> > Note: 2nd and 3rd problems are potential and not exposed unless 1st problem
> > is fixed, because we cannot activate PVID due to it.
>
> Please work out the issues in patch #2 with Vlad and resubmit this
> series.
>
> Thank you.
I'm hovering between whether we should fix the issue by changing vlan 0
interface behavior in 8021q module or enabling a bridge port to sending
priority-tagged frames, or another better way.
If you could comment it, I'd appreciate it :)
BTW, I think what is discussed in patch #2 is another problem about
handling priority-tags, and it exists without this patch set applied.
It looks like that we should prepare another patch set than this to fix
that problem.
Should I include patches that fix the priority-tags problem in this
patch set and resubmit them all together?
Thanks,
Toshiaki Makita
>
> --
> 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 4/7] ptp: switch to use gpiolib
From: Krzysztof Halasa @ 2013-09-13 12:22 UTC (permalink / raw)
To: Linus Walleij
Cc: Richard Cochran, linux-gpio@vger.kernel.org, Imre Kaloz,
Alexandre Courbot, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org
In-Reply-To: <CACRpkdZOCkLmgQHZSiqQfvLp=WzNsaE5AcY3siJ0b=bL0Xv8Pg@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> Thanks, I have found numerous active hobbyists using the
> IXP4-based NSLU2 NAS machine for various things - mostly
> non-network related as it happens, so it'll be with us for a
> while I think.
IXP42x are most probably "end of life" in the commercial sense, but the
newer IXP46x/455 and even newer IXP43x are still being sold. For
example, Gateworks have a couple of IXP43x boards ("Cambria") which
I personally find interesting, for some specific applications.
There is no platform driver for Cambria in the official Linux, guess it
should be changed.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] ISDN, hfcpci Fix uninitialized warning
From: Prarit Bhargava @ 2013-09-13 12:28 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, dzickus, Karsten Keil
Fix uninitialized warning. Use same fix as
drivers/media/pci/cx18/cx18-alsa-main.c
CC [M] drivers/isdn/hardware/mISDN/hfcpci.o
drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
drivers/isdn/hardware/mISDN/hfcpci.c:2298:2: error: ignoring return
value of ‘driver_for_each_device’, declared with attribute
warn_unused_result [-Werror=unused-result]
(void) driver_for_each_device(&hfc_driver.driver, NULL, arg,
^
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dzickus@redhat.com
Cc: Karsten Keil <isdn@linux-pingi.de>
---
drivers/isdn/hardware/mISDN/hfcpci.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 7f910c7..2373b44 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -2295,8 +2295,12 @@ _hfcpci_softirq(struct device *dev, void *arg)
static void
hfcpci_softirq(void *arg)
{
- (void) driver_for_each_device(&hfc_driver.driver, NULL, arg,
+ int ret;
+
+ ret = driver_for_each_device(&hfc_driver.driver, NULL, arg,
_hfcpci_softirq);
+ if (unlikely(ret))
+ pr_warn("hfcpci_softirq: driver softirq failed\n");
/* if next event would be in the past ... */
if ((s32)(hfc_jiffies + tics - jiffies) <= 0)
--
1.7.9.3
^ permalink raw reply related
* [PATCH] net, vxlan Fix compile warning
From: Prarit Bhargava @ 2013-09-13 12:29 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, jpirko, tgraf, David S. Miller
Fix a unintialized variable warning.
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2240:11: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
vs->sock = sock;
^
drivers/net/vxlan.c:2217:17: note: ‘sock’ was declared here
struct socket *sock;
^
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: jpirko@redhat.com
Cc: tgraf@redhat.com
Cc: "David S. Miller" <davem@davemloft.net>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bf64b41..ed3d7f4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2276,7 +2276,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
- struct socket *sock;
+ struct socket *uninitialized_var(sock);
struct sock *sk;
int rc = 0;
unsigned int h;
--
1.7.9.3
^ permalink raw reply related
* [patch v2 -stable] igbvf: integer wrapping bug setting the mtu
From: Dan Carpenter @ 2013-09-13 12:29 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Jesse Brandeburg, Bruce Allan, Carolyn Wyborny, Don Skidmore,
Greg Rose, Peter P Waskiewicz Jr, Alex Duyck, John Ronciak,
Tushar Dave, David S. Miller, Mitch Williams, Patrick McHardy,
Greg Kroah-Hartman, e1000-devel, netdev, kernel-janitors
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7332@saturn3.aculab.com>
If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can
wrap and the check on the next line can underflow. This is one of those
bugs which can be triggered by the user if you have namespaces
configured.
Also since this is something the user can trigger then we don't want to
have dev_err() message.
This is a static checker fix and I'm not sure what the impact is.
---
v2: reformat and also remove the dev_err()
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 95d5430..8cb7958 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2344,10 +2344,9 @@ static int igbvf_change_mtu(struct net_device *netdev, int new_mtu)
struct igbvf_adapter *adapter = netdev_priv(netdev);
int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
- if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
- dev_err(&adapter->pdev->dev, "Invalid MTU setting\n");
+ if (new_mtu < 68 || new_mtu > INT_MAX - ETH_HLEN - ETH_FCS_LEN ||
+ max_frame > MAX_JUMBO_FRAME_SIZE)
return -EINVAL;
- }
#define MAX_STD_JUMBO_FRAME_SIZE 9234
if (max_frame > MAX_STD_JUMBO_FRAME_SIZE) {
^ permalink raw reply related
* [PATCH] net, mellanox mlx4 Fix compile warnings
From: Prarit Bhargava @ 2013-09-13 12:30 UTC (permalink / raw)
To: netdev; +Cc: Prarit Bhargava, dledford, Amir Vadai, Or Gerlitz
Fix unitialized variable warnings.
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_HW2SW_CQ_wrapper’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2551:16: error: ‘cq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
atomic_dec(&cq->mtt->ref_count);
^
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function ‘mlx4_HW2SW_SRQ_wrapper’:
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:2734:17: error: ‘srq’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
atomic_dec(&srq->mtt->ref_count);
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dledford@redhat.com
Cc: Amir Vadai <amirv@mellanox.com>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
---
.../net/ethernet/mellanox/mlx4/resource_tracker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index dd68763..d703838 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -2563,7 +2563,7 @@ int mlx4_HW2SW_CQ_wrapper(struct mlx4_dev *dev, int slave,
{
int err;
int cqn = vhcr->in_modifier;
- struct res_cq *cq;
+ struct res_cq *uninitialized_var(cq);
err = cq_res_start_move_to(dev, slave, cqn, RES_CQ_ALLOCATED, &cq);
if (err)
@@ -2746,7 +2746,7 @@ int mlx4_HW2SW_SRQ_wrapper(struct mlx4_dev *dev, int slave,
{
int err;
int srqn = vhcr->in_modifier;
- struct res_srq *srq;
+ struct res_srq *uninitialized_var(srq);
err = srq_res_start_move_to(dev, slave, srqn, RES_SRQ_ALLOCATED, &srq);
if (err)
--
1.7.9.3
^ permalink raw reply related
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