* Re: IP fragmentation broken in 3.6-rc ?
From: Julian Anastasov @ 2012-08-21 17:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sylvain Munaut, netdev
In-Reply-To: <1345567633.5158.534.camel@edumazet-glaptop>
Hello,
On Tue, 21 Aug 2012, Eric Dumazet wrote:
> On Tue, 2012-08-21 at 19:34 +0300, Julian Anastasov wrote:
> > Hello,
> >
> > On Tue, 21 Aug 2012, Eric Dumazet wrote:
> >
> > > Following patch should help :
> > >
> > > diff --git a/include/net/dst.h b/include/net/dst.h
> > > index 621e351..a04aa37 100644
> > > --- a/include/net/dst.h
> > > +++ b/include/net/dst.h
> > > @@ -435,7 +435,7 @@ static inline void dst_set_expires(struct dst_entry *dst, int timeout)
> > > if (expires == 0)
> > > expires = 1;
> > >
> >
> > In theory, restart of PMTUD should not lead to
> > fatal problems, we will get new MTUs. But with such
> > change should be better, not much, because all MTU
> > events will come at same time, later timer will expire
> > and we will get again events from routers. The gain
> > will be an increased period (with milliseconds to seconds)
> > between PMTUD restarts. Compared to the 600-second timer,
> > this should be gain below 1% in reduced traffic for PMTUD.
> > Before now we started timer from first router, now we
> > will start/update timer period after event from last router.
> >
>
> Sorry I dont really understand what you mean
This timer is used only for PMTU, right?
RFC 1191 6.3. Purging stale PMTU information.
> > But ipv4_link_failure and ip6_link_failure want to stop
> > this timer by setting it to NOW (0). May be we have to add
> > also a !timeout check here or to leave the code as before?
> >
> > > - if (dst->expires == 0 || time_before(expires, dst->expires))
> > > + if (dst->expires == 0 || time_after(expires, dst->expires))
> > > dst->expires = expires;
> > > }
> >
> > The original problem should be somewhere else, I think.
>
> This patch fixed the problem for me.
OK, then I'll wait for the patch description
to understand what this change actually does. For me,
it just updates the timer on every MTU event, while
before the change, PMTU timer was started only once and
during the 600-second period it was not updated and also
there was the ability to invalidate the PMTU on link failure
by setting timer to jiffies, i.e. to stop this period
and to start new one with default MTU and possibly
new discovery procedure.
> My first patch was :
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index e4ba974..9858714 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -956,6 +956,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
> dst->obsolete = DST_OBSOLETE_KILL;
> } else {
> rt->rt_pmtu = mtu;
> + rt->dst.expires = 0;
> dst_set_expires(&rt->dst, ip_rt_mtu_expires);
This is better, does not break ipv4_link_failure.
There is a little race some ipv4_mtu() user to see
rt_pmtu != 0 and dst.expires = 0 and to fail in time_after_eq
test. May be that is why dst.expires is never set to 0.
But I still don't understand what both changes fix.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [PATCH] ethtool: don't overwrite useful bits in advertising bitfield
From: Ben Hutchings @ 2012-08-21 17:03 UTC (permalink / raw)
To: Johan Gunnarsson; +Cc: netdev@vger.kernel.org, Mikael Starvik
In-Reply-To: <A612847CFE53224C91B23E3A5B48BAC7534E8D7809@xmail3.se.axis.com>
On Tue, 2012-08-21 at 18:45 +0200, Johan Gunnarsson wrote:
[...]
> > > > > @@ -2405,19 +2421,20 @@ static int do_sset(struct cmd_context
> > *ctx)
> > > > > }
> > > > > if (autoneg_wanted == AUTONEG_ENABLE &&
> > > > > advertising_wanted == 0) {
> > > > > - ecmd.advertising = ecmd.supported &
> > > > > - (ADVERTISED_10baseT_Half |
> > > > > - ADVERTISED_10baseT_Full |
> > > > > - ADVERTISED_100baseT_Half |
> > > > > - ADVERTISED_100baseT_Full |
> > > > > - ADVERTISED_1000baseT_Half |
> > > > > - ADVERTISED_1000baseT_Full |
> > > > > - ADVERTISED_2500baseX_Full |
> > > > > - ADVERTISED_10000baseT_Full |
> > > > > - ADVERTISED_20000baseMLD2_Full |
> > > > > - ADVERTISED_20000baseKR2_Full);
> > > > > + /* Auto negotation enabled, but with
> > > > > + * unspecified speed and duplex: enable
> > all
> > > > > + * supported speeds and duplexes.
> > > > > + */
> > > > > + ecmd.advertising = (ecmd.advertising &
> > > > > + ~ALL_ADVERTISED_MODES) |
> > > > > + (ALL_ADVERTISED_MODES &
> > ecmd.supported);
> > > >
> > > > Perhaps we should also warn if there's a 'supported' flag we don't
> > > > recognise, because we don't know whether it's a link mode and we
> > might
> > > > be failing to enable/disable it as requested.
> > >
> > > You mean if ecmd.supported has bits enabled that ALL_ADVERTISED_MODES
> > > hasn't? I don't think that's a good idea, because that happens very
> > > often (for example PAUSE bits in my case.)
> >
> > No, I mean if it has bits enabled that are not defined at all
> > (currently
> > any of bits 27-31).
>
> Not totally sure I follow. Care to show me?
[...]
<linux/ethtool.h> or ethtool-copy.h currently defines the meanings of
bits 0-26 in the supported field. You define ALL_ADVERTISED_MODES to
include all of those that are link modes. But some time in the future,
the remaining bits will be assigned to new capabilities.
If today's ethtool is used with a newer driver that sets bit 27 in its
supported field, ethtool can't tell whether that represents a new link
mode that should be included in ALL_ADVERTISED_MODES, or some other kind
of capability. So it may not be able to set the driver's advertising
mask correctly.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: IP fragmentation broken in 3.6-rc ?
From: Eric Dumazet @ 2012-08-21 16:47 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Sylvain Munaut, netdev
In-Reply-To: <alpine.LFD.2.00.1208211815550.2149@ja.ssi.bg>
On Tue, 2012-08-21 at 19:34 +0300, Julian Anastasov wrote:
> Hello,
>
> On Tue, 21 Aug 2012, Eric Dumazet wrote:
>
> > Following patch should help :
> >
> > diff --git a/include/net/dst.h b/include/net/dst.h
> > index 621e351..a04aa37 100644
> > --- a/include/net/dst.h
> > +++ b/include/net/dst.h
> > @@ -435,7 +435,7 @@ static inline void dst_set_expires(struct dst_entry *dst, int timeout)
> > if (expires == 0)
> > expires = 1;
> >
>
> In theory, restart of PMTUD should not lead to
> fatal problems, we will get new MTUs. But with such
> change should be better, not much, because all MTU
> events will come at same time, later timer will expire
> and we will get again events from routers. The gain
> will be an increased period (with milliseconds to seconds)
> between PMTUD restarts. Compared to the 600-second timer,
> this should be gain below 1% in reduced traffic for PMTUD.
> Before now we started timer from first router, now we
> will start/update timer period after event from last router.
>
Sorry I dont really understand what you mean
> But ipv4_link_failure and ip6_link_failure want to stop
> this timer by setting it to NOW (0). May be we have to add
> also a !timeout check here or to leave the code as before?
>
> > - if (dst->expires == 0 || time_before(expires, dst->expires))
> > + if (dst->expires == 0 || time_after(expires, dst->expires))
> > dst->expires = expires;
> > }
>
> The original problem should be somewhere else, I think.
This patch fixed the problem for me.
My first patch was :
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..9858714 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -956,6 +956,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
dst->obsolete = DST_OBSOLETE_KILL;
} else {
rt->rt_pmtu = mtu;
+ rt->dst.expires = 0;
dst_set_expires(&rt->dst, ip_rt_mtu_expires);
}
}
^ permalink raw reply related
* RE: [PATCH] ethtool: don't overwrite useful bits in advertising bitfield
From: Johan Gunnarsson @ 2012-08-21 16:45 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev@vger.kernel.org, Mikael Starvik
In-Reply-To: <1345561910.2659.45.camel@bwh-desktop.uk.solarflarecom.com>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: den 21 augusti 2012 17:12
> To: Johan Gunnarsson
> Cc: netdev@vger.kernel.org; Mikael Starvik
> Subject: RE: [PATCH] ethtool: don't overwrite useful bits in
> advertising bitfield
>
> On Tue, 2012-08-21 at 10:41 +0200, Johan Gunnarsson wrote:
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > > owner@vger.kernel.org] On Behalf Of Ben Hutchings
> > > Sent: den 20 augusti 2012 17:23
> > > To: Johan Gunnarsson
> > > Cc: netdev@vger.kernel.org; Mikael Starvik
> > > Subject: Re: [PATCH] ethtool: don't overwrite useful bits in
> > > advertising bitfield
> > >
> > > On Tue, 2012-08-14 at 16:15 +0200, Johan Gunnarsson wrote:
> > > > There are bits in this bitfield that we want to leave untouched
> > > (PAUSE
> > > > and ASYM_PAUSE bits) when changing other bits (speed and duplex
> > > bits.)
> > > > Previously, these were always overwritten to zero when running
> > > commands
> > > > like "ethtool -s eth0 speed 10 duplex full autoneg off".
> > >
> > > This is right in principle, but the implementation isn't quite
> right.
> > >
> > > > Signed-off-by: Johan Gunnarsson <johangu@axis.com>
> > > > ---
> > > > ethtool.c | 45 +++++++++++++++++++++++++++++++--------------
> > > > 1 file changed, 31 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/ethtool.c b/ethtool.c
> > > > index e573357..efa12c7 100644
> > > > --- a/ethtool.c
> > > > +++ b/ethtool.c
> > > > @@ -46,6 +46,18 @@
> > > > #define MAX_ADDR_LEN 32
> > > > #endif
> > > >
> > > > +#define ALL_ADVERTISED_MODES \
> > > > + (ADVERTISED_10baseT_Half | \
> > > > + ADVERTISED_10baseT_Full | \
> > > > + ADVERTISED_100baseT_Half | \
> > > > + ADVERTISED_100baseT_Full | \
> > > > + ADVERTISED_1000baseT_Half | \
> > > > + ADVERTISED_1000baseT_Full | \
> > > > + ADVERTISED_2500baseX_Full | \
> > > > + ADVERTISED_10000baseT_Full | \
> > > > + ADVERTISED_20000baseMLD2_Full | \
> > > > + ADVERTISED_20000baseKR2_Full)
> > >
> > > This is missing the new 40G modes (not a regression, I realise).
> >
> > I'll add the 40G modes. There is also a bunch of 10G modes missing.
> Shall I add these too?
>
> Yes please.
Alright.
>
> > >
> > > [...]
> > > > @@ -2405,19 +2421,20 @@ static int do_sset(struct cmd_context
> *ctx)
> > > > }
> > > > if (autoneg_wanted == AUTONEG_ENABLE &&
> > > > advertising_wanted == 0) {
> > > > - ecmd.advertising = ecmd.supported &
> > > > - (ADVERTISED_10baseT_Half |
> > > > - ADVERTISED_10baseT_Full |
> > > > - ADVERTISED_100baseT_Half |
> > > > - ADVERTISED_100baseT_Full |
> > > > - ADVERTISED_1000baseT_Half |
> > > > - ADVERTISED_1000baseT_Full |
> > > > - ADVERTISED_2500baseX_Full |
> > > > - ADVERTISED_10000baseT_Full |
> > > > - ADVERTISED_20000baseMLD2_Full |
> > > > - ADVERTISED_20000baseKR2_Full);
> > > > + /* Auto negotation enabled, but with
> > > > + * unspecified speed and duplex: enable
> all
> > > > + * supported speeds and duplexes.
> > > > + */
> > > > + ecmd.advertising = (ecmd.advertising &
> > > > + ~ALL_ADVERTISED_MODES) |
> > > > + (ALL_ADVERTISED_MODES &
> ecmd.supported);
> > >
> > > Perhaps we should also warn if there's a 'supported' flag we don't
> > > recognise, because we don't know whether it's a link mode and we
> might
> > > be failing to enable/disable it as requested.
> >
> > You mean if ecmd.supported has bits enabled that ALL_ADVERTISED_MODES
> > hasn't? I don't think that's a good idea, because that happens very
> > often (for example PAUSE bits in my case.)
>
> No, I mean if it has bits enabled that are not defined at all
> (currently
> any of bits 27-31).
Not totally sure I follow. Care to show me?
>
> > >
> > > > } else if (advertising_wanted > 0) {
> > > > - ecmd.advertising = advertising_wanted;
> > > > + /* Enable all requested modes */
> > > > + ecmd.advertising = (ecmd.advertising &
> > > > + ~ALL_ADVERTISED_MODES) |
> > > > + (advertising_wanted &
> ecmd.supported);
> > >
> > > I don't think the '& ecmd.supported' here is right. If an autoneg
> > > device supports some new link mode L that is not in
> > > ALL_ADVERTISED_MODES, but not link mode M which the user requested,
> > > then
> > > this can silently fail because the resulting advertising mask will
> > > include L but not M.
> > >
> > > We should either use advertising_wanted unmasked and let the driver
> > > validate it, or report an error if it's not present in the
> supported
> > > mask. I think we should be consistent with the following case,
> i.e.
> > > let
> > > the driver validate it.
> >
> > How about remove "& ecmd.supported", but also warn if trying to add
> an
> > unsupported mode? Similar to the previous case.
> [...]
>
> I don't think this is similar and I don't think we need to do both.
So let's go for the removed "& ecmd.supported" then.
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: IP fragmentation broken in 3.6-rc ?
From: Julian Anastasov @ 2012-08-21 16:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sylvain Munaut, netdev
In-Reply-To: <1345560131.5158.500.camel@edumazet-glaptop>
Hello,
On Tue, 21 Aug 2012, Eric Dumazet wrote:
> Following patch should help :
>
> diff --git a/include/net/dst.h b/include/net/dst.h
> index 621e351..a04aa37 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -435,7 +435,7 @@ static inline void dst_set_expires(struct dst_entry *dst, int timeout)
> if (expires == 0)
> expires = 1;
>
In theory, restart of PMTUD should not lead to
fatal problems, we will get new MTUs. But with such
change should be better, not much, because all MTU
events will come at same time, later timer will expire
and we will get again events from routers. The gain
will be an increased period (with milliseconds to seconds)
between PMTUD restarts. Compared to the 600-second timer,
this should be gain below 1% in reduced traffic for PMTUD.
Before now we started timer from first router, now we
will start/update timer period after event from last router.
But ipv4_link_failure and ip6_link_failure want to stop
this timer by setting it to NOW (0). May be we have to add
also a !timeout check here or to leave the code as before?
> - if (dst->expires == 0 || time_before(expires, dst->expires))
> + if (dst->expires == 0 || time_after(expires, dst->expires))
> dst->expires = expires;
> }
The original problem should be somewhere else, I think.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH] af_netlink: force credentials passing [CVE-2012-3520]
From: Eric Dumazet @ 2012-08-21 16:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Petr Matousek, Florian Weimer, Pablo Neira Ayuso
From: Eric Dumazet <edumazet@google.com>
Pablo Neira Ayuso discovered that avahi and
potentially NetworkManager accept spoofed Netlink messages because of a
kernel bug. The kernel passes all-zero SCM_CREDENTIALS ancillary data
to the receiver if the sender did not provide such data, instead of not
including any such data at all or including the correct data from the
peer (as it is the case with AF_UNIX).
This bug was introduced in commit 16e572626961
(af_unix: dont send SCM_CREDENTIALS by default)
This patch forces passing credentials for netlink, as
before the regression.
Another fix would be to not add SCM_CREDENTIALS in
netlink messages if not provided by the sender, but it
might break some programs.
With help from Florian Weimer & Petr Matousek
This issue is designated as CVE-2012-3520
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/scm.h | 4 +++-
net/netlink/af_netlink.c | 2 +-
net/unix/af_unix.c | 4 ++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/net/scm.h b/include/net/scm.h
index 079d788..7dc0854 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -70,9 +70,11 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
}
static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
- struct scm_cookie *scm)
+ struct scm_cookie *scm, bool forcecreds)
{
memset(scm, 0, sizeof(*scm));
+ if (forcecreds)
+ scm_set_cred(scm, task_tgid(current), current_cred());
unix_get_peersec_dgram(sock, scm);
if (msg->msg_controllen <= 0)
return 0;
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5463969..1445d73 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1362,7 +1362,7 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (NULL == siocb->scm)
siocb->scm = &scm;
- err = scm_send(sock, msg, siocb->scm);
+ err = scm_send(sock, msg, siocb->scm, true);
if (err < 0)
return err;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e4768c1..c5ee4ff 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1450,7 +1450,7 @@ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (NULL == siocb->scm)
siocb->scm = &tmp_scm;
wait_for_unix_gc();
- err = scm_send(sock, msg, siocb->scm);
+ err = scm_send(sock, msg, siocb->scm, false);
if (err < 0)
return err;
@@ -1619,7 +1619,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (NULL == siocb->scm)
siocb->scm = &tmp_scm;
wait_for_unix_gc();
- err = scm_send(sock, msg, siocb->scm);
+ err = scm_send(sock, msg, siocb->scm, false);
if (err < 0)
return err;
^ permalink raw reply related
* Re: [PATCH] tun: don't zeroize sock->file on detach
From: Stanislav Kinsbursky @ 2012-08-21 16:04 UTC (permalink / raw)
To: David Miller
Cc: dhowells@redhat.com, netdev@vger.kernel.org, rick.jones2@hp.com,
ycheng@google.com, linux-kernel@vger.kernel.org, mikulas
In-Reply-To: <20120809.161639.1789560369123168415.davem@davemloft.net>
10.08.2012 03:16, David Miller пишет:
> From: Stanislav Kinsbursky <skinsbursky@parallels.com>
> Date: Thu, 09 Aug 2012 16:50:40 +0400
>
>> This is a fix for bug, introduced in 3.4 kernel by commit
>> 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things, replaced
>> simple sock_put() by sk_release_kernel(). Below is sequence, which leads to
>> oops for non-persistent devices:
>>
>> tun_chr_close()
>> tun_detach() <== tun->socket.file = NULL
>> tun_free_netdev()
>> sk_release_sock()
>> sock_release(sock->file == NULL)
>> iput(SOCK_INODE(sock)) <== dereference on NULL pointer
>>
>> This patch just removes zeroing of socket's file from __tun_detach().
>> sock_release() will do this.
>>
>> Cc: stable@vger.kernel.org
>> Reported-by: Ruan Zhijie <ruanzhijie@hotmail.com>
>> Tested-by: Ruan Zhijie <ruanzhijie@hotmail.com>
>> Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
>> Acked-by: Eric Dumazet <edumazet@google.com>
>> Acked-by: Yuchung Cheng <ycheng@google.com>
>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> Applied, thanks.
>
Hi, David.
I found out, that this commit: b09e786bd1dd66418b69348cb110f3a64764626a
was previous attempt to fix the problem.
I believe this commit have to be dropped.
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Getting VLANS to the vm ping / UDP working but TCP not
From: Andrew Holway @ 2012-08-21 14:03 UTC (permalink / raw)
To: kvm
Hi,
I am trying out a couple of methods to get VLANs to the VM. In both cases the VM can ping google et all without problem and DNS works fine but it does not want to do any TCP. I thought this might be a frame size problem but even using telnet (which I understand sends tiny packets) fails to work.
Why would udp / ping work fine when tcp fails?
I saw some kind of weird packet on the bridge when I was trying to connect to a web server running on the VM with telnet.
15:11:47.464656 01:00:00:0e:00:24 (oui Unknown) > 00:00:01:00:00:00 (oui Unknown), ethertype Unknown (0xdcd9), length 66:
0x0000: 84a8 0800 4510 0030 cd23 4000 4006 527b ....E..0.#@.@.R{
0x0010: 257b 6811 257b 6812 f487 0050 da75 1e54 %{h.%{h....P.u.T
0x0020: 0000 0000 7002 ffff 7b65 0000 0204 05b4 ....p...{e......
0x0030: 0402 0000
But its hard to repeat them.
Any ideas?
Thanks,
Andrew
a) vm001 is on node002 and has the following xml:
[root@node002 ~]# virsh dumpxml vm001
...
<interface type='bridge'>
<mac address='00:00:00:00:00:0e'/>
<source bridge='br0'/>
<target dev='vnet0'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='bridge'>
<mac address='00:00:01:00:00:0e'/>
<source bridge='br1'/>
<target dev='vnet1'/>
<model type='e1000'/>
<alias name='net1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
…
[root@vm001 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:00:00:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 10.141.100.1/16 brd 10.141.255.255 scope global eth0
inet6 fe80::200:ff:fe00:e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:00:01:00:00:0e brd ff:ff:ff:ff:ff:ff
###
4: eth1.4@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:00:01:00:00:0e brd ff:ff:ff:ff:ff:ff
inet 37.123.104.18/29 brd 37.123.104.23 scope global eth1.4
inet6 fe80::200:1ff:fe00:e/64 scope link
valid_lft forever preferred_lft forever
###
[root@node002 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UNKNOWN qlen 1000
link/ether 00:02:c9:34:67:31 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:9c:02:24:1a:e0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::29c:2ff:fe24:1ae0/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1522 qdisc mq state UP qlen 1000
link/ether 00:9c:02:24:1a:e4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::29c:2ff:fe24:1ae4/64 scope link
valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 00:9c:02:24:1a:e0 brd ff:ff:ff:ff:ff:ff
inet 10.141.0.2/16 brd 10.141.255.255 scope global br0
inet6 fe80::29c:2ff:fe24:1ae0/64 scope link
valid_lft forever preferred_lft forever
7: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1522 qdisc noqueue state UNKNOWN
link/ether 00:9c:02:24:1a:e4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::29c:2ff:fe24:1ae4/64 scope link
valid_lft forever preferred_lft forever
8: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 52:54:00:81:84:9f brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
9: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
link/ether 52:54:00:81:84:9f brd ff:ff:ff:ff:ff:ff
33: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether fe:00:00:00:00:0e brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:ff:fe00:e/64 scope link
valid_lft forever preferred_lft forever
34: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1522 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether fe:00:01:00:00:0e brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc00:1ff:fe00:e/64 scope link
valid_lft forever preferred_lft forever
[root@node002 ~]# sysctl -a | grep tcp
fs.nfs.nlm_tcpport = 0
fs.nfs.nfs_callback_tcpport = 0
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 12397248 16529664 24794496
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 262144
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_thin_dupack = 0
sunrpc.transports = tcp 1048576
sunrpc.transports = tcp-bc 1048576
sunrpc.tcp_slot_table_entries = 2
sunrpc.tcp_max_slot_table_entries = 65536
sunrpc.tcp_fin_timeout = 15
^ permalink raw reply
* Re: regression with poll(2)
From: Andrew Morton @ 2012-08-21 15:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mel Gorman, Sage Weil, David Miller, netdev, linux-kernel,
ceph-devel, Neil Brown, Peter Zijlstra, michaelc, emunson,
Eric Dumazet, Christoph Lameter
In-Reply-To: <CA+55aFw6S85jR+5zP9W6YykdsTMSVw9T5ibW93Gtx2rjw-b2EA@mail.gmail.com>
On Mon, 20 Aug 2012 10:02:05 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Aug 20, 2012 at 2:04 AM, Mel Gorman <mgorman@suse.de> wrote:
> >
> > Can the following patch be tested please? It is reported to fix an fio
> > regression that may be similar to what you are experiencing but has not
> > been picked up yet.
>
> Andrew, is this in your queue, or should I take this directly, or
> what? It seems to fix the problem for Eric and Sage, at least.
Yes, I have a copy queued:
From: Alex Shi <alex.shi@intel.com>
Subject: mm: correct page->pfmemalloc to fix deactivate_slab regression
cfd19c5a9ec ("mm: only set page->pfmemalloc when ALLOC_NO_WATERMARKS was
used") tried to narrow down page->pfmemalloc setting, but it missed some
places the pfmemalloc should be set.
So, in __slab_alloc, the unalignment pfmemalloc and ALLOC_NO_WATERMARKS
cause incorrect deactivate_slab() on our core2 server:
64.73% fio [kernel.kallsyms] [k] _raw_spin_lock
|
--- _raw_spin_lock
|
|---0.34%-- deactivate_slab
| __slab_alloc
| kmem_cache_alloc
| |
That causes our fio sync write performance to have a 40% regression.
Move the checking in get_page_from_freelist() which resolves this issue.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: David Miller <davem@davemloft.net
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Sage Weil <sage@inktank.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/page_alloc.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff -puN mm/page_alloc.c~mm-correct-page-pfmemalloc-to-fix-deactivate_slab-regression mm/page_alloc.c
--- a/mm/page_alloc.c~mm-correct-page-pfmemalloc-to-fix-deactivate_slab-regression
+++ a/mm/page_alloc.c
@@ -1928,6 +1928,17 @@ this_zone_full:
zlc_active = 0;
goto zonelist_scan;
}
+
+ if (page)
+ /*
+ * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
+ * necessary to allocate the page. The expectation is
+ * that the caller is taking steps that will free more
+ * memory. The caller should avoid the page being used
+ * for !PFMEMALLOC purposes.
+ */
+ page->pfmemalloc = !!(alloc_flags & ALLOC_NO_WATERMARKS);
+
return page;
}
@@ -2389,14 +2400,6 @@ rebalance:
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
if (page) {
- /*
- * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
- * necessary to allocate the page. The expectation is
- * that the caller is taking steps that will free more
- * memory. The caller should avoid the page being used
- * for !PFMEMALLOC purposes.
- */
- page->pfmemalloc = true;
goto got_pg;
}
}
@@ -2569,8 +2572,6 @@ retry_cpuset:
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
- else
- page->pfmemalloc = false;
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
_
^ permalink raw reply
* netconsole leads to stalled CPU task
From: Sylvain Munaut @ 2012-08-21 15:13 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to use the netconsole to feed kernel message to the outside
but this lead to a stall ...
This only happens in a fairly specific configuration where you have a
bridge over vlan over bonding.
I tested with only (bridge over vlan) and (vlan over bonding) and
those work fine.
bash# modprobe netconsole
netconsole=8888@10.208.1.30/mgmt,8000@10.208.1.3/00:16:3e:1a:37:37
[... never returns ... ]
dmesg:
[ 130.672942] netpoll: netconsole: local port 8888
[ 130.673206] netpoll: netconsole: local IP 10.208.1.30
[ 130.673460] netpoll: netconsole: interface 'mgmt'
[ 130.673735] netpoll: netconsole: remote port 8000
[ 130.673984] netpoll: netconsole: remote IP 10.208.1.3
[ 130.674231] netpoll: netconsole: remote ethernet address 00:16:3e:1a:37:37
[ 132.975290] console [netcon0] enabled
[ 132.975541] netconsole: network logging started
[ 190.677624] INFO: rcu_preempt detected stalls on CPUs/tasks: { 15}
(detected by 2, t=60002 jiffies)
[ 190.678218] INFO: Stall ended before state dump start
[ 370.682595] INFO: rcu_preempt detected stalls on CPUs/tasks: { 15}
(detected by 2, t=240007 jiffies)
[ 370.683197] INFO: Stall ended before state dump start
[ 451.664596] INFO: rcu_bh detected stalls on CPUs/tasks: { 15}
(detected by 16, t=60004 jiffies)
[ 451.665190] INFO: Stall ended before state dump start
[ 550.687619] INFO: rcu_preempt detected stalls on CPUs/tasks: { 15}
(detected by 16, t=420012 jiffies)
[ 550.688211] INFO: Stall ended before state dump start
[ 631.669621] INFO: rcu_bh detected stalls on CPUs/tasks: { 15}
(detected by 2, t=240009 jiffies)
[ 631.670220] INFO: Stall ended before state dump start
ifconfig:
bond0 Link encap:Ethernet HWaddr 18:03:73:ed:67:ad
inet6 addr: fe80::1a03:73ff:feed:67ad/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:735 errors:0 dropped:1 overruns:0 frame:0
TX packets:127 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:99136 (96.8 KiB) TX bytes:40635 (39.6 KiB)
bond0.1 Link encap:Ethernet HWaddr 18:03:73:ed:67:ad
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:283 errors:0 dropped:0 overruns:0 frame:0
TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:41948 (40.9 KiB) TX bytes:37915 (37.0 KiB)
eth0 Link encap:Ethernet HWaddr 18:03:73:ed:67:ad
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:450 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:52085 (50.8 KiB) TX bytes:1053 (1.0 KiB)
eth2 Link encap:Ethernet HWaddr 18:03:73:ed:67:ad
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:285 errors:0 dropped:1 overruns:0 frame:0
TX packets:117 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47051 (45.9 KiB) TX bytes:39582 (38.6 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
mgmt Link encap:Ethernet HWaddr 18:03:73:ed:67:ad
inet addr:10.208.1.30 Bcast:10.208.1.255 Mask:255.255.255.0
inet6 addr: fe80::1a03:73ff:feed:67ad/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:280 errors:0 dropped:0 overruns:0 frame:0
TX packets:108 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:41713 (40.7 KiB) TX bytes:37915 (37.0 KiB)
Cheers,
Sylvain
^ permalink raw reply
* Re: [net-next 1/6] ethtool.h: MDI setting support
From: Ben Hutchings @ 2012-08-21 15:12 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Jesse Brandeburg, netdev, gospo, sassmann
In-Reply-To: <1345538275-1690-2-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 2012-08-21 at 01:37 -0700, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> This change modifies the core ethtool struct to allow a driver to
> support setting of MDI/MDI-X state for twisted pair wiring. This
> change uses a previously reserved u8 and should not change any
> binary compatibility of ethtool.
>
> Also as per Ben Hutchings' suggestion, the capabilities are
> stored in a separate byte so the driver can report if it supports
> changing settings.
>
> see thread: http://kerneltrap.org/mailarchive/linux-netdev/2010/11/17/6289820/thread
>
> see ethtool patches titled:
> ethtool: allow setting MDI-X state
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: Ben Hutchings <bhutchings@solarflare.com>
> Tested-by: Aaron Brown aaron.f.brown@intel.com
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> include/linux/ethtool.h | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 21eff41..fcb4f8e 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -45,8 +45,10 @@ struct ethtool_cmd {
> * bits) in Mbps. Please use
> * ethtool_cmd_speed()/_set() to
> * access it */
> - __u8 eth_tp_mdix;
> - __u8 reserved2;
> + __u8 eth_tp_mdix; /* twisted pair MDI-X status */
> + __u8 eth_tp_mdix_ctrl; /* twisted pair MDI-X control, when set,
> + * link should be renegotiated if necessary
> + */
> __u32 lp_advertising; /* Features the link partner advertises */
> __u32 reserved[2];
> };
> @@ -1229,10 +1231,13 @@ struct ethtool_ops {
> #define AUTONEG_DISABLE 0x00
> #define AUTONEG_ENABLE 0x01
>
> -/* Mode MDI or MDI-X */
> -#define ETH_TP_MDI_INVALID 0x00
> -#define ETH_TP_MDI 0x01
> -#define ETH_TP_MDI_X 0x02
> +/* MDI or MDI-X status/control - if MDI/MDI_X/AUTO is set then
> + * the driver is required to renegotiate link
> + */
> +#define ETH_TP_MDI_INVALID 0x00 /* status: unknown; control: unsupported */
> +#define ETH_TP_MDI 0x01 /* status: MDI; control: force MDI */
> +#define ETH_TP_MDI_X 0x02 /* status: MDI-X; control: force MDI-X */
> +#define ETH_TP_MDI_AUTO 0x03 /* control: auto-select */
>
> /* Wake-On-Lan options. */
> #define WAKE_PHY (1 << 0)
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH] ethtool: don't overwrite useful bits in advertising bitfield
From: Ben Hutchings @ 2012-08-21 15:11 UTC (permalink / raw)
To: Johan Gunnarsson; +Cc: netdev@vger.kernel.org, Mikael Starvik
In-Reply-To: <A612847CFE53224C91B23E3A5B48BAC7534E8D76AD@xmail3.se.axis.com>
On Tue, 2012-08-21 at 10:41 +0200, Johan Gunnarsson wrote:
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Ben Hutchings
> > Sent: den 20 augusti 2012 17:23
> > To: Johan Gunnarsson
> > Cc: netdev@vger.kernel.org; Mikael Starvik
> > Subject: Re: [PATCH] ethtool: don't overwrite useful bits in
> > advertising bitfield
> >
> > On Tue, 2012-08-14 at 16:15 +0200, Johan Gunnarsson wrote:
> > > There are bits in this bitfield that we want to leave untouched
> > (PAUSE
> > > and ASYM_PAUSE bits) when changing other bits (speed and duplex
> > bits.)
> > > Previously, these were always overwritten to zero when running
> > commands
> > > like "ethtool -s eth0 speed 10 duplex full autoneg off".
> >
> > This is right in principle, but the implementation isn't quite right.
> >
> > > Signed-off-by: Johan Gunnarsson <johangu@axis.com>
> > > ---
> > > ethtool.c | 45 +++++++++++++++++++++++++++++++--------------
> > > 1 file changed, 31 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/ethtool.c b/ethtool.c
> > > index e573357..efa12c7 100644
> > > --- a/ethtool.c
> > > +++ b/ethtool.c
> > > @@ -46,6 +46,18 @@
> > > #define MAX_ADDR_LEN 32
> > > #endif
> > >
> > > +#define ALL_ADVERTISED_MODES \
> > > + (ADVERTISED_10baseT_Half | \
> > > + ADVERTISED_10baseT_Full | \
> > > + ADVERTISED_100baseT_Half | \
> > > + ADVERTISED_100baseT_Full | \
> > > + ADVERTISED_1000baseT_Half | \
> > > + ADVERTISED_1000baseT_Full | \
> > > + ADVERTISED_2500baseX_Full | \
> > > + ADVERTISED_10000baseT_Full | \
> > > + ADVERTISED_20000baseMLD2_Full | \
> > > + ADVERTISED_20000baseKR2_Full)
> >
> > This is missing the new 40G modes (not a regression, I realise).
>
> I'll add the 40G modes. There is also a bunch of 10G modes missing. Shall I add these too?
Yes please.
> >
> > [...]
> > > @@ -2405,19 +2421,20 @@ static int do_sset(struct cmd_context *ctx)
> > > }
> > > if (autoneg_wanted == AUTONEG_ENABLE &&
> > > advertising_wanted == 0) {
> > > - ecmd.advertising = ecmd.supported &
> > > - (ADVERTISED_10baseT_Half |
> > > - ADVERTISED_10baseT_Full |
> > > - ADVERTISED_100baseT_Half |
> > > - ADVERTISED_100baseT_Full |
> > > - ADVERTISED_1000baseT_Half |
> > > - ADVERTISED_1000baseT_Full |
> > > - ADVERTISED_2500baseX_Full |
> > > - ADVERTISED_10000baseT_Full |
> > > - ADVERTISED_20000baseMLD2_Full |
> > > - ADVERTISED_20000baseKR2_Full);
> > > + /* Auto negotation enabled, but with
> > > + * unspecified speed and duplex: enable all
> > > + * supported speeds and duplexes.
> > > + */
> > > + ecmd.advertising = (ecmd.advertising &
> > > + ~ALL_ADVERTISED_MODES) |
> > > + (ALL_ADVERTISED_MODES & ecmd.supported);
> >
> > Perhaps we should also warn if there's a 'supported' flag we don't
> > recognise, because we don't know whether it's a link mode and we might
> > be failing to enable/disable it as requested.
>
> You mean if ecmd.supported has bits enabled that ALL_ADVERTISED_MODES
> hasn't? I don't think that's a good idea, because that happens very
> often (for example PAUSE bits in my case.)
No, I mean if it has bits enabled that are not defined at all (currently
any of bits 27-31).
> >
> > > } else if (advertising_wanted > 0) {
> > > - ecmd.advertising = advertising_wanted;
> > > + /* Enable all requested modes */
> > > + ecmd.advertising = (ecmd.advertising &
> > > + ~ALL_ADVERTISED_MODES) |
> > > + (advertising_wanted & ecmd.supported);
> >
> > I don't think the '& ecmd.supported' here is right. If an autoneg
> > device supports some new link mode L that is not in
> > ALL_ADVERTISED_MODES, but not link mode M which the user requested,
> > then
> > this can silently fail because the resulting advertising mask will
> > include L but not M.
> >
> > We should either use advertising_wanted unmasked and let the driver
> > validate it, or report an error if it's not present in the supported
> > mask. I think we should be consistent with the following case, i.e.
> > let
> > the driver validate it.
>
> How about remove "& ecmd.supported", but also warn if trying to add an
> unsupported mode? Similar to the previous case.
[...]
I don't think this is similar and I don't think we need to do both.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] iproute2: Add missing tc-ematch.8 for man page installation
From: Stephen Hemminger @ 2012-08-21 14:49 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Linux Netdev List
In-Reply-To: <503319AD.2090701@hartkopp.net>
On Tue, 21 Aug 2012 07:16:29 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied
^ permalink raw reply
* Re: IP fragmentation broken in 3.6-rc ?
From: Eric Dumazet @ 2012-08-21 14:42 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: netdev
In-Reply-To: <1345555336.5158.493.camel@edumazet-glaptop>
On Tue, 2012-08-21 at 15:22 +0200, Eric Dumazet wrote:
> On Tue, 2012-08-21 at 15:05 +0200, Sylvain Munaut wrote:
> > Hi,
> >
> > I'm starting to wonder if it's not related to
> > 46517008e1168dc926cf2c47d529efc07eca85c0 "ipv4: Kill
> > ip_rt_frag_needed()."
> >
> > Cheers,
> >
> > Sylvain
>
> Hmm, most probably problem came with commit
> ceb3320610d6f15ff20dd4c042b36473d77de76f
> (ipv4: Kill routes during PMTU/redirect updates.)
>
>
Following patch should help :
diff --git a/include/net/dst.h b/include/net/dst.h
index 621e351..a04aa37 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -435,7 +435,7 @@ static inline void dst_set_expires(struct dst_entry *dst, int timeout)
if (expires == 0)
expires = 1;
- if (dst->expires == 0 || time_before(expires, dst->expires))
+ if (dst->expires == 0 || time_after(expires, dst->expires))
dst->expires = expires;
}
^ permalink raw reply related
* (ipt_log_packet, sb_add) 3.6.0-rc2 kernel panic - not syncing; Fatal exception in interrupt
From: Sami Farin @ 2012-08-21 13:49 UTC (permalink / raw)
To: netdev; +Cc: Sami Farin, netdev
this with 3.6.0-rc2-g6dab7ede+ , x86_64 SMP, e1000e
gcc version 4.7.1 20120813 (Red Hat 4.7.1-7) (GCC)
motherboard Asus P8Z68-V pro gen3
https://docs.google.com/open?id=0B_EMXtsx7o56UnJqNUNmMjNaSkE
(screencapture, 2.2 MB)
RIP [<ffffffff8109078c>] __lock_acquire.isra.25+0x15f/0xb20
Call Trace:
sb_add
lock_acquire
dump_ipv4_packet
_raw_read_lock_bh
dump_ipv4_packet
dump_ipv4_packet
sb_add
ipt_log_packet
log_tg
ipt_do_table
iptable_filter_hook
nf_iterate
ip_rcv_finish
nf_hook_slow
...
from vmlinux:
0xffffffff8109075a <+301>: cmpl $0x0,0x1691a9f(%rip) # 0xffffffff82722200 <debug_locks_silent>
0xffffffff81090761 <+308>: jne 0xffffffff8109073f <__lock_acquire+274>
0xffffffff81090763 <+310>: mov $0xbd5,%esi
0xffffffff81090768 <+315>: mov $0xffffffff81a4e0c9,%rdi
0xffffffff8109076f <+322>: callq 0xffffffff8104761f <warn_slowpath_null>
0xffffffff81090774 <+327>: xor %eax,%eax
0xffffffff81090776 <+329>: jmpq 0xffffffff8109093a <__lock_acquire+781>
0xffffffff8109077b <+334>: mov %r12d,%eax
0xffffffff8109077e <+337>: mov 0x8(%r14,%rax,8),%rbx
0xffffffff81090783 <+342>: test %rbx,%rbx
0xffffffff81090786 <+345>: je 0xffffffff81090682 <__lock_acquire+85>
!! 0xffffffff8109078c <+351>: lock incl 0x198(%rbx)
0xffffffff81090793 <+358>: mov 0x660(%r13),%r15d
0xffffffff8109079a <+365>: mov 0xedfa0f(%rip),%r10d # 0xffffffff81f701b0 <oops_in_progress>
0xffffffff810907a1 <+372>: test %r10d,%r10d
0xffffffff810907a4 <+375>: jne 0xffffffff810907b0 <__lock_acquire+387>
0xffffffff810907a6 <+377>: cmp $0x2f,%r15d
0xffffffff810907aa <+381>: ja 0xffffffff810909fb <__lock_acquire+974>
0xffffffff810907b0 <+387>: sub $0xffffffff81fb66e0,%rbx
0xffffffff810907b7 <+394>: sar $0x4,%rbx
0xffffffff810907bb <+398>: movabs $0xef7bdef7bdef7bdf,%rax
0xffffffff810907c5 <+408>: imul %rax,%rbx
0xffffffff810907c9 <+412>: mov %ebx,%r11d
0xffffffff810907cc <+415>: lea 0x1(%rbx),%eax
0xffffffff810907cf <+418>: test %r15d,%r15d
0xffffffff810907d2 <+421>: je 0xffffffff81090902 <__lock_acquire+725>
0xffffffff810907d8 <+427>: mov %r15d,%edi
kernel 3.5.0-rc6-g4523e145+ worked ok for over a month..
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
MDI-X: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
--
Do what you love because life is too short for anything else.
^ permalink raw reply
* Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS
From: Julian Anastasov @ 2012-08-21 14:14 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Patrick McHardy, Hans Schillstrom, lvs-devel,
Simon Horman, Wensong Zhang, netfilter-devel
In-Reply-To: <20120820130840.1509.75794.stgit@dragon>
Hello,
On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:
> Based on patch from: Hans Schillstrom
>
> IPv6 headers must be processed in order of appearance,
> neither can it be assumed that Upper layer headers is first.
> If anything else than L4 is the first header IPVS will throw it.
>
> IPVS will write SNAT & DNAT modifications at a fixed pos which
> will corrupt the message. Proper header position must be found
> before writing modifying packet.
>
> This patch contains a lot of API changes. This is done, to avoid
> the costly scan of finding the IPv6 headers, via ipv6_find_hdr().
> Finding the IPv6 headers is done as early as possible, and passed
> on as a pointer "struct ip_vs_iphdr *" to the affected functions.
>
> Notice, I have choosen, not to change the API of function
> pointer "(*schedule)" (in struct ip_vs_scheduler) as it can be
> used by external schedulers, via {un,}register_ip_vs_scheduler.
> Only 4 out of 10 schedulers use info from ip_vs_iphdr*, and when
> they do, they are only interested in iph->{s,d}addr.
>
> This patch depends on commit 84018f55a:
> "netfilter: ip6_tables: add flags parameter to ipv6_find_hdr()"
>
> This also adds a dependency to ip6_tables.
>
> Hans left some questions in ip_vs_pe_sip.c, which I'm uncertain about.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
Patch 1 looks ok, following are some small comments
for patch 2 and 3.
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +#include <linux/netfilter_ipv6/ip6_tables.h>
> +#endif
There is already #if IS_ENABLED(CONFIG_IPV6) that
can replace #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
It seems we need IS_ENABLED for many places:
CONFIG_NF_CONNTRACK, CONFIG_NF_DEFRAG_IPV6
> @@ -958,34 +943,26 @@ static int ip_vs_out_icmp_v6(struct sk_buff *skb, int *related,
> }
>
> /* Now find the contained IP header */
> - offset += sizeof(_icmph);
> - cih = skb_header_pointer(skb, offset, sizeof(_ciph), &_ciph);
> - if (cih == NULL)
> - return NF_ACCEPT; /* The packet looks wrong, ignore */
> + ipvsh->len += sizeof(_icmph);
> + ip6 = skb_header_pointer(skb, ipvsh->len, sizeof(_ip6), &_ip6);
ip6 is not checked here for NULL or we rely on
ipv6_find_hdr checks?
> @@ -1506,39 +1464,43 @@ ip_vs_in_icmp_v6(struct sk_buff *skb, int *related, unsigned int hooknum)
> }
>
> /* Now find the contained IP header */
> - offset += sizeof(_icmph);
> - cih = skb_header_pointer(skb, offset, sizeof(_ciph), &_ciph);
> - if (cih == NULL)
> - return NF_ACCEPT; /* The packet looks wrong, ignore */
> + ciph.len = iph->len + sizeof(_icmph);
> + ciph.flags = 0;
> + ciph.fragoffs = 0;
> + ciph.protocol = ipv6_find_hdr(skb, &ciph.len, -1, &ciph.fragoffs,
> + &ciph.flags);
> + ciph.saddr = iph->saddr; /* con_in_get() handles reverse order */
> + ciph.daddr = iph->daddr;
The ciph initialization looks dangerous if one day
we add new field into the header.
Can we use ciph = (struct ip_vs_iphdr) { .XXX = val, ... },
in such case we have to call ipv6_find_hdr out of (after)
this initialization? Of course, we will write twice to
small fields such as protocol, len, fragoffs, flags
Also ipv6_find_hdr looks a bit noisy for missing header,
can it be a problem for the inner IPv6 header in ICMP messages?
In patch 3 ip_vs_in_icmp_v6 initializes ciph in the
same way. It will be difficult to audit the code later
considering the large number of places where iph is used.
> net = skb_net(skb);
> - pd = ip_vs_proto_data_get(net, cih->nexthdr);
> + pd = ip_vs_proto_data_get(net, ciph.protocol);
> if (!pd)
> return NF_ACCEPT;
> pp = pd->pp;
>
> - /* Is the embedded protocol header present? */
> - /* TODO: we don't support fragmentation at the moment anyways */
> - if (unlikely(cih->nexthdr == IPPROTO_FRAGMENT && pp->dont_defrag))
> + /* Is the embedded protocol header present?
> + * If it's the second or later fragment we don't know what it is
> + * i.e. just let it through.
> + */
> + if (ciph.fragoffs)
> return NF_ACCEPT;
>
> + offset = ciph.len;
> IP_VS_DBG_PKT(11, AF_INET6, pp, skb, offset,
> "Checking incoming ICMPv6 for");
>
> - offset += sizeof(struct ipv6hdr);
> -
> - ip_vs_fill_iphdr(AF_INET6, cih, &ciph);
> /* The embedded headers contain source and dest in reverse order */
> - cp = pp->conn_in_get(AF_INET6, skb, &ciph, offset, 1);
> + cp = pp->conn_in_get(AF_INET6, skb, &ciph, 1);
> if (!cp)
> return NF_ACCEPT;
>
> /* do the statistics and put it back */
> ip_vs_in_stats(cp, skb);
> - if (IPPROTO_TCP == cih->nexthdr || IPPROTO_UDP == cih->nexthdr ||
> - IPPROTO_SCTP == cih->nexthdr)
> - offset += 2 * sizeof(__u16);
> - verdict = ip_vs_icmp_xmit_v6(skb, cp, pp, offset, hooknum);
> + if (IPPROTO_TCP == ciph.protocol || IPPROTO_UDP == ciph.protocol ||
> + IPPROTO_SCTP == ciph.protocol)
> + offset = ciph.len + (2 * sizeof(__u16));
Still in the same func, above code is correct but
patch 3 changes it back to wrong state (offs_ciph = ciph.len).
> +
> + verdict = ip_vs_icmp_xmit_v6(skb, cp, pp, offset, hooknum, &ciph);
>
> __ip_vs_conn_put(cp);
> diff --git a/net/netfilter/ipvs/ip_vs_pe_sip.c b/net/netfilter/ipvs/ip_vs_pe_sip.c
> index 1aa5cac..bb28b4f 100644
> --- a/net/netfilter/ipvs/ip_vs_pe_sip.c
> +++ b/net/netfilter/ipvs/ip_vs_pe_sip.c
> @@ -68,26 +68,37 @@ static int get_callid(const char *dptr, unsigned int dataoff,
> static int
> ip_vs_sip_fill_param(struct ip_vs_conn_param *p, struct sk_buff *skb)
> {
> + struct sk_buff *reasm = skb_nfct_reasm(skb);
> struct ip_vs_iphdr iph;
> unsigned int dataoff, datalen, matchoff, matchlen;
> const char *dptr;
> int retc;
>
> - ip_vs_fill_iphdr(p->af, skb_network_header(skb), &iph);
> + ip_vs_fill_iph_skb(p->af, skb, &iph);
May be skb_linearize is bad for IPv6? IIRC,
ip_vs_pe_sip.c needs access just to read the Call-ID.
For IPv4 it was simple to use skb_linearize, may be
the logic should be improved to read the values even
from non-linear data. May be there is already some
example code for this. For IPv6 I'm not sure what
kind are the problems here, may be it depends if
we try to call skb_linearize for reasm packet?
> -
> - if ((retc=skb_linearize(skb)) < 0)
> + /*
> + * todo: Check if this will mess-up the reasm skb !!! /HS
> + */
> + retc = skb_linearize(reasm);
> + if (retc < 0)
> return retc;
> - dptr = skb->data + dataoff;
> - datalen = skb->len - dataoff;
> + dptr = reasm->data + dataoff;
> + datalen = reasm->len - dataoff;
>
> if (get_callid(dptr, dataoff, datalen, &matchoff, &matchlen))
> return -EINVAL;
There are recents changes for IPv6 from Patrick McHardy:
http://marc.info/?l=netfilter-devel&m=134543406303402&w=2
http://marc.info/?l=netfilter-devel&m=134543407803412&w=2
In this context, may be soon we will modify ip_vs_ftp to
support IPv6. It is possible to work with present FTP helper
in netfilter. Does it mean that we will see only reassembled
packets when conntrack is running? No original fragments.
Are we prepared to work in both ways (originals+reasm and
just reasm) ?
- For patch 3 in Kconfig do we need 'select NF_DEFRAG_IPV6' ?
Basicly, I'm concerned what will happen when we
start to mangle the protocol payloads (FTP). For now
we are safe by touching only addresses and ports. May be
we have to synchronize these changes with the work from
Patrick.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Cong Wang @ 2012-08-21 13:38 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Shan Wei, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <20120820202109.GB28790@unicorn.suse.cz>
On Mon, 2012-08-20 at 22:21 +0200, Michal Kubecek wrote:
> On Mon, Aug 20, 2012 at 05:06:39PM +0800, Cong Wang wrote:
> > doesn't work. I think we probably can save the struct net pointer in
> > struct netns_frags during inet_frags_init_net(), so that container_of()
> > can be eliminated.
>
> This would work but one would have to check carefully that the pointer
> is always set to an usable value. Or we could just add a flag indicating
> whether the structure is embedded (and if it is not, use init_net).
> Another approach was suggested in the patchworks discussion: add a
> special namespace for IPv6 conntrack fragment handling.
I think your former solution is easier, I will try it.
>
> > Thanks for testing! I tried to test it too, but seems I can't trigger a
> > defragment. Any hints?
>
> I used netfilter on a computer between source and destination of the
> packets (generated with "ping6 -s 3000"):
>
> ip6tables -A FORWARD -o ... -m frag --fragid 0:0xFFFFFFFF --fraglast -j DROP
>
> The --fragid condition is needed to work around a bug in iptables (if
> frag module is loaded and there is no --fragid, only packets with zero
> fragment id match - patch for this is already in git). On the target,
> packet is defragmented automatically, by default by the "normal" code,
> with nf_conntrack_ipv6 module by the conntrack code.
>
> Setting
>
> echo 5 >/proc/sys/net/ipv6/ip6frag_time
> echo 5 >/proc/sys/net/netfilter/nf_conntrack_frag6_timeout
>
> on target also helps.
>
Great! This helps!
Thanks!
^ permalink raw reply
* Re: IP fragmentation broken in 3.6-rc ?
From: Eric Dumazet @ 2012-08-21 13:22 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: netdev
In-Reply-To: <CAF6-1L6DTXPGi4kbcPqbOXrrafMmZ6K1QdcAa=PxJBzZWkvojg@mail.gmail.com>
On Tue, 2012-08-21 at 15:05 +0200, Sylvain Munaut wrote:
> Hi,
>
> I'm starting to wonder if it's not related to
> 46517008e1168dc926cf2c47d529efc07eca85c0 "ipv4: Kill
> ip_rt_frag_needed()."
>
> Cheers,
>
> Sylvain
Hmm, most probably problem came with commit
ceb3320610d6f15ff20dd4c042b36473d77de76f
(ipv4: Kill routes during PMTU/redirect updates.)
^ permalink raw reply
* Re: IP fragmentation broken in 3.6-rc ?
From: Sylvain Munaut @ 2012-08-21 13:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Hi,
I'm starting to wonder if it's not related to
46517008e1168dc926cf2c47d529efc07eca85c0 "ipv4: Kill
ip_rt_frag_needed()."
Cheers,
Sylvain
^ permalink raw reply
* Re: [net-next PATCH] mdio: translation of MMD EEE registers to/from ethtool settings
From: Giuseppe CAVALLARO @ 2012-08-21 12:47 UTC (permalink / raw)
To: Bruce Allan; +Cc: netdev
In-Reply-To: <20120820145529.19390.66175.stgit@bwallan-smackover2.jf.intel.com>
On 8/20/2012 4:55 PM, Bruce Allan wrote:
> The helper functions which translate IEEE MDIO Manageable Device (MMD)
> Energy-Efficient Ethernet (EEE) registers 3.20, 7.60 and 7.61 to and from
> the comparable ethtool supported/advertised settings will be needed by
> drivers other than those in PHYLIB (e.g. e1000e in a follow-on patch).
>
> In the same fashion as similar translation functions in linux/mii.h, move
> these functions from the PHYLIB core to the linux/mdio.h header file so the
> code will not have to be duplicated in each driver needing MMD-to-ethtool
> (and vice-versa) translations. The function and some variable names have
> been renamed to be more descriptive.
>
> Not tested on the only hardware that currently calls the related functions,
> stmmac, because I don't have access to any. Has been compile tested and
> the translations have been tested on a locally modified version of e1000e.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
I did some tests on my side with the stmmac and I've not seen any issues
on EEE. Also the patch looks fine to me.
Peppe
> ---
>
> drivers/net/phy/phy.c | 74 ++++----------------------------------------
> include/linux/mdio.h | 83 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 90 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 7ca2ff9..ef9ea92 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1035,66 +1035,6 @@ static void phy_write_mmd_indirect(struct mii_bus *bus, int prtad, int devad,
> bus->write(bus, addr, MII_MMD_DATA, data);
> }
>
> -static u32 phy_eee_to_adv(u16 eee_adv)
> -{
> - u32 adv = 0;
> -
> - if (eee_adv & MDIO_EEE_100TX)
> - adv |= ADVERTISED_100baseT_Full;
> - if (eee_adv & MDIO_EEE_1000T)
> - adv |= ADVERTISED_1000baseT_Full;
> - if (eee_adv & MDIO_EEE_10GT)
> - adv |= ADVERTISED_10000baseT_Full;
> - if (eee_adv & MDIO_EEE_1000KX)
> - adv |= ADVERTISED_1000baseKX_Full;
> - if (eee_adv & MDIO_EEE_10GKX4)
> - adv |= ADVERTISED_10000baseKX4_Full;
> - if (eee_adv & MDIO_EEE_10GKR)
> - adv |= ADVERTISED_10000baseKR_Full;
> -
> - return adv;
> -}
> -
> -static u32 phy_eee_to_supported(u16 eee_caported)
> -{
> - u32 supported = 0;
> -
> - if (eee_caported & MDIO_EEE_100TX)
> - supported |= SUPPORTED_100baseT_Full;
> - if (eee_caported & MDIO_EEE_1000T)
> - supported |= SUPPORTED_1000baseT_Full;
> - if (eee_caported & MDIO_EEE_10GT)
> - supported |= SUPPORTED_10000baseT_Full;
> - if (eee_caported & MDIO_EEE_1000KX)
> - supported |= SUPPORTED_1000baseKX_Full;
> - if (eee_caported & MDIO_EEE_10GKX4)
> - supported |= SUPPORTED_10000baseKX4_Full;
> - if (eee_caported & MDIO_EEE_10GKR)
> - supported |= SUPPORTED_10000baseKR_Full;
> -
> - return supported;
> -}
> -
> -static u16 phy_adv_to_eee(u32 adv)
> -{
> - u16 reg = 0;
> -
> - if (adv & ADVERTISED_100baseT_Full)
> - reg |= MDIO_EEE_100TX;
> - if (adv & ADVERTISED_1000baseT_Full)
> - reg |= MDIO_EEE_1000T;
> - if (adv & ADVERTISED_10000baseT_Full)
> - reg |= MDIO_EEE_10GT;
> - if (adv & ADVERTISED_1000baseKX_Full)
> - reg |= MDIO_EEE_1000KX;
> - if (adv & ADVERTISED_10000baseKX4_Full)
> - reg |= MDIO_EEE_10GKX4;
> - if (adv & ADVERTISED_10000baseKR_Full)
> - reg |= MDIO_EEE_10GKR;
> -
> - return reg;
> -}
> -
> /**
> * phy_init_eee - init and check the EEE feature
> * @phydev: target phy_device struct
> @@ -1132,7 +1072,7 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
> if (eee_cap < 0)
> return eee_cap;
>
> - cap = phy_eee_to_supported(eee_cap);
> + cap = mmd_eee_cap_to_ethtool_sup_t(eee_cap);
> if (!cap)
> goto eee_exit;
>
> @@ -1149,8 +1089,8 @@ int phy_init_eee(struct phy_device *phydev, bool clk_stop_enable)
> if (eee_adv < 0)
> return eee_adv;
>
> - adv = phy_eee_to_adv(eee_adv);
> - lp = phy_eee_to_adv(eee_lp);
> + adv = mmd_eee_adv_to_ethtool_adv_t(eee_adv);
> + lp = mmd_eee_adv_to_ethtool_adv_t(eee_lp);
> idx = phy_find_setting(phydev->speed, phydev->duplex);
> if ((lp & adv & settings[idx].setting))
> goto eee_exit;
> @@ -1210,21 +1150,21 @@ int phy_ethtool_get_eee(struct phy_device *phydev, struct ethtool_eee *data)
> MDIO_MMD_PCS, phydev->addr);
> if (val < 0)
> return val;
> - data->supported = phy_eee_to_supported(val);
> + data->supported = mmd_eee_cap_to_ethtool_sup_t(val);
>
> /* Get advertisement EEE */
> val = phy_read_mmd_indirect(phydev->bus, MDIO_AN_EEE_ADV,
> MDIO_MMD_AN, phydev->addr);
> if (val < 0)
> return val;
> - data->advertised = phy_eee_to_adv(val);
> + data->advertised = mmd_eee_adv_to_ethtool_adv_t(val);
>
> /* Get LP advertisement EEE */
> val = phy_read_mmd_indirect(phydev->bus, MDIO_AN_EEE_LPABLE,
> MDIO_MMD_AN, phydev->addr);
> if (val < 0)
> return val;
> - data->lp_advertised = phy_eee_to_adv(val);
> + data->lp_advertised = mmd_eee_adv_to_ethtool_adv_t(val);
>
> return 0;
> }
> @@ -1241,7 +1181,7 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val;
>
> - val = phy_adv_to_eee(data->advertised);
> + val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
> phy_write_mmd_indirect(phydev->bus, MDIO_AN_EEE_ADV, MDIO_MMD_AN,
> phydev->addr, val);
>
> diff --git a/include/linux/mdio.h b/include/linux/mdio.h
> index 7cccafe..6c40684 100644
> --- a/include/linux/mdio.h
> +++ b/include/linux/mdio.h
> @@ -377,5 +377,88 @@ static inline void mdio45_ethtool_gset(const struct mdio_if_info *mdio,
> extern int mdio_mii_ioctl(const struct mdio_if_info *mdio,
> struct mii_ioctl_data *mii_data, int cmd);
>
> +/**
> + * mmd_eee_cap_to_ethtool_sup_t
> + * @eee_cap: value of the MMD EEE Capability register
> + *
> + * A small helper function that translates MMD EEE Capability (3.20) bits
> + * to ethtool supported settings.
> + */
> +static inline u32 mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
> +{
> + u32 supported = 0;
> +
> + if (eee_cap & MDIO_EEE_100TX)
> + supported |= SUPPORTED_100baseT_Full;
> + if (eee_cap & MDIO_EEE_1000T)
> + supported |= SUPPORTED_1000baseT_Full;
> + if (eee_cap & MDIO_EEE_10GT)
> + supported |= SUPPORTED_10000baseT_Full;
> + if (eee_cap & MDIO_EEE_1000KX)
> + supported |= SUPPORTED_1000baseKX_Full;
> + if (eee_cap & MDIO_EEE_10GKX4)
> + supported |= SUPPORTED_10000baseKX4_Full;
> + if (eee_cap & MDIO_EEE_10GKR)
> + supported |= SUPPORTED_10000baseKR_Full;
> +
> + return supported;
> +}
> +
> +/**
> + * mmd_eee_adv_to_ethtool_adv_t
> + * @eee_adv: value of the MMD EEE Advertisement/Link Partner Ability registers
> + *
> + * A small helper function that translates the MMD EEE Advertisment (7.60)
> + * and MMD EEE Link Partner Ability (7.61) bits to ethtool advertisement
> + * settings.
> + */
> +static inline u32 mmd_eee_adv_to_ethtool_adv_t(u16 eee_adv)
> +{
> + u32 adv = 0;
> +
> + if (eee_adv & MDIO_EEE_100TX)
> + adv |= ADVERTISED_100baseT_Full;
> + if (eee_adv & MDIO_EEE_1000T)
> + adv |= ADVERTISED_1000baseT_Full;
> + if (eee_adv & MDIO_EEE_10GT)
> + adv |= ADVERTISED_10000baseT_Full;
> + if (eee_adv & MDIO_EEE_1000KX)
> + adv |= ADVERTISED_1000baseKX_Full;
> + if (eee_adv & MDIO_EEE_10GKX4)
> + adv |= ADVERTISED_10000baseKX4_Full;
> + if (eee_adv & MDIO_EEE_10GKR)
> + adv |= ADVERTISED_10000baseKR_Full;
> +
> + return adv;
> +}
> +
> +/**
> + * ethtool_adv_to_mmd_eee_adv_t
> + * @adv: the ethtool advertisement settings
> + *
> + * A small helper function that translates ethtool advertisement settings
> + * to EEE advertisements for the MMD EEE Advertisement (7.60) and
> + * MMD EEE Link Partner Ability (7.61) registers.
> + */
> +static inline u16 ethtool_adv_to_mmd_eee_adv_t(u32 adv)
> +{
> + u16 reg = 0;
> +
> + if (adv & ADVERTISED_100baseT_Full)
> + reg |= MDIO_EEE_100TX;
> + if (adv & ADVERTISED_1000baseT_Full)
> + reg |= MDIO_EEE_1000T;
> + if (adv & ADVERTISED_10000baseT_Full)
> + reg |= MDIO_EEE_10GT;
> + if (adv & ADVERTISED_1000baseKX_Full)
> + reg |= MDIO_EEE_1000KX;
> + if (adv & ADVERTISED_10000baseKX4_Full)
> + reg |= MDIO_EEE_10GKX4;
> + if (adv & ADVERTISED_10000baseKR_Full)
> + reg |= MDIO_EEE_10GKR;
> +
> + return reg;
> +}
> +
> #endif /* __KERNEL__ */
> #endif /* __LINUX_MDIO_H__ */
>
> --
> 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: Fwd: TCP fragmentation broken in 3.6-rc ?
From: Sylvain Munaut @ 2012-08-21 11:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1345478571.5158.323.camel@edumazet-glaptop>
Hi,
> Any chance you could post a tcpdump demonstrating the problem ?
> (including the tcp session plus icmp messages)
Here it is :
http://ge.tt/api/1/files/76YVbLM/0/blob?download
Cheers,
Sylvain
^ permalink raw reply
* [PATCH net-next] packet: Protect packet sk list with mutex (v2)
From: Pavel Emelyanov @ 2012-08-21 11:06 UTC (permalink / raw)
To: Eric Dumazet, David Miller, Linux Netdev List
Change since v1:
* Fixed inuse counters access spotted by Eric
In patch eea68e2f (packet: Report socket mclist info via diag module) I've
introduced a "scheduling in atomic" problem in packet diag module -- the
socket list is traversed under rcu_read_lock() while performed under it sk
mclist access requires rtnl lock (i.e. -- mutex) to be taken.
[152363.820563] BUG: scheduling while atomic: crtools/12517/0x10000002
[152363.820573] 4 locks held by crtools/12517:
[152363.820581] #0: (sock_diag_mutex){+.+.+.}, at: [<ffffffff81a2dcb5>] sock_diag_rcv+0x1f/0x3e
[152363.820613] #1: (sock_diag_table_mutex){+.+.+.}, at: [<ffffffff81a2de70>] sock_diag_rcv_msg+0xdb/0x11a
[152363.820644] #2: (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81a67d01>] netlink_dump+0x23/0x1ab
[152363.820693] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff81b6a049>] packet_diag_dump+0x0/0x1af
Similar thing was then re-introduced by further packet diag patches (fanount
mutex and pgvec mutex for rings) :(
Apart from being terribly sorry for the above, I propose to change the packet
sk list protection from spinlock to mutex. This lock currently protects two
modifications:
* sklist
* prot inuse counters
The sklist modifications can be just reprotected with mutex since they already
occur in a sleeping context. The inuse counters modifications are trickier -- the
__this_cpu_-s are used inside, thus requiring the caller to handle the potential
issues with contexts himself. Since packet sockets' counters are modified in two
places only (packet_create and packet_release) we only need to protect the context
from being preempted. BH disabling is not required in this case.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
diff --git a/include/net/netns/packet.h b/include/net/netns/packet.h
index cb4e894..4780b08 100644
--- a/include/net/netns/packet.h
+++ b/include/net/netns/packet.h
@@ -8,7 +8,7 @@
#include <linux/spinlock.h>
struct netns_packet {
- spinlock_t sklist_lock;
+ struct mutex sklist_lock;
struct hlist_head sklist;
};
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 226b2cd..79bc69c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2308,10 +2308,13 @@ static int packet_release(struct socket *sock)
net = sock_net(sk);
po = pkt_sk(sk);
- spin_lock_bh(&net->packet.sklist_lock);
+ mutex_lock(&net->packet.sklist_lock);
sk_del_node_init_rcu(sk);
+ mutex_unlock(&net->packet.sklist_lock);
+
+ preempt_disable();
sock_prot_inuse_add(net, sk->sk_prot, -1);
- spin_unlock_bh(&net->packet.sklist_lock);
+ preempt_enable();
spin_lock(&po->bind_lock);
unregister_prot_hook(sk, false);
@@ -2510,10 +2513,13 @@ static int packet_create(struct net *net, struct socket *sock, int protocol,
register_prot_hook(sk);
}
- spin_lock_bh(&net->packet.sklist_lock);
+ mutex_lock(&net->packet.sklist_lock);
sk_add_node_rcu(sk, &net->packet.sklist);
+ mutex_unlock(&net->packet.sklist_lock);
+
+ preempt_disable();
sock_prot_inuse_add(net, &packet_proto, 1);
- spin_unlock_bh(&net->packet.sklist_lock);
+ preempt_enable();
return 0;
out:
@@ -3766,7 +3772,7 @@ static const struct file_operations packet_seq_fops = {
static int __net_init packet_net_init(struct net *net)
{
- spin_lock_init(&net->packet.sklist_lock);
+ mutex_init(&net->packet.sklist_lock);
INIT_HLIST_HEAD(&net->packet.sklist);
if (!proc_net_fops_create(net, "packet", 0, &packet_seq_fops))
diff --git a/net/packet/diag.c b/net/packet/diag.c
index bc33fbe..39bce0d 100644
--- a/net/packet/diag.c
+++ b/net/packet/diag.c
@@ -177,8 +177,8 @@ static int packet_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
net = sock_net(skb->sk);
req = nlmsg_data(cb->nlh);
- rcu_read_lock();
- sk_for_each_rcu(sk, node, &net->packet.sklist) {
+ mutex_lock(&net->packet.sklist_lock);
+ sk_for_each(sk, node, &net->packet.sklist) {
if (!net_eq(sock_net(sk), net))
continue;
if (num < s_num)
@@ -192,7 +192,7 @@ next:
num++;
}
done:
- rcu_read_unlock();
+ mutex_unlock(&net->packet.sklist_lock);
cb->args[0] = num;
return skb->len;
^ permalink raw reply related
* Re: coping with memory limitations and packet flooding in codel and fq_codel
From: Eric Dumazet @ 2012-08-21 10:50 UTC (permalink / raw)
To: Andrew McGregor; +Cc: netdev, codel
In-Reply-To: <46C4C66E-A4EE-4051-9686-7AD02EE925B4@gmail.com>
On Tue, 2012-08-21 at 22:27 +1200, Andrew McGregor wrote:
> On 21/08/2012, at 8:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > ath9k driver is known to deliver very fat skbs (skb->truesize is too
> > big)
>
> What would it take to fix this?
>
> Andrew
Someone could use the following :
https://gerrit.chromium.org/gerrit/#/c/18412/
^ permalink raw reply
* Re: iputils git tree
From: Xose Vazquez Perez @ 2012-08-21 10:42 UTC (permalink / raw)
To: netdev
Jan Engelhardt wrote:
> And half of iputils has been superseded or thelike.
>
> * arping -> th's arping http://freecode.com/projects/arping
> * ifenslave -> bonding's sysfs files
> * tftpd -> tftpd-hpa
* traceroute6 -> http://traceroute.sf.net/
^ permalink raw reply
* Re: coping with memory limitations and packet flooding in codel and fq_codel
From: Andrew McGregor @ 2012-08-21 10:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, codel
In-Reply-To: <1345538298.5158.401.camel@edumazet-glaptop>
[-- Attachment #1.1: Type: text/plain, Size: 192 bytes --]
On 21/08/2012, at 8:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> ath9k driver is known to deliver very fat skbs (skb->truesize is too
> big)
What would it take to fix this?
Andrew
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2330 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ 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