* Re: [PATCH] udp: fix possible seqlock deadlock
From: Eric Dumazet @ 2013-11-28 17:36 UTC (permalink / raw)
To: jongman.heo
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <1385659390.5352.20.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2013-11-28 at 09:23 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In commit c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
> another spot where IP_INC_STATS_BH() was improperly used.
>
> udp_sendmsg() is called from process context, not from softirq context.
>
> This was detected by lockdep seqlock support.
>
> Reported-by: jongman heo <jongman.heo@samsung.com>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
Scrap this, I'll send a v2 with a complete check.
^ permalink raw reply
* Re: [PATCH net] diag: fix netlink API attributes
From: Nicolas Dichtel @ 2013-11-28 17:37 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev
In-Reply-To: <20131128163816.GA32047@casper.infradead.org>
Le 28/11/2013 17:38, Thomas Graf a écrit :
> On 11/28/13 at 02:57pm, Nicolas Dichtel wrote:
>> The first netlink attribute (value 0) must always be defined as none/unspec.
>> This is correctly done in inet_diag.h, but other diag interfaces are broken.
>>
>> Libraries like libnl skip this kind of attributes, thus it's never reported to
>> the application.
>>
>> CC: Thomas Graf <tgraf@suug.ch>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> First of all, thanks for the notification Nicolas. I'll fix libnl to
> pass through these attributes.
Fine :)
Thank you!
>
> I think the fix you propose is no an option as it breaks backwards
> compatiblity with existing user space. We cannot change the value
> of existing attributes.
Yes, I was just wondering how to fix it.
It also breaks the patch you've proposed in this thread:
http://thread.gmane.org/gmane.linux.network/251478/focus=252764
Hence, aligning attributes on 64-bits is still unresolved :(
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] xen-netback: TX grant mapping instead of copy
From: Zoltan Kiss @ 2013-11-28 17:37 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1383821563.26213.168.camel@kazak.uk.xensource.com>
On 07/11/13 10:52, Ian Campbell wrote:
> On Fri, 2013-11-01 at 19:00 +0000, Zoltan Kiss wrote:
>> On 01/11/13 10:50, Ian Campbell wrote:
>>> Does this always avoid copying when bridging/openvswitching/forwarding
>>> (e.g. masquerading etc)? For both domU->domU and domU->physical NIC?
>> I've tested the domU->domU, domU->physical with bridge and openvswitch
>> usecase, and now I've created a new stat counter to see how often copy
>> happens (the callback's second parameter tells you whether the skb was
>> freed or copied). It doesn't do copy in all of these scenarios.
>> What do you mean by forwarding? The scenario when you use bridge and
>> iptables mangling with the packet, not just filtering?
>
> I mean using L3 routing rather L2 bridging. Which might involve
> NAT/MASQUERADE or might just be normal IP routing.
I still couldn't find time to try out this scenario, but I think in this
case packet goes through deliver_skb, which means it will get copied. So
performance would be a bit worse due to the extra map/unmap. And I'm
afraid we can't help that too much due to this:
https://lkml.org/lkml/2012/7/20/363
However I think using Dom0 as a router/firewall is already a suboptimal
solution, so maybe a small performance regression is acceptable?
Anyway, I will try this out, and see if it really copies everything, and
get some numbers as well.
>>> How does it deal with broadcast traffic?
Now I had time to check it: broadcast packets get copied only once, when
cloning happens. It will swap out the frags with local ones, so any
subsequent cloning will have a local SKB.
Zoli
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] xen-netback: TX grant mapping instead of copy
From: Ian Campbell @ 2013-11-28 17:43 UTC (permalink / raw)
To: Zoltan Kiss; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <52977F5C.7090703@citrix.com>
On Thu, 2013-11-28 at 17:37 +0000, Zoltan Kiss wrote:
> On 07/11/13 10:52, Ian Campbell wrote:
> > On Fri, 2013-11-01 at 19:00 +0000, Zoltan Kiss wrote:
> >> On 01/11/13 10:50, Ian Campbell wrote:
> >>> Does this always avoid copying when bridging/openvswitching/forwarding
> >>> (e.g. masquerading etc)? For both domU->domU and domU->physical NIC?
> >> I've tested the domU->domU, domU->physical with bridge and openvswitch
> >> usecase, and now I've created a new stat counter to see how often copy
> >> happens (the callback's second parameter tells you whether the skb was
> >> freed or copied). It doesn't do copy in all of these scenarios.
> >> What do you mean by forwarding? The scenario when you use bridge and
> >> iptables mangling with the packet, not just filtering?
> >
> > I mean using L3 routing rather L2 bridging. Which might involve
> > NAT/MASQUERADE or might just be normal IP routing.
> I still couldn't find time to try out this scenario, but I think in this
> case packet goes through deliver_skb, which means it will get copied. So
> performance would be a bit worse due to the extra map/unmap. And I'm
> afraid we can't help that too much due to this:
> https://lkml.org/lkml/2012/7/20/363
> However I think using Dom0 as a router/firewall is already a suboptimal
> solution, so maybe a small performance regression is acceptable?
Routing/firewalling domUs is as valid as bridging. There is nothing in
the slightest bit suboptimal about it.
If this use case regresses with this approach then I'm afraid that
either needs to be addressed or a different approach considered.
> Anyway, I will try this out, and see if it really copies everything, and
> get some numbers as well.
Thanks.
> >>> How does it deal with broadcast traffic?
> Now I had time to check it: broadcast packets get copied only once, when
> cloning happens. It will swap out the frags with local ones, so any
> subsequent cloning will have a local SKB.
That's good.
Ian.
^ permalink raw reply
* [PATCH v2] inet: fix possible seqlock deadlocks
From: Eric Dumazet @ 2013-11-28 17:51 UTC (permalink / raw)
To: jongman.heo
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Hannes Frederic Sowa
In-Reply-To: <1385659390.5352.20.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
In commit c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
another places where IP_INC_STATS_BH() were improperly used.
udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
process context, not from softirq context.
This was detected by lockdep seqlock support.
Reported-by: jongman heo <jongman.heo@samsung.com>
Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv4/ping.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/udp.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 840cf1b9e6ee..242e7f4ed6f4 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -772,7 +772,7 @@ int ping_v4_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
err = PTR_ERR(rt);
rt = NULL;
if (err == -ENETUNREACH)
- IP_INC_STATS_BH(net, IPSTATS_MIB_OUTNOROUTES);
+ IP_INC_STATS(net, IPSTATS_MIB_OUTNOROUTES);
goto out;
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 59a6f8b90cd9..067213924751 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -177,7 +177,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
if (err == -ENETUNREACH)
- IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
+ IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
return err;
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 44dfaa09b584..44e3884f9e4c 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -999,7 +999,7 @@ int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
err = PTR_ERR(rt);
rt = NULL;
if (err == -ENETUNREACH)
- IP_INC_STATS_BH(net, IPSTATS_MIB_OUTNOROUTES);
+ IP_INC_STATS(net, IPSTATS_MIB_OUTNOROUTES);
goto out;
}
^ permalink raw reply related
* Re: [PATCH v2] inet: fix possible seqlock deadlocks
From: Hannes Frederic Sowa @ 2013-11-28 18:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: jongman.heo, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1385661082.5352.34.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 28, 2013 at 09:51:22AM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> In commit c9e9042994d3 ("ipv4: fix possible seqlock deadlock") I left
> another places where IP_INC_STATS_BH() were improperly used.
>
> udp_sendmsg(), ping_v4_sendmsg() and tcp_v4_connect() are called from
> process context, not from softirq context.
>
> This was detected by lockdep seqlock support.
>
> Reported-by: jongman heo <jongman.heo@samsung.com>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
> Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Just got home after getting distracted with other things today and the work is
already done. Thanks, Eric! ;)
Exactly the spots I noticed this morning, so
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Should we do something about the naming? I find it rather dangerous because
they look like the _bh lock postfixes but act exactly in the opposite?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 3/5][v2] phylib: Add generic 10G driver
From: Florian Fainelli @ 2013-11-28 18:46 UTC (permalink / raw)
To: Shaohui Xie
Cc: 谢谢谢, David Miller, jg1.han@samsung.com,
mugunthanvnm, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Emilian Medve,
Madalin-Cristian Bucur
In-Reply-To: <ED492CCEAF882048BC2237DE806547C915177468@039-SN2MPN1-013.039d.mgd.msft.net>
Le jeudi 28 novembre 2013, 09:59:53 Shaohui Xie a écrit :
> Thank you for reviewing the patches!
> I thought I was suggested to use phy_drivers_register() and
> phy_drivers_unregister(), so I changed to use an array, seems I got you
> wrong. :)If using two separate genphy_driver instances as you mentioned
> above is OK, I’m OK to use them, the array size is a headache to me, and
> may need to iterate the array when we unbind the driver.
> If we go for the
> array, I'd like to use some constant for the array indices. Right now we
> only support a generic 10/100/1000 PHY and now a 10G phy, but one day we
> might support a generic 40G or 100G PHY so the array indices won't be as
> obvious as they are today.
> [S.H] if we go for the array, how about below codes:
>
> enum generic_phy {
>
> INTERFACE_1G,
>
> INTERFACE_10G,
>
> INTERFACE_SUPP,
>
> };
>
> static struct phy_driver genphy_driver[ INTERFACE_SUPP];
I would prefer to use something named: GENPHY_DRV_1G, GENPHY_DRV_10G,
GENPHY_DRV_MAX, but yes that's the idea.
>
> I’m OK with using array or two separate instances, anyone would be accepted
> is good to me:)
> > extern int mdio_bus_init(void);
> > extern void mdio_bus_exit(void);
> >
> >
> >
> > @@ -539,7 +540,7 @@ static int phy_attach_direct(struct net_device *dev,
> > struct phy_device *phydev,
>
> > return -ENODEV;
> >
> > }
> >
> >
> >
> > - d->driver = &genphy_driver.driver;
> > + d->driver = &genphy_driver[0].driver;
>
>
> This is where using a constant for an index would become useful.
> [S.H] Yes. Should be something like:
> d->driver = &genphy_driver[INTERFACE_1G].driver;
> right?
Yes exactly
>
>
> >
> >
> > err = d->driver->probe(d);
> > if (err >= 0)
> >
> > @@ -620,7 +621,7 @@ void phy_detach(struct phy_device *phydev)
> >
> > * was using the generic driver), we unbind the device
> > * from the generic driver so that there's a chance a
> > * real driver could be loaded */
> >
> > - if (phydev->dev.driver == &genphy_driver.driver)
> > + if (phydev->dev.driver == &genphy_driver[0].driver)
> >
> > device_release_driver(&phydev->dev);
> >
> > }
>
> [S.H] This may also need to changed as:
>
> for (i = 0; i < ARRAY_SIZE(genphy_driver); i++) {
>
> if (phydev->dev.driver == &genphy_driver[i].driver)
>
> device_release_driver(&phydev->dev);
>
> }
Yes, indeed.
>
>
> > EXPORT_SYMBOL(phy_detach);
> >
> > @@ -689,6 +690,12 @@ static int genphy_config_advert(struct phy_device
> > *phydev)
>
> > return changed;
> >
> > }
> >
> >
> >
> > +int gen10g_config_advert(struct phy_device *dev)
> > +{
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_advert);
> > +
> >
> > /**
> >
> > * genphy_setup_forced - configures/forces speed/duplex from @phydev
> > * @phydev: target phy_device struct
> >
> > @@ -742,6 +749,11 @@ int genphy_restart_aneg(struct phy_device *phydev)
> >
> > }
> > EXPORT_SYMBOL(genphy_restart_aneg);
> >
> >
> >
> > +int gen10g_restart_aneg(struct phy_device *phydev)
> > +{
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_restart_aneg);
> >
> >
> >
> > /**
> >
> > * genphy_config_aneg - restart auto-negotiation or write BMCR
> >
> > @@ -784,6 +796,12 @@ int genphy_config_aneg(struct phy_device *phydev)
> >
> > }
> > EXPORT_SYMBOL(genphy_config_aneg);
> >
> >
> >
> > +int gen10g_config_aneg(struct phy_device *phydev)
> > +{
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_config_aneg);
> > +
> >
> > /**
> >
> > * genphy_update_link - update link status in @phydev
> > * @phydev: target phy_device struct
> >
> > @@ -913,6 +931,34 @@ int genphy_read_status(struct phy_device *phydev)
> >
> > }
> > EXPORT_SYMBOL(genphy_read_status);
> >
> >
> >
> > +int gen10g_read_status(struct phy_device *phydev)
> > +{
> > + int devad, reg;
> > + u32 mmd_mask = phydev->c45_ids.devices_in_package;
> > +
> > + phydev->link = 1;
> > +
> > + /* For now just lie and say it's 10G all the time */
> > + phydev->speed = SPEED_10000;
> > + phydev->duplex = DUPLEX_FULL;
> > +
> > + for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask >> 1) {
> > + if (!(mmd_mask & 1))
> > + continue;
> > +
> > + /* Read twice because link state is latched and a
> > + * read moves the current state into the register
> > + */
> > + phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
> > + if (reg < 0 || !(reg & MDIO_STAT1_LSTATUS))
> > + phydev->link = 0;
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_read_status);
> > +
> >
> > static int genphy_config_init(struct phy_device *phydev)
> > {
> >
> > int val;
> >
> > @@ -959,6 +1005,16 @@ static int genphy_config_init(struct phy_device
> > *phydev)
>
> >
> >
> > return 0;
> >
> > }
> >
> > +
> > +static int gen10g_config_init(struct phy_device *phydev)
> > +{
> > + /* Temporarily just say we support everything */
> > + phydev->supported = SUPPORTED_10000baseT_Full;
> > + phydev->advertising = SUPPORTED_10000baseT_Full;
> > +
> > + return 0;
> > +}
> > +
> >
> > int genphy_suspend(struct phy_device *phydev)
> > {
> >
> > int value;
> >
> > @@ -974,6 +1030,12 @@ int genphy_suspend(struct phy_device *phydev)
> >
> > }
> > EXPORT_SYMBOL(genphy_suspend);
> >
> >
> >
> > +int gen10g_suspend(struct phy_device *phydev)
> > +{
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_suspend);
> > +
> >
> > int genphy_resume(struct phy_device *phydev)
> > {
> >
> > int value;
> >
> > @@ -989,6 +1051,12 @@ int genphy_resume(struct phy_device *phydev)
> >
> > }
> > EXPORT_SYMBOL(genphy_resume);
> >
> >
> >
> > +int gen10g_resume(struct phy_device *phydev)
> > +{
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(gen10g_resume);
> > +
> >
> > /**
> >
> > * phy_probe - probe and init a PHY device
> > * @dev: device to probe and init
> >
> > @@ -1116,7 +1184,8 @@ void phy_drivers_unregister(struct phy_driver *drv,
> > int n)
>
> > }
> > EXPORT_SYMBOL(phy_drivers_unregister);
> >
> >
> >
> > -static struct phy_driver genphy_driver = {
> > +static struct phy_driver genphy_driver[] = {
> > +{
> >
> > .phy_id = 0xffffffff,
> > .phy_id_mask = 0xffffffff,
> > .name = "Generic PHY",
> >
> > @@ -1127,7 +1196,18 @@ static struct phy_driver genphy_driver = {
> >
> > .suspend = genphy_suspend,
> > .resume = genphy_resume,
> > .driver = {.owner= THIS_MODULE, },
> >
> > -};
> > +}, {
> > + .phy_id = 0xffffffff,
> > + .phy_id_mask = 0xffffffff,
> > + .name = "Generic 10G PHY",
> > + .config_init = gen10g_config_init,
> > + .features = 0,
> > + .config_aneg = gen10g_config_aneg,
> > + .read_status = gen10g_read_status,
> > + .suspend = gen10g_suspend,
> > + .resume = gen10g_resume,
> > + .driver = {.owner = THIS_MODULE, },
> > +} };
> >
> >
> >
> > static int __init phy_init(void)
> > {
> >
> > @@ -1137,7 +1217,8 @@ static int __init phy_init(void)
> >
> > if (rc)
> >
> > return rc;
> >
> >
> >
> > - rc = phy_driver_register(&genphy_driver);
> > + rc = phy_drivers_register(genphy_driver,
> > + ARRAY_SIZE(genphy_driver));
> >
> > if (rc)
> >
> > mdio_bus_exit();
> >
> >
> >
> > @@ -1146,7 +1227,8 @@ static int __init phy_init(void)
> >
> >
> >
> > static void __exit phy_exit(void)
> > {
> >
> > - phy_driver_unregister(&genphy_driver);
> > + phy_drivers_unregister(genphy_driver,
> > + ARRAY_SIZE(genphy_driver));
> >
> > mdio_bus_exit();
> >
> > }
>
> [S.H] Using array could simplify the phy_init() and phy_exit(), this the
> advantage I see. But I may need to split the patch in two patches, one to
> change the genphy_driver to array, the second to add the generic 10g
> driver. Is it acceptable?
Yes, I am okay with two patches doing that.
Thanks!
--
Florian
^ permalink raw reply
* Re: [Patch v3] IPv6: Fixed support for blackhole and prohibit routes
From: Hannes Frederic Sowa @ 2013-11-28 18:49 UTC (permalink / raw)
To: Kamala R; +Cc: netdev, David Miller, linux-kernel
In-Reply-To: <1385629923-22920-1-git-send-email-kamala@aristanetwors.com>
On Thu, Nov 28, 2013 at 02:42:03PM +0530, Kamala R wrote:
> From: Kamala R <kamala@aristanetworks.com>
>
> The behaviour of blackhole and prohibit routes has been corrected by setting
> the input and output pointers of the dst variable appropriately. For
> blackhole routes, they are set to dst_discard and to ip6_pkt_discard and
> ip6_pkt_discard_out respectively for prohibit routes.
>
> Signed-off-by: Kamala R <kamala@aristanetworks.com>
Thanks for changing this once again!
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [Patch v2] IPv6: Fixed support for blackhole and prohibit routes
From: Hannes Frederic Sowa @ 2013-11-28 18:50 UTC (permalink / raw)
To: Kamala R; +Cc: netdev, David Miller, linux-kernel
In-Reply-To: <1385108488-32163-1-git-send-email-kamala@aristanetwors.com>
On Fri, Nov 22, 2013 at 01:51:28PM +0530, Kamala R wrote:
> From: Kamala R <kamala@aristanetworks.com>
>
> The behaviour of blackhole and prohibit routes has been corrected by setting
> the input and output function pointers of the dst variable appropriately. For
> blackhole routes, they are set to dst_discard and to ip6_pkt_prohibit and
> ip6_pkt_prohbit_out respectively for prohibit routes.
>
> Changes from v1: Logic is the same. Changes made for readability and so it
> looks pleasing.
David, fyi a third version of this patch has been posted.
^ permalink raw reply
* [PATCH] ipv6: ip6_pkt_prohibit(_out) should not depend on CONFIG_IPV6_MULTIPLE_TABLES
From: Hannes Frederic Sowa @ 2013-11-28 19:04 UTC (permalink / raw)
To: Kamala R; +Cc: netdev, David Miller, linux-kernel
In-Reply-To: <1385629923-22920-1-git-send-email-kamala@aristanetwors.com>
Since patch "IPv6: Fixed support for blackhole and prohibit routes" we
need ip6_pkt_prohibit(_out) available without CONFIG_IPV6_MULTIPLE_TABLES
defined.
Cc: Kamala R <kamala@aristanetworks.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/route.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 97125c4..ddb9d41 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -84,6 +84,8 @@ static int ip6_dst_gc(struct dst_ops *ops);
static int ip6_pkt_discard(struct sk_buff *skb);
static int ip6_pkt_discard_out(struct sk_buff *skb);
+static int ip6_pkt_prohibit(struct sk_buff *skb);
+static int ip6_pkt_prohibit_out(struct sk_buff *skb);
static void ip6_link_failure(struct sk_buff *skb);
static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
struct sk_buff *skb, u32 mtu);
@@ -234,9 +236,6 @@ static const struct rt6_info ip6_null_entry_template = {
#ifdef CONFIG_IPV6_MULTIPLE_TABLES
-static int ip6_pkt_prohibit(struct sk_buff *skb);
-static int ip6_pkt_prohibit_out(struct sk_buff *skb);
-
static const struct rt6_info ip6_prohibit_entry_template = {
.dst = {
.__refcnt = ATOMIC_INIT(1),
@@ -2147,8 +2146,6 @@ static int ip6_pkt_discard_out(struct sk_buff *skb)
return ip6_pkt_drop(skb, ICMPV6_NOROUTE, IPSTATS_MIB_OUTNOROUTES);
}
-#ifdef CONFIG_IPV6_MULTIPLE_TABLES
-
static int ip6_pkt_prohibit(struct sk_buff *skb)
{
return ip6_pkt_drop(skb, ICMPV6_ADM_PROHIBITED, IPSTATS_MIB_INNOROUTES);
@@ -2160,8 +2157,6 @@ static int ip6_pkt_prohibit_out(struct sk_buff *skb)
return ip6_pkt_drop(skb, ICMPV6_ADM_PROHIBITED, IPSTATS_MIB_OUTNOROUTES);
}
-#endif
-
/*
* Allocate a dst for local (unicast / anycast) address.
*/
--
1.8.3.1
^ permalink raw reply related
* [PATCH] inet: further fixes of possible seqlock deadlocks
From: Hannes Frederic Sowa @ 2013-11-28 19:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: jongman.heo, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1385661082.5352.34.camel@edumazet-glaptop2.roam.corp.google.com>
This fixes more incorrect uses of *_STATS_BH in process context.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv4/udp.c | 8 ++++----
net/ipv6/ip6_output.c | 8 ++++----
net/ipv6/ping.c | 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 44e3884..f5cc018 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1160,10 +1160,10 @@ static unsigned int first_packet_length(struct sock *sk)
spin_lock_bh(&rcvq->lock);
while ((skb = skb_peek(rcvq)) != NULL &&
udp_lib_checksum_complete(skb)) {
- UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_CSUMERRORS,
- IS_UDPLITE(sk));
- UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS,
- IS_UDPLITE(sk));
+ UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_CSUMERRORS,
+ IS_UDPLITE(sk));
+ UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS,
+ IS_UDPLITE(sk));
atomic_inc(&sk->sk_drops);
__skb_unlink(skb, rcvq);
__skb_queue_tail(&list_kill, skb);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 59df872..e05cf0a 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -116,8 +116,8 @@ static int ip6_finish_output2(struct sk_buff *skb)
}
rcu_read_unlock_bh();
- IP6_INC_STATS_BH(dev_net(dst->dev),
- ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
+ IP6_INC_STATS(dev_net(dst->dev),
+ ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
kfree_skb(skb);
return -EINVAL;
}
@@ -1524,8 +1524,8 @@ int ip6_push_pending_frames(struct sock *sk)
if (proto == IPPROTO_ICMPV6) {
struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
- ICMP6MSGOUT_INC_STATS_BH(net, idev, icmp6_hdr(skb)->icmp6_type);
- ICMP6_INC_STATS_BH(net, idev, ICMP6_MIB_OUTMSGS);
+ ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type);
+ ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
}
err = ip6_local_out(skb);
diff --git a/net/ipv6/ping.c b/net/ipv6/ping.c
index a83243c..3a1f1f3 100644
--- a/net/ipv6/ping.c
+++ b/net/ipv6/ping.c
@@ -182,8 +182,8 @@ int ping_v6_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
MSG_DONTWAIT, np->dontfrag);
if (err) {
- ICMP6_INC_STATS_BH(sock_net(sk), rt->rt6i_idev,
- ICMP6_MIB_OUTERRORS);
+ ICMP6_INC_STATS(sock_net(sk), rt->rt6i_idev,
+ ICMP6_MIB_OUTERRORS);
ip6_flush_pending_frames(sk);
} else {
err = icmpv6_push_pending_frames(sk, &fl6,
--
1.8.3.1
^ permalink raw reply related
* Re: [ovs-dev] [PATCH openvswitch] netlink: Implement & enable memory mapped netlink i/o
From: Ben Pfaff @ 2013-11-28 19:24 UTC (permalink / raw)
To: Thomas Graf; +Cc: jesse, dev, fleitner, netdev
In-Reply-To: <52967768.8090308@redhat.com>
On Wed, Nov 27, 2013 at 11:51:20PM +0100, Thomas Graf wrote:
> On 11/26/2013 12:02 AM, Ben Pfaff wrote:
> >On Thu, Nov 21, 2013 at 07:16:54PM +0100, Thomas Graf wrote:
> >>Based on the initial patch by Cong Wang posted a couple of months
> >>ago.
> >>
> >>This is the user space counterpart needed for the kernel patch
> >>'[PATCH net-next 3/8] openvswitch: Enable memory mapped Netlink i/o'
> >>
> >>Allows the kernel to construct Netlink messages on memory mapped
> >>buffers and thus avoids copying. The functionality is enabled on
> >>sockets used for unicast traffic.
> >>
> >>Further optimizations are possible by avoiding the copy into the
> >>ofpbuf after reading.
> >>
> >>Cc: Cong Wang <xiyou.wangcong@gmail.com>
> >>Signed-off-by: Thomas Graf <tgraf@redhat.com>
> >
> >Does this depend on other patches or some specific Linux kernel
> >headers? It doesn't build here on GCC (similar results with Clang):
>
> Yes, it depends on a sufficiently recent <linux/netlink.h>. We can
> either #ifdef the mmap code or we provide a local copy of
> <linux/netlink.h> in include/linux. The code automatically falls back if
> the kernel does not support NL MMAP so that seems superior.
Can you add the new definitions to the end of lib/netlink-protocol.h,
conditional on their being needed? We already have a number of
compatibility definitions there.
^ permalink raw reply
* Re: [PATCH 1/8] atm: eni: use DEFINE_PCI_DEVICE_TABLE macro
From: David Miller @ 2013-11-28 20:48 UTC (permalink / raw)
To: jg1.han; +Cc: chas, netdev, linux-atm-general, romieu
In-Reply-To: <005701ceebf3$dc4ae840$94e0b8c0$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 28 Nov 2013 13:39:44 +0900
> On Thursday, November 28, 2013 12:37 PM, Jingoo Han wrote:
>>
>> This macro is used to create a struct pci_device_id array.
>>
>> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
>
> Please, ignore these patches.
> According to the Greg Kroah-Hartman,
...
Ok, but it was also not appropriate to submit these patches because the
net-next tree is not open yet.
Thank you.
^ permalink raw reply
* Re: [PATCH] inet: further fixes of possible seqlock deadlocks
From: Eric Dumazet @ 2013-11-28 21:01 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: jongman.heo, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20131128192231.GE24171@order.stressinduktion.org>
On Thu, 2013-11-28 at 20:22 +0100, Hannes Frederic Sowa wrote:
> This fixes more incorrect uses of *_STATS_BH in process context.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> net/ipv4/udp.c | 8 ++++----
> net/ipv6/ip6_output.c | 8 ++++----
> net/ipv6/ping.c | 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 44e3884..f5cc018 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1160,10 +1160,10 @@ static unsigned int first_packet_length(struct sock *sk)
> spin_lock_bh(&rcvq->lock);
Here we block BH, because of spin_lock_bh()
> while ((skb = skb_peek(rcvq)) != NULL &&
> udp_lib_checksum_complete(skb)) {
> - UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_CSUMERRORS,
> - IS_UDPLITE(sk));
> - UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS,
> - IS_UDPLITE(sk));
So this is the right thing, this change is not needed.
> + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_CSUMERRORS,
> + IS_UDPLITE(sk));
> + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS,
> + IS_UDPLITE(sk));
> atomic_inc(&sk->sk_drops);
> __skb_unlink(skb, rcvq);
> __skb_queue_tail(&list_kill, skb);
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 59df872..e05cf0a 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/j
> @@ -116,8 +116,8 @@ static int ip6_finish_output2(struct sk_buff *skb)
> }
> rcu_read_unlock_bh();
>
> - IP6_INC_STATS_BH(dev_net(dst->dev),
> - ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
> + IP6_INC_STATS(dev_net(dst->dev),
> + ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
This is ipv6, not inet changes ;)
> kfree_skb(skb);
> return -EINVAL;
> }
> @@ -1524,8 +1524,8 @@ int ip6_push_pending_frames(struct sock *sk)
> if (proto == IPPROTO_ICMPV6) {
> struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
>
> - ICMP6MSGOUT_INC_STATS_BH(net, idev, icmp6_hdr(skb)->icmp6_type);
> - ICMP6_INC_STATS_BH(net, idev, ICMP6_MIB_OUTMSGS);
> + ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type);
> + ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
I am not sure we use a seqlock for ICMP stats.
seqlocks were used for 64bit IP stats
^ permalink raw reply
* Re: [PATCH] inet: further fixes of possible seqlock deadlocks
From: Hannes Frederic Sowa @ 2013-11-28 21:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: jongman.heo, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1385672502.5352.38.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 28, 2013 at 01:01:42PM -0800, Eric Dumazet wrote:
> On Thu, 2013-11-28 at 20:22 +0100, Hannes Frederic Sowa wrote:
> > This fixes more incorrect uses of *_STATS_BH in process context.
> >
> > Cc: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > ---
> > net/ipv4/udp.c | 8 ++++----
> > net/ipv6/ip6_output.c | 8 ++++----
> > net/ipv6/ping.c | 4 ++--
> > 3 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> > index 44e3884..f5cc018 100644
> > --- a/net/ipv4/udp.c
> > +++ b/net/ipv4/udp.c
> > @@ -1160,10 +1160,10 @@ static unsigned int first_packet_length(struct sock *sk)
> > spin_lock_bh(&rcvq->lock);
>
> Here we block BH, because of spin_lock_bh()
>
> > while ((skb = skb_peek(rcvq)) != NULL &&
> > udp_lib_checksum_complete(skb)) {
> > - UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_CSUMERRORS,
> > - IS_UDPLITE(sk));
> > - UDP_INC_STATS_BH(sock_net(sk), UDP_MIB_INERRORS,
> > - IS_UDPLITE(sk));
>
> So this is the right thing, this change is not needed.
Oh yes, I was mechanically going through the a grep of _BH\( in ipv4
and ipv6 and missed that.
> > + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_CSUMERRORS,
> > + IS_UDPLITE(sk));
> > + UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS,
> > + IS_UDPLITE(sk));
> > atomic_inc(&sk->sk_drops);
> > __skb_unlink(skb, rcvq);
> > __skb_queue_tail(&list_kill, skb);
> > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> > index 59df872..e05cf0a 100644
> > --- a/net/ipv6/ip6_output.c
> > +++ b/j
> > @@ -116,8 +116,8 @@ static int ip6_finish_output2(struct sk_buff *skb)
> > }
> > rcu_read_unlock_bh();
> >
> > - IP6_INC_STATS_BH(dev_net(dst->dev),
> > - ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
> > + IP6_INC_STATS(dev_net(dst->dev),
> > + ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
>
> This is ipv6, not inet changes ;)
I always considered inet both for ipv4+ipv6, otherwise I would use ipv4
or ipv6 as patch prefix.
>
> > kfree_skb(skb);
> > return -EINVAL;
> > }
> > @@ -1524,8 +1524,8 @@ int ip6_push_pending_frames(struct sock *sk)
> > if (proto == IPPROTO_ICMPV6) {
> > struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
> >
> > - ICMP6MSGOUT_INC_STATS_BH(net, idev, icmp6_hdr(skb)->icmp6_type);
> > - ICMP6_INC_STATS_BH(net, idev, ICMP6_MIB_OUTMSGS);
> > + ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type);
> > + ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
>
> I am not sure we use a seqlock for ICMP stats.
>
> seqlocks were used for 64bit IP stats
True, atomic longs get used here in both cases.
Will update the patch. Thanks, Eric!
^ permalink raw reply
* Re: [RFC PATCH v2] diag: warn about missing first netlink attribute
From: David Miller @ 2013-11-28 21:36 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: tgraf, netdev
In-Reply-To: <1385659865-1926-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 28 Nov 2013 18:31:05 +0100
> The first netlink attribute (value 0) must always be defined as none/unspec.
> This is correctly done in inet_diag.h, but other diag interfaces are wrong.
>
> Because we cannot change an existing API, I add a comment to point the mistake
> and avoid to propagate it in a new diag API in the future.
>
> CC: Thomas Graf <tgraf@suug.ch>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> v2: just warn about the missing attribute
>
> If patch is approved, I will submit it when the net-next tree opens.
Indeed we can't change it, and documenting it like this is also a good
idea.
I hope Thomas agrees.
^ permalink raw reply
* Re: [RFC PATCH v2] diag: warn about missing first netlink attribute
From: Thomas Graf @ 2013-11-28 22:09 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <1385659865-1926-1-git-send-email-nicolas.dichtel@6wind.com>
On 11/28/13 at 06:31pm, Nicolas Dichtel wrote:
> The first netlink attribute (value 0) must always be defined as none/unspec.
> This is correctly done in inet_diag.h, but other diag interfaces are wrong.
>
> Because we cannot change an existing API, I add a comment to point the mistake
> and avoid to propagate it in a new diag API in the future.
>
> CC: Thomas Graf <tgraf@suug.ch>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> v2: just warn about the missing attribute
>
> If patch is approved, I will submit it when the net-next tree opens.
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [PATCH net] diag: fix netlink API attributes
From: Thomas Graf @ 2013-11-28 22:19 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev
In-Reply-To: <52977F44.6070002@6wind.com>
On 11/28/13 at 06:37pm, Nicolas Dichtel wrote:
> Le 28/11/2013 17:38, Thomas Graf a écrit :
> >On 11/28/13 at 02:57pm, Nicolas Dichtel wrote:
> >>The first netlink attribute (value 0) must always be defined as none/unspec.
> >>This is correctly done in inet_diag.h, but other diag interfaces are broken.
> >>
> >>Libraries like libnl skip this kind of attributes, thus it's never reported to
> >>the application.
> >>
> >>CC: Thomas Graf <tgraf@suug.ch>
> >>Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> >
> >First of all, thanks for the notification Nicolas. I'll fix libnl to
> >pass through these attributes.
> Fine :)
> Thank you!
Fixed in:
commit 6a8d90f5fec48b6e376ff29ccf3e0c620a41e758
Author: Thomas Graf <tgraf@suug.ch>
Date: Thu Nov 28 23:14:38 2013 +0100
attr: Allow attribute type 0
{netlink,packet,unix}_diag use attribute type 0 for valid
attributes. The value was reserved and usage was prohibited
by the protocol but we can't undo the breakge.
Make libnl accept attribute type 0 to allow parsing these
attributes.
Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
> >I think the fix you propose is no an option as it breaks backwards
> >compatiblity with existing user space. We cannot change the value
> >of existing attributes.
> Yes, I was just wondering how to fix it.
> It also breaks the patch you've proposed in this thread:
> http://thread.gmane.org/gmane.linux.network/251478/focus=252764
>
> Hence, aligning attributes on 64-bits is still unresolved :(
Unfortunately I ran into other places where an attribute type 0
was used. Therefore the idea of using NLA_UNSPEC (0) to insert
padding attributes doesn't work. We would need to find another
way to insert padding. I'll be glad to share the WIP patch if
somebody else would like to continue the work.
^ permalink raw reply
* Re: [PATCH] inet: further fixes of possible seqlock deadlocks
From: Hannes Frederic Sowa @ 2013-11-28 22:19 UTC (permalink / raw)
To: Eric Dumazet, jongman.heo, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20131128212700.GF24171@order.stressinduktion.org>
On Thu, Nov 28, 2013 at 10:27:00PM +0100, Hannes Frederic Sowa wrote:
> > > @@ -1524,8 +1524,8 @@ int ip6_push_pending_frames(struct sock *sk)
> > > if (proto == IPPROTO_ICMPV6) {
> > > struct inet6_dev *idev = ip6_dst_idev(skb_dst(skb));
> > >
> > > - ICMP6MSGOUT_INC_STATS_BH(net, idev, icmp6_hdr(skb)->icmp6_type);
> > > - ICMP6_INC_STATS_BH(net, idev, ICMP6_MIB_OUTMSGS);
> > > + ICMP6MSGOUT_INC_STATS(net, idev, icmp6_hdr(skb)->icmp6_type);
> > > + ICMP6_INC_STATS(net, idev, ICMP6_MIB_OUTMSGS);
> >
> > I am not sure we use a seqlock for ICMP stats.
> >
> > seqlocks were used for 64bit IP stats
>
> True, atomic longs get used here in both cases.
I don't really understand why we distinguish between _BH and plain ICMP stat
calls then.
The non-_BH versions deactivate interrupts when updating the per-cpu counter.
^ permalink raw reply
* Re: [PATCH openvswitch] netlink: Implement & enable memory mapped netlink i/o
From: Thomas Graf @ 2013-11-28 22:31 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
fleitner-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <20131128192449.GA28279-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On 11/28/2013 08:24 PM, Ben Pfaff wrote:
> On Wed, Nov 27, 2013 at 11:51:20PM +0100, Thomas Graf wrote:
>> On 11/26/2013 12:02 AM, Ben Pfaff wrote:
>>> On Thu, Nov 21, 2013 at 07:16:54PM +0100, Thomas Graf wrote:
>>>> Based on the initial patch by Cong Wang posted a couple of months
>>>> ago.
>>>>
>>>> This is the user space counterpart needed for the kernel patch
>>>> '[PATCH net-next 3/8] openvswitch: Enable memory mapped Netlink i/o'
>>>>
>>>> Allows the kernel to construct Netlink messages on memory mapped
>>>> buffers and thus avoids copying. The functionality is enabled on
>>>> sockets used for unicast traffic.
>>>>
>>>> Further optimizations are possible by avoiding the copy into the
>>>> ofpbuf after reading.
>>>>
>>>> Cc: Cong Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Signed-off-by: Thomas Graf <tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Does this depend on other patches or some specific Linux kernel
>>> headers? It doesn't build here on GCC (similar results with Clang):
>>
>> Yes, it depends on a sufficiently recent <linux/netlink.h>. We can
>> either #ifdef the mmap code or we provide a local copy of
>> <linux/netlink.h> in include/linux. The code automatically falls back if
>> the kernel does not support NL MMAP so that seems superior.
>
> Can you add the new definitions to the end of lib/netlink-protocol.h,
> conditional on their being needed? We already have a number of
> compatibility definitions there.
Sure. I'll move the definitions out of !HAVE_NETLINK and into
appropriate conditionals.
^ permalink raw reply
* Re: [PATCH 1/5] net: sfc: remove unnecessary pci_set_drvdata()
From: David Miller @ 2013-11-28 23:11 UTC (permalink / raw)
To: jg1.han; +Cc: netdev, linux-net-drivers, bhutchings
In-Reply-To: <000101cee97f$b2271ff0$16755fd0$%han@samsung.com>
Can you please resubmit these pci_set_drvdata() patches (the IRDA,
WAN, hippi, fiddi ones too) when I open the net-next tree back up?
Thank you.
^ permalink raw reply
* Re: [PATCH] inet: further fixes of possible seqlock deadlocks
From: David Miller @ 2013-11-28 23:15 UTC (permalink / raw)
To: hannes; +Cc: eric.dumazet, jongman.heo, netdev, linux-kernel
In-Reply-To: <20131128221926.GG24171@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 28 Nov 2013 23:19:26 +0100
> I don't really understand why we distinguish between _BH and plain ICMP stat
> calls then.
>
> The non-_BH versions deactivate interrupts when updating the per-cpu counter.
This level of distinction exists back in the day where we did per-cpu counters
by hand. We used to have a BH counter and a non-BH counter for each statistic
and it really helped performance wise.
These days most of that may not be so relevant any more.
^ permalink raw reply
* Re: [RFC PATCH v2] diag: warn about missing first netlink attribute
From: David Miller @ 2013-11-28 23:16 UTC (permalink / raw)
To: tgraf; +Cc: nicolas.dichtel, netdev
In-Reply-To: <20131128220909.GA4100@casper.infradead.org>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 28 Nov 2013 22:09:09 +0000
> On 11/28/13 at 06:31pm, Nicolas Dichtel wrote:
>> The first netlink attribute (value 0) must always be defined as none/unspec.
>> This is correctly done in inet_diag.h, but other diag interfaces are wrong.
>>
>> Because we cannot change an existing API, I add a comment to point the mistake
>> and avoid to propagate it in a new diag API in the future.
>>
>> CC: Thomas Graf <tgraf@suug.ch>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>>
>> v2: just warn about the missing attribute
>>
>> If patch is approved, I will submit it when the net-next tree opens.
>
> Acked-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] netem: fix loss generators
From: David Miller @ 2013-11-28 23:18 UTC (permalink / raw)
To: stephen; +Cc: stefano.salsano, netdev
In-Reply-To: <20131121175419.59059598@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 21 Nov 2013 17:54:19 -0800
> Patch from developers of the alternative loss models, downloaded from:
> http://netgroup.uniroma2.it/twiki/bin/view.cgi/Main/NetemCLG
>
> We found some bugs in our first implementation.
> A first set of bugs is in the function loss_4state:
> In the case 1 of the switch statement in the if conditions we
> need to add clg->a4 to clg->a1, according to the model.
> In the case 3 of the switch statement we need to delete "return
> true" if the condition leads us in the state 1, because the state 1 is
> a good state.
>
> A second set of bugs is in the function loss_gilb_ell
> In both cases of the switch statement we need to add the break
> statement, because the two cases are mutually exclusive.
> In the case 2, of the switch we change the direction of the inequality to
> net_random()>clg->a3, because clg->a3 is h in the GE model and when h
> is 0 all packets will be lost.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Stephen, can you adjust this patch to take into account commit:
4a3ad7b3eade08ad1c760aaa4fe06a36f2584939
as Hagen noted?
Thank you.
^ permalink raw reply
* Re: [PATCH net v3] bonding: disable arp and enable mii monitoring when bond change to no uses arp mode
From: David Miller @ 2013-11-28 23:20 UTC (permalink / raw)
To: dingtianhong; +Cc: andy, dcbw, fubar, nikolay, vfalico, netdev
In-Reply-To: <528F6A1B.70904@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Fri, 22 Nov 2013 22:28:43 +0800
> Because the ARP monitoring is not support for 802.3ad, but I still
> could change the mode to 802.3ad from ab mode while ARP monitoring
> is running, it is incorrect.
>
> So add a check for 802.3ad in bonding_store_mode to fix the problem,
> and make a new macro BOND_NO_USES_ARP() to simplify the code.
>
> v2: according to the Dan Williams's suggestion, bond mode is the most
> important bond option, it should override any of the other sub-options.
> So when the mode is changed, the conficting values should be cleared
> or reset, otherwise the user has to duplicate more operations to modify
> the logic. I disable the arp and enable mii monitoring when the bond mode
> is changed to AB, TB and 8023AD if the arp interval is true.
>
> v3: according to the Nik's suggestion, the default value of miimon should need
> a name, there is several place to use it, and the bond_store_arp_interval()
> could use micro BOND_NO_USES_ARP to make the code more simpify.
>
> Suggested-by: Dan Williams <dcbw@redhat.com>
> Suggested-by: Nikolay Aleksandrov <nikolay@redhat.com>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Applied, thanks for following up on this Ding.
^ 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