* [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
* 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
* 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
* 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: 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 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: 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] 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
* [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
* [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: 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: 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: ks8851-ml: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/micrel/ks8851_mll.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/micrel/ks8851_mll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
index 0fba153..075f4e2 100644
--- a/drivers/net/ethernet/micrel/ks8851_mll.c
+++ b/drivers/net/ethernet/micrel/ks8851_mll.c
@@ -915,7 +915,7 @@ static int ks_net_open(struct net_device *netdev)
struct ks_net *ks = netdev_priv(netdev);
int err;
-#define KS_INT_FLAGS (IRQF_DISABLED|IRQF_TRIGGER_LOW)
+#define KS_INT_FLAGS IRQF_TRIGGER_LOW
/* lock the card, even if we may not actually do anything
* else at the moment.
*/
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: pxa168_eth: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 4:04 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Michael Opdenacker
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index 4ae0c74..fff6246 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1123,8 +1123,7 @@ static int pxa168_eth_open(struct net_device *dev)
struct pxa168_eth_private *pep = netdev_priv(dev);
int err;
- err = request_irq(dev->irq, pxa168_eth_int_handler,
- IRQF_DISABLED, dev->name, dev);
+ err = request_irq(dev->irq, pxa168_eth_int_handler, 0, dev->name, dev);
if (err) {
dev_err(&dev->dev, "can't assign irq\n");
return -EAGAIN;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: lantiq_etop: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 3:59 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/lantiq_etop.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/lantiq_etop.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index bfdb0686..6a6c1f7 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -282,8 +282,7 @@ ltq_etop_hw_init(struct net_device *dev)
if (IS_TX(i)) {
ltq_dma_alloc_tx(&ch->dma);
- request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
- "etop_tx", priv);
+ request_irq(irq, ltq_etop_dma_irq, 0, "etop_tx", priv);
} else if (IS_RX(i)) {
ltq_dma_alloc_rx(&ch->dma);
for (ch->dma.desc = 0; ch->dma.desc < LTQ_DESC_NUM;
@@ -291,8 +290,7 @@ ltq_etop_hw_init(struct net_device *dev)
if (ltq_etop_alloc_skb(ch))
return -ENOMEM;
ch->dma.desc = 0;
- request_irq(irq, ltq_etop_dma_irq, IRQF_DISABLED,
- "etop_rx", priv);
+ request_irq(irq, ltq_etop_dma_irq, 0, "etop_rx", priv);
}
ch->dma.irq = irq;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: hp100: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 3:51 UTC (permalink / raw)
To: perex; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/hp/hp100.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/hp/hp100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c
index e3c7c69..91227d0 100644
--- a/drivers/net/ethernet/hp/hp100.c
+++ b/drivers/net/ethernet/hp/hp100.c
@@ -1097,7 +1097,7 @@ static int hp100_open(struct net_device *dev)
/* New: if bus is PCI or EISA, interrupts might be shared interrupts */
if (request_irq(dev->irq, hp100_interrupt,
lp->bus == HP100_BUS_PCI || lp->bus ==
- HP100_BUS_EISA ? IRQF_SHARED : IRQF_DISABLED,
+ HP100_BUS_EISA ? IRQF_SHARED : 0,
"hp100", dev)) {
printk("hp100: %s: unable to get IRQ %d\n", dev->name, dev->irq);
return -EAGAIN;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] net: fec: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-13 3:44 UTC (permalink / raw)
To: davem, fabio.estevam
Cc: frank.li, B38611, jim_baxter, netdev, linux-kernel,
Michael Opdenacker
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;
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH for-net] net/mlx4_en: Check device state when setting coalescing
From: David Miller @ 2013-09-13 3:42 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, gideonn, eugenia
In-Reply-To: <1378998680-7546-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Thu, 12 Sep 2013 18:11:20 +0300
> From: Eugenia Emantayev <eugenia@mellanox.com>
>
> When the device is down, CQs are freed. We must check the device state
> to avoid issuing firmware commands on non existing CQs.
>
> CC: Or Gerlitz <ogerlitz@mellanox.com>
> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: bridge: Clamp forward_delay when enabling STP
From: David Miller @ 2013-09-13 3:32 UTC (permalink / raw)
To: herbert; +Cc: shemminger, netdev
In-Reply-To: <20130912071204.GA16548@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 12 Sep 2013 17:12:05 +1000
> At some point limits were added to forward_delay. However, the
> limits are only enforced when STP is enabled. This created a
> scenario where you could have a value outside the allowed range
> while STP is disabled, which then stuck around even after STP
> is enabled.
>
> This patch fixes this by clamping the value when we enable STP.
>
> I had to move the locking around a bit to ensure that there is
> no window where someone could insert a value outside the range
> while we're in the middle of enabling STP.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks Herbert.
^ permalink raw reply
* Re: [PATCH 1/1] resubmit bridge: fix message_age_timer calculation
From: David Miller @ 2013-09-13 3:31 UTC (permalink / raw)
To: cphealy; +Cc: stephen, netdev, bridge, buytenh
In-Reply-To: <1378960667-5092-1-git-send-email-cphealy@gmail.com>
From: Chris Healy <cphealy@gmail.com>
Date: Wed, 11 Sep 2013 21:37:47 -0700
> This changes the message_age_timer calculation to use the BPDU's max age as
> opposed to the local bridge's max age. This is in accordance with section
> 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification.
>
> With the current implementation, when running with very large bridge
> diameters, convergance will not always occur even if a root bridge is
> configured to have a longer max age.
>
> Tested successfully on bridge diameters of ~200.
>
> Signed-off-by: Chris Healy <cphealy@gmail.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] net: tulip: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-13 3:27 UTC (permalink / raw)
To: michael.opdenacker; +Cc: grundler, netdev, linux-kernel
In-Reply-To: <1378959624-4123-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Thu, 12 Sep 2013 06:20:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/dec/tulip/de4x5.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>
Applied.
^ permalink raw reply
* Re: [PATCH] ethernet: amd: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-13 3:27 UTC (permalink / raw)
To: michael.opdenacker
Cc: rusty, benh, silviupopescu1990, geert, netdev, linux-kernel
In-Reply-To: <1378957970-3666-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Thu, 12 Sep 2013 05:52:50 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/amd/sun3lance.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>
Applied.
^ permalink raw reply
* Re: [PATCH] ehea: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-13 3:27 UTC (permalink / raw)
To: michael.opdenacker; +Cc: cascardo, netdev, linux-kernel
In-Reply-To: <1378957571-3574-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Thu, 12 Sep 2013 05:46:11 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/ibm/ehea/ehea_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>
Applied.
^ permalink raw reply
* Re: [PATCH] bfin_mac: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-13 3:27 UTC (permalink / raw)
To: michael.opdenacker
Cc: richardcochran, jg1.han, jiri, mugunthanvnm, uclinux-dist-devel,
netdev, linux-kernel
In-Reply-To: <1378956943-3470-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Thu, 12 Sep 2013 05:35:43 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/adi/bfin_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>
Applied.
^ permalink raw reply
* Re: [PATCHv2 net] xen-netback: count number required slots for an skb more carefully
From: David Miller @ 2013-09-13 3:23 UTC (permalink / raw)
To: david.vrabel
Cc: xen-devel, konrad.wilk, boris.ostrovsky, netdev, ian.campbell
In-Reply-To: <1378907568-8062-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Wed, 11 Sep 2013 14:52:48 +0100
> From: David Vrabel <david.vrabel@citrix.com>
>
> When a VM is providing an iSCSI target and the LUN is used by the
> backend domain, the generated skbs for direct I/O writes to the disk
> have large, multi-page skb->data but no frags.
>
> With some lengths and starting offsets, xen_netbk_count_skb_slots()
> would be one short because the simple calculation of
> DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
> decisions made by start_new_rx_buffer() which does not guarantee
> responses are fully packed.
...
> Fix this by counting the number of required slots more carefully. In
> xen_netbk_count_skb_slots(), more closely follow the algorithm used by
> xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
> is the dry-run equivalent of netbk_gop_frag_copy().
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> --
> v2: xen_netbk_* -> xenvif_* to match new style
Thanks for resolving this into a final patch after so much back and
forth :-)
I assume you want this queued up for -stable, and can you check if
there is any non-trivial backporting for earlier kernels?
^ 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