* Re: [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Cong Wang @ 2016-03-10 21:29 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Mahesh Bandewar, David Miller, Mahesh Bandewar, Eric Dumazet,
netdev, Eric W. Biederman, Cong Wang
In-Reply-To: <56E14296.5010103@6wind.com>
On Thu, Mar 10, 2016 at 1:47 AM, Nicolas Dichtel
<nicolas.dichtel@6wind.com> wrote:
> Le 09/03/2016 22:49, Mahesh Bandewar a écrit :
>>
>> From: Mahesh Bandewar <maheshb@google.com>
>>
>> One of the major request (for enhancement) that I have received
>> from various users of IPvlan in L3 mode is its inability to handle
>> IPtables.
>>
>> While looking at the code and how we handle ingress, the problem
>> can be attributed to the asymmetry in the way packets get processed
>> for IPvlan devices configured in L3 mode. L3 mode is supposed to
>> be restrictive and all the L3 decisions need to be taken for the
>> traffic in master's ns. This does happen as expected for egress
>> traffic however on ingress traffic, the IPvlan packet-handler
>> changes the skb->dev and this forces packet to be processed with
>> the IPvlan slave and it's associated ns. This causes above mentioned
>> problem and few other which are not yet reported / attempted. e.g.
>> IPsec with L3 mode or even ingress routing.
>>
>> This could have been solved if we had a way to handover packet to
>> slave and associated ns after completing the L3 phase. This is a
>> non-trivial issue to fix especially looking at IPsec code.
>>
>> This patch series attempts to solve this problem by introducing the
>> device pointer l3_dev which resides in net_device structure in the
>> RX cache line. We initialize the l3_dev to self. This would mean
>> there is no complex logic to when-and-how-to initialize it. Now
>> the stack will use this dev pointer during the L3 phase. This should
>> not alter any existing properties / behavior and also there should
>> not be any additional penalties since it resides in the same RX
>> cache line.
>
> If I understand correctly (and as Cong already said), information are
> leaking
> between netns during the input phase. On the tx side, skb_scrub_packet() is
> called, but not on the rx side. I think it's wrong. There should be an
> explicit
> boundary.
That is not what I am complaining about.
I dislike the trick of switching skb->dev pointer with skb->dev->l3_dev.
This is not how we switch netns, nor the way how netns works.
Look at veth pair or dev_change_net_namespace(), each time when we
switch netns, we need to do a full reregistration or a full reentrance, we
never just switch some pointers to switch netns. This is why I said it breaks
isolation.
Also, it is ugly to hide such a ipvlan-specific pointer for half of the RX code
path.
^ permalink raw reply
* Re: [PATCH net-next V3 00/10] cls_flower hardware offload support
From: David Miller @ 2016-03-10 21:24 UTC (permalink / raw)
To: amir; +Cc: netdev, john.r.fastabend, jiri, ogerlitz, saeedm, hadarh, ronye
In-Reply-To: <1457433758-9193-1-git-send-email-amir@vadai.me>
From: Amir Vadai <amir@vadai.me>
Date: Tue, 8 Mar 2016 12:42:28 +0200
> Please see changes from V2 at the bottom.
>
> This patchset introduces cls_flower hardware offload support over ConnectX-4
> driver, more hardware vendors are welcome to use it too.
...
Series applied, thanks for retaining detailed change history in this series
header posting.
^ permalink raw reply
* Re: [PATCH V5 0/4] net-next: mediatek: add ethernet driver
From: David Miller @ 2016-03-10 21:22 UTC (permalink / raw)
To: blogic
Cc: linux-kernel, netdev, linux-arm-kernel, linux-mediatek,
steven.liu, Carlos.Huang, nbd, igvtee
In-Reply-To: <1457432997-25526-1-git-send-email-blogic@openwrt.org>
From: John Crispin <blogic@openwrt.org>
Date: Tue, 8 Mar 2016 11:29:53 +0100
> This series adds support for the Mediatek ethernet core found on current ARM
> based SoCs. The driver works on MT2701 and MT7623 SoCs
>
> Instead of trying to upstream everything at once I decided to concentrate on
> the important parts required to make current generation silicon work. The V3
> series only includes the code required to make dual MAC setups work and only
> supports the newer QDMA engine.
...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: dsa: Fix cleanup resources upon module removal
From: David Miller @ 2016-03-10 21:21 UTC (permalink / raw)
To: narmstrong
Cc: f.fainelli, andrew, rmk+kernel, pavel.nakonechny, netdev,
linux-kernel
In-Reply-To: <1457429780-7665-1-git-send-email-narmstrong@baylibre.com>
From: Neil Armstrong <narmstrong@baylibre.com>
Date: Tue, 8 Mar 2016 10:36:20 +0100
> The initial commit badly merged into the dsa_resume method instead
> of the dsa_remove_dst method.
> As consequence, the dst->master_netdev->dsa_ptr is not set to NULL on
> removal and re-bind of the dsa device fails with error -17.
>
> Fixes: b0dc635d923c ("net: dsa: cleanup resources upon module removal ")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> net/dsa/dsa.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> David, Florian, Andrew,
>
> This fix is quite urgent since it breaks all the removal cleanup.
Since 'net' is closed, I've applied this to 'net-next' and queue it up for
-stable.
Thanks.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-10 21:19 UTC (permalink / raw)
To: David Miller
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310.160521.1642655131932337300.davem@davemloft.net>
On Thu, Mar 10, 2016 at 04:05:21PM -0500, David Miller wrote:
> >
> > and nobody calls for nf_ct_iterate_cleanup, no?
>
> Oh yes they do, from masq's non-inet notifier. masq registers two
> notifiers, one for generic netdev and one for inetdev.
Thanks a huge David! I'll test it just to be sure.
Cyrill
^ permalink raw reply
* Re: [PATCH net-next 1/1] qede: Fix net-next "make ARCH=x86_64"
From: David Miller @ 2016-03-10 21:19 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1457428184-18336-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Tue, 8 Mar 2016 04:09:44 -0500
> 'commit 55482edc25f0606851de42e73618f813f310d009
> ("qede: Add slowpath/fastpath support and enable hardware GRO")'
> introduces below error when compiling net-next with "make ARCH=x86_64"
>
> drivers/built-in.o: In function `qede_rx_int':
> qede_main.c:(.text+0x6101a0): undefined reference to `tcp_gro_complete'
>
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.
From: David Miller @ 2016-03-10 21:18 UTC (permalink / raw)
To: hau; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1457427065-3699-1-git-send-email-hau@realtek.com>
From: Chunhao Lin <hau@realtek.com>
Date: Tue, 8 Mar 2016 16:51:05 +0800
> For pcie nic, after setting link speed and thers is no link driver does not need
> to do phy reset untill link up.
"there's", "until"
> For some pcie nics, to do this will also reset phy speed down counter and prevent
> phy from auto speed down.
Please fix these typos and resubmit, thanks.
^ permalink raw reply
* Re: [net-next] arp: add macro to get drop_gratuitous_arp setting
From: David Miller @ 2016-03-10 21:17 UTC (permalink / raw)
To: zhangshengju; +Cc: netdev
In-Reply-To: <1457423630-12676-1-git-send-email-zhangshengju@cmss.chinamobile.com>
From: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
Date: Tue, 8 Mar 2016 07:53:50 +0000
> Add macro IN_DEV_DROP_GRATUITOUS_ARP to facilitate getting
> drop_gratuitous_arp value.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
As it's used in one location, I see zero value in this, sorry.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH net v2 0/2] qlcnic fixes
From: David Miller @ 2016-03-10 21:16 UTC (permalink / raw)
To: rajesh.borundia; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1457422798-17981-1-git-send-email-rajesh.borundia@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
Date: Tue, 8 Mar 2016 02:39:56 -0500
> This series adds following fixes.
>
> o While processing mailbox if driver gets a spurious mailbox
> interrupt it leads into premature completion of a next
> mailbox request. Added a guard against this by checking current
> state of mailbox and ignored spurious interrupt.
> Added a stats counter to record this condition.
>
> v2:
>
> o Added patch that removes usage of atomic_t as we are not implemeting
> atomicity by using atomic_t value.
>
> Please apply these fixes to net.
As explained in other list postings, 'net' is basically closed for this
release cycle, so I applied this series to 'net-next'.
Let me know if you'd like me to therefore queue these changes up for
-stable.
Thanks.
^ permalink raw reply
* Re: [PATCH] include/net/inet_connection_sock.h: Use pr_devel() instead of pr_debug()
From: David Miller @ 2016-03-10 21:14 UTC (permalink / raw)
To: nwang; +Cc: whs_alex, netdev, linux-kernel, nwang
In-Reply-To: <1457416348-32463-1-git-send-email-nwang@suse.com>
From: Nick Wang <nwang@suse.com>
Date: Tue, 8 Mar 2016 13:52:28 +0800
> File "inet_connection_sock.h" is a common share header that not can
> be use for one module, so use pr_devel instead of pr_debug is OK.
Not really, we only want these printks to do anything only when debug
printk's are enabled.
We don't want the overhead otherwise.
You'll need to find another fix for this, sorry.
^ permalink raw reply
* Re: [PATCH net-next 0/4] cxgb4vf: Interrupt and queue configuration changes
From: David Miller @ 2016-03-10 21:12 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1457414420-5237-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 8 Mar 2016 10:50:16 +0530
> This series fixes some issues and some changes in the queue and interrupt
> configuration for cxgb4vf driver. We need to enable interrupts before we
> register our network device, so that we don't loose link up interrupts.
> Allocate rx queues based on interrupt type. Set number of tx/rx queues in
> probe function only. Also adds check for some invalid configurations.
>
> This patch series has been created against net-next tree and includes
> patches on cxgb4vf 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] net: dsa: mv88e6xxx: avoid writing the same mode
From: David Miller @ 2016-03-10 21:11 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, andrew, kevin.smith
In-Reply-To: <1457393092-22826-1-git-send-email-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 7 Mar 2016 18:24:52 -0500
> There is no need to change the 802.1Q port mode for the same value.
> Thus avoid such message:
>
> [ 401.954836] dsa dsa@0 lan0: 802.1Q Mode: Disabled (was Disabled)
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: read then write PVID
From: David Miller @ 2016-03-10 21:11 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, andrew, kevin.smith
In-Reply-To: <1457393079-22740-1-git-send-email-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 7 Mar 2016 18:24:39 -0500
> The port register 0x07 contains more options than just the default VID,
> even though they are not used yet. So prefer a read then write operation
> over a direct write.
>
> This also allows to keep track of the change through dynamic debug.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: mv88e6xxx: rework port state setter
From: David Miller @ 2016-03-10 21:11 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, andrew, kevin.smith
In-Reply-To: <1457393057-22618-1-git-send-email-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 7 Mar 2016 18:24:17 -0500
> Apply a few non-functional changes on the port state setter:
>
> * add a dynamic debug message with state names to track changes
> * explicit states checking instead of assuming their numeric values
> * lock mutex only once when changing several port states
> * use bitmap macros to declare and access port_state_update_mask
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Applied.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cong Wang @ 2016-03-10 21:09 UTC (permalink / raw)
To: David Miller
Cc: Cyrill Gorcunov, Alexei Starovoitov, Eric Dumazet,
Linux Kernel Network Developers, solar, Vasily Averin, avagin,
xemul, vdavydov, khorenko, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <20160310.145543.990436948715023108.davem@davemloft.net>
On Thu, Mar 10, 2016 at 11:55 AM, David Miller <davem@davemloft.net> wrote:
> Indeed, good catch. Therefore:
>
> 1) Keep the masq netdev notifier. That will flush the conntrack table
> for the inetdev_destroy event.
>
> 2) Make the inetdev notifier only do something if inetdev->dead is
> false. (ie. we are flushing an individual address)
>
> And then we don't need the NETDEV_UNREGISTER thing at all:
This makes sense to me. I guess similar thing needs to do for IPv6 masq too.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/2] sh_eth: fix couple of bugs in sh_eth_ring_format()
From: David Miller @ 2016-03-10 21:07 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <4881302.XJJSmqvE1J@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 08 Mar 2016 01:33:38 +0300
> Here's a set of 2 patches against DaveM's 'net.git' repo fixing two bugs
> in sh_eth_.ring_format()...
>
> [1/2] sh_eth: fix NULL pointer dereference in sh_eth_ring_format()
> [2/2] sh_eth: advance 'rxdesc' later in sh_eth_ring_format()
Since Linus is likely to release today or otherwise very soon I'm not
putting things into 'net'.
So I've applied this series to 'net-next', let me know if I should
queue it up for stable.
Thanks.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-10 21:05 UTC (permalink / raw)
To: gorcunov
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310201351.GB1989@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Thu, 10 Mar 2016 23:13:51 +0300
> On Thu, Mar 10, 2016 at 03:03:11PM -0500, David Miller wrote:
>> From: Cyrill Gorcunov <gorcunov@gmail.com>
>> Date: Thu, 10 Mar 2016 23:01:34 +0300
>>
>> > On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
>> >> >
>> >> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
>> >> > is happening and masq already registers a netdev notifier...
>> >>
>> >> Indeed, good catch. Therefore:
>> >>
>> >> 1) Keep the masq netdev notifier. That will flush the conntrack table
>> >> for the inetdev_destroy event.
>> >>
>> >> 2) Make the inetdev notifier only do something if inetdev->dead is
>> >> false. (ie. we are flushing an individual address)
>> >>
>> >> And then we don't need the NETDEV_UNREGISTER thing at all:
>> >>
>> >> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> >> index c6eb421..f71841a 100644
>> >> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> >> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> >> @@ -108,10 +108,20 @@ static int masq_inet_event(struct notifier_block *this,
>> >> unsigned long event,
>> >> void *ptr)
>> >> {
>> >> - struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
>> >> struct netdev_notifier_info info;
>> >> + struct in_ifaddr *ifa = ptr;
>> >> + struct in_device *idev;
>> >>
>> >> - netdev_notifier_info_init(&info, dev);
>> >> + /* The masq_dev_notifier will catch the case of the device going
>> >> + * down. So if the inetdev is dead and being destroyed we have
>> >> + * no work to do. Otherwise this is an individual address removal
>> >> + * and we have to perform the flush.
>> >> + */
>> >> + idev = ifa->ifa_dev;
>> >> + if (idev->dead)
>> >> + return NOTIFY_DONE;
>> >> +
>> >> + netdev_notifier_info_init(&info, idev->dev);
>> >> return masq_device_event(this, event, &info);
>> >> }
>> >
>> > Guys, I'm lost. Currently masq_device_event calls for conntrack
>> > cleanup with device index, so that once device is going down, the
>> > appropriate conntracks gonna be dropped off. Now if device is dead
>> > nobody will cleanup the conntracks?
>>
>> Both notifiers are run in the inetdev_destroy() case.
>>
>> Maybe that's what you are missing.
>
> No :) Look, here is what I mean. Previously with your two patches
> we've been calling nf-cleanup for every address, so we had to make
> code call for cleanup for one time only. Now with the patch above
> the code flow is the following
>
> inetdev_destroy
> in_dev->dead = 1;
> ...
> inet_del_ifa
> ...
> blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
> ...
> masq_inet_event
> ...
> masq_device_event
> if (idev->dead)
> return NOTIFY_DONE;
>
> and nobody calls for nf_ct_iterate_cleanup, no?
Oh yes they do, from masq's non-inet notifier. masq registers two
notifiers, one for generic netdev and one for inetdev.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-10 20:19 UTC (permalink / raw)
To: David Miller, xiyou.wangcong
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310201351.GB1989@uranus.lan>
On Thu, Mar 10, 2016 at 11:13:51PM +0300, Cyrill Gorcunov wrote:
> >
> > Both notifiers are run in the inetdev_destroy() case.
> >
> > Maybe that's what you are missing.
>
> No :) Look, here is what I mean. Previously with your two patches
> we've been calling nf-cleanup for every address, so we had to make
> code call for cleanup for one time only. Now with the patch above
> the code flow is the following
Ah, I'm idiot, drop the question.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-10 20:13 UTC (permalink / raw)
To: David Miller
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310.150311.1210460824855467762.davem@davemloft.net>
On Thu, Mar 10, 2016 at 03:03:11PM -0500, David Miller wrote:
> From: Cyrill Gorcunov <gorcunov@gmail.com>
> Date: Thu, 10 Mar 2016 23:01:34 +0300
>
> > On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
> >> >
> >> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
> >> > is happening and masq already registers a netdev notifier...
> >>
> >> Indeed, good catch. Therefore:
> >>
> >> 1) Keep the masq netdev notifier. That will flush the conntrack table
> >> for the inetdev_destroy event.
> >>
> >> 2) Make the inetdev notifier only do something if inetdev->dead is
> >> false. (ie. we are flushing an individual address)
> >>
> >> And then we don't need the NETDEV_UNREGISTER thing at all:
> >>
> >> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> >> index c6eb421..f71841a 100644
> >> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> >> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> >> @@ -108,10 +108,20 @@ static int masq_inet_event(struct notifier_block *this,
> >> unsigned long event,
> >> void *ptr)
> >> {
> >> - struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
> >> struct netdev_notifier_info info;
> >> + struct in_ifaddr *ifa = ptr;
> >> + struct in_device *idev;
> >>
> >> - netdev_notifier_info_init(&info, dev);
> >> + /* The masq_dev_notifier will catch the case of the device going
> >> + * down. So if the inetdev is dead and being destroyed we have
> >> + * no work to do. Otherwise this is an individual address removal
> >> + * and we have to perform the flush.
> >> + */
> >> + idev = ifa->ifa_dev;
> >> + if (idev->dead)
> >> + return NOTIFY_DONE;
> >> +
> >> + netdev_notifier_info_init(&info, idev->dev);
> >> return masq_device_event(this, event, &info);
> >> }
> >
> > Guys, I'm lost. Currently masq_device_event calls for conntrack
> > cleanup with device index, so that once device is going down, the
> > appropriate conntracks gonna be dropped off. Now if device is dead
> > nobody will cleanup the conntracks?
>
> Both notifiers are run in the inetdev_destroy() case.
>
> Maybe that's what you are missing.
No :) Look, here is what I mean. Previously with your two patches
we've been calling nf-cleanup for every address, so we had to make
code call for cleanup for one time only. Now with the patch above
the code flow is the following
inetdev_destroy
in_dev->dead = 1;
...
inet_del_ifa
...
blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
...
masq_inet_event
...
masq_device_event
if (idev->dead)
return NOTIFY_DONE;
and nobody calls for nf_ct_iterate_cleanup, no?
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-10 20:03 UTC (permalink / raw)
To: gorcunov
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310200133.GA1989@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Thu, 10 Mar 2016 23:01:34 +0300
> On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
>> >
>> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
>> > is happening and masq already registers a netdev notifier...
>>
>> Indeed, good catch. Therefore:
>>
>> 1) Keep the masq netdev notifier. That will flush the conntrack table
>> for the inetdev_destroy event.
>>
>> 2) Make the inetdev notifier only do something if inetdev->dead is
>> false. (ie. we are flushing an individual address)
>>
>> And then we don't need the NETDEV_UNREGISTER thing at all:
>>
>> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> index c6eb421..f71841a 100644
>> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
>> @@ -108,10 +108,20 @@ static int masq_inet_event(struct notifier_block *this,
>> unsigned long event,
>> void *ptr)
>> {
>> - struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
>> struct netdev_notifier_info info;
>> + struct in_ifaddr *ifa = ptr;
>> + struct in_device *idev;
>>
>> - netdev_notifier_info_init(&info, dev);
>> + /* The masq_dev_notifier will catch the case of the device going
>> + * down. So if the inetdev is dead and being destroyed we have
>> + * no work to do. Otherwise this is an individual address removal
>> + * and we have to perform the flush.
>> + */
>> + idev = ifa->ifa_dev;
>> + if (idev->dead)
>> + return NOTIFY_DONE;
>> +
>> + netdev_notifier_info_init(&info, idev->dev);
>> return masq_device_event(this, event, &info);
>> }
>
> Guys, I'm lost. Currently masq_device_event calls for conntrack
> cleanup with device index, so that once device is going down, the
> appropriate conntracks gonna be dropped off. Now if device is dead
> nobody will cleanup the conntracks?
Both notifiers are run in the inetdev_destroy() case.
Maybe that's what you are missing.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-10 20:01 UTC (permalink / raw)
To: David Miller
Cc: xiyou.wangcong, alexei.starovoitov, eric.dumazet, netdev, solar,
vvs, avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310.145543.990436948715023108.davem@davemloft.net>
On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
> >
> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
> > is happening and masq already registers a netdev notifier...
>
> Indeed, good catch. Therefore:
>
> 1) Keep the masq netdev notifier. That will flush the conntrack table
> for the inetdev_destroy event.
>
> 2) Make the inetdev notifier only do something if inetdev->dead is
> false. (ie. we are flushing an individual address)
>
> And then we don't need the NETDEV_UNREGISTER thing at all:
>
> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> index c6eb421..f71841a 100644
> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> @@ -108,10 +108,20 @@ static int masq_inet_event(struct notifier_block *this,
> unsigned long event,
> void *ptr)
> {
> - struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
> struct netdev_notifier_info info;
> + struct in_ifaddr *ifa = ptr;
> + struct in_device *idev;
>
> - netdev_notifier_info_init(&info, dev);
> + /* The masq_dev_notifier will catch the case of the device going
> + * down. So if the inetdev is dead and being destroyed we have
> + * no work to do. Otherwise this is an individual address removal
> + * and we have to perform the flush.
> + */
> + idev = ifa->ifa_dev;
> + if (idev->dead)
> + return NOTIFY_DONE;
> +
> + netdev_notifier_info_init(&info, idev->dev);
> return masq_device_event(this, event, &info);
> }
Guys, I'm lost. Currently masq_device_event calls for conntrack
cleanup with device index, so that once device is going down, the
appropriate conntracks gonna be dropped off. Now if device is dead
nobody will cleanup the conntracks?
Cyrill
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-10 19:55 UTC (permalink / raw)
To: xiyou.wangcong
Cc: gorcunov, alexei.starovoitov, eric.dumazet, netdev, solar, vvs,
avagin, xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <CAM_iQpWWbj00H-cKvpeaKq6mVWK_D2CFuarXiE6YDQeQX5JupA@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 10 Mar 2016 11:02:28 -0800
> On Thu, Mar 10, 2016 at 10:01 AM, David Miller <davem@davemloft.net> wrote:
>> I'm tempted to say that we should provide these notifier handlers with
>> the information they need, explicitly, to handle this case.
>>
>> Most intdev notifiers actually want to know the individual addresses
>> that get removed, one by one. That's handled by the existing
>> NETDEV_DOWN event and the ifa we pass to that.
>>
>> But some, like this netfilter masq case, would be satisfied with a
>> single event that tells them the whole inetdev instance is being torn
>> down. Which is the case we care about here.
>>
>> We currently don't use NETDEV_UNREGISTER for inetdev notifiers, so
>> maybe we could use that.
>>
>> And that is consistent with the core netdev notifier that triggers
>> this call chain in the first place.
>>
>> Roughly, something like this:
>>
>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>> index 8c3df2c..6eee5cb 100644
>> --- a/net/ipv4/devinet.c
>> +++ b/net/ipv4/devinet.c
>> @@ -292,6 +292,11 @@ static void inetdev_destroy(struct in_device *in_dev)
>>
>> in_dev->dead = 1;
>>
>> + if (in_dev->ifa_list)
>> + blocking_notifier_call_chain(&inetaddr_chain,
>> + NETDEV_UNREGISTER,
>> + in_dev->ifa_list);
>> +
>> ip_mc_destroy_dev(in_dev);
>
>
> Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
> is happening and masq already registers a netdev notifier...
Indeed, good catch. Therefore:
1) Keep the masq netdev notifier. That will flush the conntrack table
for the inetdev_destroy event.
2) Make the inetdev notifier only do something if inetdev->dead is
false. (ie. we are flushing an individual address)
And then we don't need the NETDEV_UNREGISTER thing at all:
diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
index c6eb421..f71841a 100644
--- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
@@ -108,10 +108,20 @@ static int masq_inet_event(struct notifier_block *this,
unsigned long event,
void *ptr)
{
- struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
struct netdev_notifier_info info;
+ struct in_ifaddr *ifa = ptr;
+ struct in_device *idev;
- netdev_notifier_info_init(&info, dev);
+ /* The masq_dev_notifier will catch the case of the device going
+ * down. So if the inetdev is dead and being destroyed we have
+ * no work to do. Otherwise this is an individual address removal
+ * and we have to perform the flush.
+ */
+ idev = ifa->ifa_dev;
+ if (idev->dead)
+ return NOTIFY_DONE;
+
+ netdev_notifier_info_init(&info, idev->dev);
return masq_device_event(this, event, &info);
}
^ permalink raw reply related
* Re: [PATCH] kcm: mark helper functions inline
From: David Miller @ 2016-03-10 19:48 UTC (permalink / raw)
To: arnd; +Cc: tom, netdev, linux-kernel
In-Reply-To: <1457634674-3373509-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 10 Mar 2016 19:31:12 +0100
> The stub helper functions for the newly added kcm_proc_init/exit interfaces
> are defined as 'static' in a header file, which leads to build warnings for
> each file that includes them without calling them:
>
> include/net/kcm.h:183:12: error: 'kcm_proc_init' defined but not used [-Werror=unused-function]
> include/net/kcm.h:184:13: error: 'kcm_proc_exit' defined but not used [-Werror=unused-function]
>
> This marks the two functions as 'static inline' instead, which avoids the
> warnings and is obviously what was meant here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: cd6e111bf5be ("kcm: Add statistics and proc interfaces")
Applied, thanks Arnd.
^ permalink raw reply
* Re: [PATCH 1/2] net: thunderx: Set recevie buffer page usage count in bulk
From: David Miller @ 2016-03-10 19:48 UTC (permalink / raw)
To: sunil.kovvuri
Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham, robert.richter
In-Reply-To: <CA+sq2CeMQMnmGPUWoLrtPzGiJpvNTsR_WmQzQr5wFVC9b3LU-w@mail.gmail.com>
From: Sunil Kovvuri <sunil.kovvuri@gmail.com>
Date: Thu, 10 Mar 2016 23:57:48 +0530
> Difference between NIU driver and this patch is there it's
> calculate split count, increment page count and then divide page into
> buffers. Here it's divide page into buffers, have a counter which increments
> at every split and then at the end do a atomic increment of page->_count.
>
> Any issue with this approach ?
I guess not.
^ permalink raw reply
* Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
From: Murali Karicheri @ 2016-03-10 19:38 UTC (permalink / raw)
To: Florian Fainelli, johan, open list:TI NETCP ETHERNET DRIVER,
Kwok, WingMan
In-Reply-To: <56E1B75F.9070100@gmail.com>
On 03/10/2016 01:05 PM, Florian Fainelli wrote:
> On 10/03/16 08:48, Murali Karicheri wrote:
>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>>> On 03/03/16 14:18, Murali Karicheri wrote:
>>>> Hi,
>>>>
>>>> We are using Micrel Phy in one of our board and wondering if we can force the
>>>> Phy to disable flow control at start. I have a 1G ethernet switch connected
>>>> to Phy and the phy always enable flow control. I would like to configure the
>>>> phy not to flow control. Is that possible and if yes, what should I do in the
>>>> my Ethernet driver to tell the Phy not to enable flow control?
>>>
>>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>>> the switch is doing, along with the link partner advertising support for
>>> it. You would want to make sure that your PHY device interface (provided
>>> that you are using the PHY library) is not starting with Pause
>>> advertised, but it could be supported.
>>
>> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
>> by default FC supported. After negotiation, I see that Phylib provide the
>> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not
>> to advertise?
>>
>> I call following sequence in the Ethernet driver.
>>
>> of_phy_connect(x,y,hndlr,a,z);
>
> Here you should be able to change phydev->advertising and
> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
> bits and have phy_start() restart with that which should disable pause
> and asym_pause as seen by your adjust_link handler.
>
Ok. Good point. I will try this. Thanks for your suggestion.
Murali
>> phy_start()
>>
>> Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can
>> I tell the phy not to advertise initially?
--
Murali Karicheri
Linux Kernel, Keystone
^ 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