* Re: [PATCH net] netlink: fix wrong subscription bitmask to group mapping in binding callbacks
From: David Miller @ 2015-01-09 4:04 UTC (permalink / raw)
To: pablo; +Cc: netdev
In-Reply-To: <1420633915-25475-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 7 Jan 2015 13:31:55 +0100
> The subscription bitmask passed via struct sockaddr_nl is converted to
> the group number when calling the netlink_bind() and netlink_unbind()
> callbacks.
>
> The conversion is however incorrect since bitmask (1 << 0) needs to be
> mapped to group number 1. Note that you cannot specify the group number 0
> (usually known as _NONE) from setsockopt() using NETLINK_ADD_MEMBERSHIP
> since this is rejected through -EINVAL.
>
> This problem became noticeable since 97840cb ("netfilter: nfnetlink:
> fix insufficient validation in nfnetlink_bind") when binding to bitmask
> (1 << 0) in ctnetlink.
>
> Reported-by: Andre Tomt <andre@tomt.net>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This gets rejects when I try to apply it to 'net', please
respin.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] Involve rhashtable_lookup_insert routine
From: David Miller @ 2015-01-09 3:48 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, netdev, Paul.Gortmaker, tipc-discussion, tgraf
In-Reply-To: <1420609318-3261-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Wed, 7 Jan 2015 13:41:51 +0800
> The series aims to involve rhashtable_lookup_insert() to guarantee
> that the process of lookup and insertion of an object from/into hash
> table is finished atomically, allowing rhashtable's users not to
> introduce an extra lock during search and insertion. For example,
> tipc socket is the first user benefiting from this enhancement.
Looks good, series applied.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
^ permalink raw reply
* Re: [PATCH -next] r8169: add support for xmit_more
From: David Miller @ 2015-01-09 3:51 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1420624189-24325-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 7 Jan 2015 10:49:49 +0100
> Delay update of hw tail descriptor if we know that another skb is going
> to be sent.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks.
^ permalink raw reply
* Re: [net v2 0/3][pull request] Intel Wired LAN Driver Updates 2015-01-06
From: David Miller @ 2015-01-09 3:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1420594317-6191-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 6 Jan 2015 17:31:54 -0800
> This series contains fixes to i40e only.
>
> Jesse provides a fix for when the driver was polling with interrupts
> disabled the hardware would occasionally not write back descriptors.
> His fix causes the driver to detect this situation and force an interrupt
> to fire which will flush the stuck descriptor.
>
> Anjali provides a couple of fixes, the first corrects an issue where
> the receive port checksum error counter was incrementing incorrectly with
> UDP encapsulated tunneled traffic. The second fix resolves an issue where
> the driver was examining the outer protocol layer to set the inner protocol
> layer checksum offload. In the case of TCP over IPv6 over an IPv4 based
> VXLAN, the inner checksum offloads would be set to look for IPv4/UDP
> instead of IPv6/TCP, so fixed the issue so that the driver will look at
> the proper layer for encapsulation offload settings.
>
> v2: fixed a bug in patch 01 of the series, where the interrupt rate impacted
> 4 port workloads by reducing throughput.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Add support for few debugfs entries
From: David Miller @ 2015-01-09 3:40 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, anish
In-Reply-To: <1420600683-23289-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 7 Jan 2015 08:47:59 +0530
> This patch series adds support for devlog, cim_la, cim_qcfg and mps_tcam
> debugfs entries.
>
> The patches series is created against 'net-next' tree.
> And includes patches on cxgb4 driver.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net-next] doc: fix the compile error of txtimestamp.c
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:32 -0800
> Vinson reported:
>
> HOSTCC Documentation/networking/timestamping/txtimestamp
> Documentation/networking/timestamping/txtimestamp.c:64:8: error:
> redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:23:0,
> from Documentation/networking/timestamping/txtimestamp.c:33:
> /usr/include/netinet/in.h:456:8: note: originally defined here
> struct in6_pktinfo
> ^
>
> After we sync with libc header, we don't need this ugly hack any more.
>
> Reported-by: Vinson Lee <vlee@twopensource.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next] ipv6: fix redefinition of in6_pktinfo and ip6_mtuinfo
From: David Miller @ 2015-01-09 3:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, carlos, vlee
In-Reply-To: <1420587932-8733-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 6 Jan 2015 15:45:31 -0800
> Both netinet/in.h and linux/ipv6.h define these two structs,
> if we include both of them, we got:
>
> /usr/include/linux/ipv6.h:19:8: error: redefinition of ‘struct in6_pktinfo’
> struct in6_pktinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:524:8: note: originally defined here
> struct in6_pktinfo
> ^
> In file included from txtimestamp.c:40:0:
> /usr/include/linux/ipv6.h:24:8: error: redefinition of ‘struct ip6_mtuinfo’
> struct ip6_mtuinfo {
> ^
> In file included from /usr/include/arpa/inet.h:22:0,
> from txtimestamp.c:33:
> /usr/include/netinet/in.h:531:8: note: originally defined here
> struct ip6_mtuinfo
> ^
> So similarly to what we did for in6_addr, we need to sync with
> libc header on their definitions.
>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: David Miller @ 2015-01-09 3:12 UTC (permalink / raw)
To: kernel.org.gnu; +Cc: eric.dumazet, netdev, herbert
In-Reply-To: <CA+U0gVi1cVB4qbXAkPp1LMmNOaDOD2UaAL4riA6O_Q_SnvMQTA@mail.gmail.com>
From: Dennis Chen <kernel.org.gnu@gmail.com>
Date: Fri, 9 Jan 2015 10:26:48 +0800
> I am very curious about the reason that you're removing the atomic ops
> in the stack, what's the benifit?
1) Do not top post.
2) The reason is, obviously, performance.
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 3:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Is this the below patch you mentioned?
https://lkml.org/lkml/2014/7/23/134
--
Den
^ permalink raw reply
* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Ahmed S. Darwish @ 2015-01-09 3:06 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <54AE6FC1.6050007@pengutronix.de>
On Thu, Jan 08, 2015 at 12:53:37PM +0100, Marc Kleine-Budde wrote:
> On 01/05/2015 07:31 PM, Ahmed S. Darwish wrote:
> >
[...]
> >
> > cf->can_id |= CAN_ERR_CRTL;
> > cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
> >
> > stats->rx_over_errors++;
> > stats->rx_errors++;
> >
> > netif_rx(skb);
> >
> > stats->rx_packets++;
> > stats->rx_bytes += cf->can_dlc;
>
> Another patch would be not to touch cf after netif_rx(), please move the stats handling before calling netif_rx(). Same applies to the kvaser_usb_rx_can_msg() function.
>
BTW, is it guaranteed from the SocketCAN stack that netif_rx()
will never return NET_RX_DROPPED? Because if no guarantee
exists, I guess below fragment cannot be completely correct?
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
netif_rx(skb);
On the other hand, I don't see evan a single CAN driver checking
netif_rx() return value, so maybe such a check is an overkill...
Thanks,
Darwish
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109023421.GA16089@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:34 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>>
>> Thanks, would you pls give me an example of those drivers? I'll study
>> it further...
>
> There are no known drivers doing this currently since that would
> be a bug and they would be fixed quickly. But if you look back
> in history virtio_net was doing this.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
So the only reason for the code '!list_empty()' I can see is to avoid
possible bug code in new drivers, thus pls think if it's possible
that there's a window opened for creating multiple NAPI instances in
the list for the new drivers?
--
Den
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Herbert Xu @ 2015-01-09 2:34 UTC (permalink / raw)
To: Dennis Chen; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <CA+U0gVgS7z601DZvL82EJfYGYb5XQExw9CbnPRpUeN32TWLF7w@mail.gmail.com>
On Fri, Jan 09, 2015 at 10:32:13AM +0800, Dennis Chen wrote:
>
> Thanks, would you pls give me an example of those drivers? I'll study
> it further...
There are no known drivers doing this currently since that would
be a bug and they would be fixed quickly. But if you look back
in history virtio_net was doing this.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, Miller, Eric Dumazet
In-Reply-To: <20150109022752.GA15785@gondor.apana.org.au>
On Fri, Jan 9, 2015 at 10:27 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Jan 09, 2015 at 10:24:18AM +0800, Dennis Chen wrote:
>>
>> Hi Herbert, please see this code piece in napi_poll:
>>
>> /* Some drivers may have called napi_schedule
>> * prior to exhausting their budget.
>> */
>> if (unlikely(!list_empty(&n->poll_list))) {
>> pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
>> n->dev ? n->dev->name : "backlog");
>> goto out_unlock;
>> }
>>
>> Here "Some drivers" may have called napi_schedule to make
>> n->poll_list is not empty, does that mean "Some drivers" will clear
>> NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
>> does that make sense for you question? ;-)
>
> No it tells me that you don't understand the problem at all.
> Those drivers will end up resetting the NAPI_STATE_SCHED bit
> after clearing it.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Thanks, would you pls give me an example of those drivers? I'll study
it further...
--
Den
^ permalink raw reply
* Dear: Account User
From: Helpdesk @ 2015-01-09 2:22 UTC (permalink / raw)
To: netdev
Dear: Account User,
This message is from the System Administrator support center. Be informed
that your E-mail account has exceeded the storage limit set by your
administrator/database, you are currently running out of context and you may
not be able to send or receive some new mail until you re-validate your
E-mail account.
To prevent your email account from been closed, re-validate your mailbox
below please click and visit this site of lick: >>>>
http://survey-upgrade-helpdesk.ezweb123.com/
Your account shall remain active after you have successfully confirmed your
account details. Thank you for your swift response to this notification we
apologize for any inconvenience.
We appreciate your continued help and support.
Regards,
SYSTEM ADMINISTRATOR HELPDESK TEAM 2015
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:28 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, Herbert Xu, Miller, Eric Dumazet
In-Reply-To: <54AE8048.6040105@cogentembedded.com>
hello,
On Thu, Jan 8, 2015 at 9:04 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 1/8/2015 11:22 AM, Dennis Chen wrote:
>
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>
>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>> ---
>> net/core/dev.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>
>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 683d493..b3107ac 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4619,6 +4619,14 @@ static int napi_poll(struct napi_struct *n,
>> struct list_head *repoll)
>> n->dev ? n->dev->name : "backlog");
>> goto out_unlock;
>> }
>> +
>> + /* Some drivers may exit the polling mode when exhaust the
>
>
> s/exhaust/exhausting/.
>
>> + * budget. Set the NAPI_STATE_SCHED bit to prevent multiple NAPI
>> + * instances in the list in case of next device interrupt raised.
>> + */
>> + if (unlikely(!test_and_set_bit(NAPI_STATE_SCHED, &n->state)))
>> + pr_warn_once("%s: exit polling mode after exhaust the
>> budget\n",
>
>
> Likewise. And s/exit/exiting/.
>
> WBR, Sergei
>
will be updated if applied :-)
--
Den
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Herbert Xu @ 2015-01-09 2:27 UTC (permalink / raw)
To: Dennis Chen; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <CA+U0gVgZr-Mhzest1O_vtCWMwuaQmP30DYb8CLXDG8iTobObYQ@mail.gmail.com>
On Fri, Jan 09, 2015 at 10:24:18AM +0800, Dennis Chen wrote:
>
> Hi Herbert, please see this code piece in napi_poll:
>
> /* Some drivers may have called napi_schedule
> * prior to exhausting their budget.
> */
> if (unlikely(!list_empty(&n->poll_list))) {
> pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
> n->dev ? n->dev->name : "backlog");
> goto out_unlock;
> }
>
> Here "Some drivers" may have called napi_schedule to make
> n->poll_list is not empty, does that mean "Some drivers" will clear
> NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
> does that make sense for you question? ;-)
No it tells me that you don't understand the problem at all.
Those drivers will end up resetting the NAPI_STATE_SCHED bit
after clearing it.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Herbert Xu, Miller
In-Reply-To: <1420728671.5947.47.camel@edumazet-glaptop2.roam.corp.google.com>
I am very curious about the reason that you're removing the atomic ops
in the stack, what's the benifit?
On Thu, Jan 8, 2015 at 10:51 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2015-01-08 at 16:22 +0800, Dennis Chen wrote:
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>> ---
>
>
> Well no.
>
> I am removing some atomic ops in the stack, please do not add new ones,
> especially if no driver is that buggy.
>
> The unlikely() wont help the expensive stuff being done here.
>
>
--
Den
^ permalink raw reply
* [PATCH net-next v2 2/2 RESEND] r8152: check the status before submitting rx
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-114-Taiwan-albertk@realtek.com>
Don't submit the rx if the device is unplugged, stopped, or
linking down.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index cd93388..b23426e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
int ret;
+ /* The rx would be stopped, so skip submitting */
+ if (test_bit(RTL8152_UNPLUG, &tp->flags) ||
+ !test_bit(WORK_ENABLE, &tp->flags) || !netif_carrier_ok(tp->netdev))
+ return 0;
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
agg->head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 1/2 RESEND] r8152: call rtl_start_rx after netif_carrier_on
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-114-Taiwan-albertk@realtek.com>
Remove rtl_start_rx() from rtl_enable() and put it after calling
netif_carrier_on().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 57ec23e..cd93388 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2059,7 +2059,7 @@ static int rtl_enable(struct r8152 *tp)
rxdy_gated_en(tp, false);
- return rtl_start_rx(tp);
+ return 0;
}
static int rtl8152_enable(struct r8152 *tp)
@@ -2874,6 +2874,7 @@ static void set_carrier(struct r8152 *tp)
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, &tp->flags);
netif_carrier_on(netdev);
+ rtl_start_rx(tp);
}
} else {
if (tp->speed & LINK_STATUS) {
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 0/2 RESEND] r8152: adjust r8152_submit_rx
From: Hayes Wang @ 2015-01-09 2:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
v2:
Replace the patch #1 with "call rtl_start_rx after netif_carrier_on".
For patch #2, replace checking tp->speed with netif_carrier_ok.
v1:
Avoid r8152_submit_rx() from submitting rx during unexpected
moment. This could reduce the time of stopping rx.
For patch #1, the tp->speed should be updated early. Then,
the patch #2 could use it to check the current linking status.
Hayes Wang (2):
r8152: call rtl_start_rx after netif_carrier_on
r8152: check the status before submitting rx
drivers/net/usb/r8152.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* Re: [PATCH] net: Prevent multiple NAPI instances co-existing in the list
From: Dennis Chen @ 2015-01-09 2:24 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, davem, eric.dumazet
In-Reply-To: <20150108111554.GA8720@gondor.apana.org.au>
On Thu, Jan 8, 2015 at 7:15 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Dennis Chen <kernel.org.gnu@gmail.com> wrote:
>> Some drivers may clear the NAPI_STATE_SCHED bit upon the state of the
>> NAPI instance after exhaust the budget in the poll function, which
>> will open a window for next device interrupt handler to insert a same
>> instance to the list after calling list_add_tail(&n->poll_list,
>> repoll) if we don't set this bit.
>>
>> Signed-off-by: Dennis Chen <kernel.org.gnu@gmail.com>
>
> Which driver is doing this?
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert, please see this code piece in napi_poll:
/* Some drivers may have called napi_schedule
* prior to exhausting their budget.
*/
if (unlikely(!list_empty(&n->poll_list))) {
pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
n->dev ? n->dev->name : "backlog");
goto out_unlock;
}
Here "Some drivers" may have called napi_schedule to make
n->poll_list is not empty, does that mean "Some drivers" will clear
NAPI_STATE_SCHED bit, otherwise the napi_schedule() will do nothing,
does that make sense for you question? ;-)
--
Den
^ permalink raw reply
* Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn_add()
From: Scott Feldman @ 2015-01-09 1:46 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Siva Mannem, Netdev
In-Reply-To: <20150107125301.GE1888@nanopsycho.orion>
On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@gmail.com wrote:
>>Hi,
>>
>>I am trying to understand the ongoing switch device offload effort and
>>am following the discussions. I have a question regarding
>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>enabled on a port that is attached to a bridge that has vlan filtering
>>enabled.
>>
>>If I understand correctly, when IFLA_BRPORT_LEARNING_SYNC is set on a
>>bridge port, fdb entries that are learnt externally(may be learnt by
>>hardware and driver is notified) are synced to bridges fdb using
>>br_fdb_external_learn_add(). The fdb
>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>this method are also deleted by the aging logic after the aging time
>>even though L2 data forwadring happens in hardware.
This is correct...
>> Is there a way
>>where aging can be disabled for these entries? and let the entries be
>>removed only via br_fdb_external_learn_delete()? or am I missing
>>something?
>
> Currently extenaly learned fdb entries are indeed removed during aging
> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
> and not remove that fdbs. What do you think Scott?
Something like that would work, if we added another brport flag to
control that. With the current arrangement, using bridge for aging
out entries, we want br_fdb_cleanup removing the external_learned
fdbs, but if there was another brport flag we could fine tune that.
Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that. I'm
not sure how aging settings for the bridge are pushed down to offload
hw, or if there is a different set for hw.
But, isn't it nice to let Linux bridge control aging? That way,
bridge -s fdb dump shows nice statistics on fdb entries. Hardware
isn't involved in the aging processes (other than being told to remove
an entry). Simple hardware equals simple driver. Linux remains
control point.
-scott
^ permalink raw reply
* Re: [PATCH next] net: e1000e: support txtd update delay via xmit_more
From: Jeff Kirsher @ 2015-01-09 1:22 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <1420624162-24206-1-git-send-email-fw@strlen.de>
On Wed, Jan 7, 2015 at 1:49 AM, Florian Westphal <fw@strlen.de> wrote:
> Don't update tx tail descriptor if queue hasn't been stopped
> and we know at least one more skb will be sent right away.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
Thanks Florian, I will add your patch to my queue.
^ permalink raw reply
* Re: [PATCH net-next] mac80211: silent build warnings
From: Ying Xue @ 2015-01-09 1:00 UTC (permalink / raw)
To: Sergei Shtylyov, johannes; +Cc: netdev, linux-wireless
In-Reply-To: <54AE7F3F.3070802@cogentembedded.com>
On 01/08/2015 08:59 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 1/8/2015 10:04 AM, Ying Xue wrote:
>
>> Silent the following build warnings:
>
>> net/mac80211/mlme.c: In function ‘ieee80211_rx_mgmt_beacon’:
>> net/mac80211/mlme.c:1348:3: warning: ‘pwr_level_cisco’ may be used
>> uninitialized in this function [-Wuninitialized]
>> net/mac80211/mlme.c:1315:6: note: ‘pwr_level_cisco’ was declared here
>
>> Signed-off-by: Ying Xue <ying.xue@windriver.com>
>> ---
>> net/mac80211/mlme.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 2c36c47..13b5506 100644
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -1312,7 +1312,7 @@ static u32 ieee80211_handle_pwr_constr(struct
>> ieee80211_sub_if_data *sdata,
>> {
>> bool has_80211h_pwr = false, has_cisco_pwr = false;
>> int chan_pwr = 0, pwr_reduction_80211h = 0;
>> - int pwr_level_cisco, pwr_level_80211h;
>> + int pwr_level_cisco = 0, pwr_level_80211h = 0;
>
> OK, but why are you also initializing the second variable?
>
Although the second variable is not warned in above compile warning
message, but it should be if we take a look at the code associated with it.
However, as Johannes confirmed, the first change is unnecessary at all.
So please ignore the patch.
Thanks,
Ying
> WBR, Sergei
>
> --
> 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] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Pablo Neira Ayuso @ 2015-01-09 0:05 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <1420756756.1755002.211556745.0418D128@webmail.messagingengine.com>
On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> Hi Pablo,
>
> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > ipv6_find_hdr() function is designed to return the transport protocol.
> > After the proposed change, it will return extension header numbers.
> > This will break existing ip6tables rulesets since the `-p' option
> > relies on this function to match the transport protocol.
> >
> > Note that the AH header is skipped (see code a bit below this
> > problematic fragmentation handling) so the follow up header after the
> > AH header is returned as the transport header.
> >
> > We can probably return the AH protocol number for non-1st fragments.
> > However, that would be something new to ip6tables since nobody has
> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > the user to allow this, but we would accept all kind of fragmented AH
> > traffic through the firewall since we cannot know what transport
> > protocol contains from non-1st fragments (unless I'm missing anything,
> > I need to have a closer look at this again tomorrow with fresher
> > mind).
>
> The code in question is guarded by (_frag_off != 0), so we are
> definitely processing a non-1st fragment currently. The -p match would
> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> will find the real transport (final) header at this point (I hope I
> followed the code correctly here).
Then, Rahul should get things working by modprobing nf_defrag_ipv6.
^ 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