* Re: [PATCH net-next FIX] RDMA/cma: Fix build breakage when infiniband is built-in
From: Or Gerlitz @ 2013-11-12 8:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, amirv, eyalpe
In-Reply-To: <20131111.004319.58572524940129607.davem@davemloft.net>
On 11/11/2013 07:43, David Miller wrote:
> I really want to merge the net-next tree as soon as possible so I
> committed the following:
>
> ====================
> [PATCH] vlan: Implement vlan_dev_get_egress_qos_mask as an inline.
>
> This is to avoid very silly Kconfig dependencies for modules
> using this routine.
>
> Signed-off-by: David S. Miller<davem@davemloft.net>
Dave, I have checked it in our environment and things work as expected,
thanks for taking care.
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Johannes Berg @ 2013-11-12 8:36 UTC (permalink / raw)
To: Karl Beldan
Cc: Hannes Frederic Sowa, Theodore Ts'o, Daniel Borkmann,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131112003709.GA11824@gobelin>
On Tue, 2013-11-12 at 01:37 +0100, Karl Beldan wrote:
> > > 1) I'm pretty sure, but it would be good to get netdev confirmation,
> > > that the call to get_random_bytes() in
> > > net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> > > by calls to prandom_u32().
> >
> > Would make sense. I added wireless-devel to confirm.
> >
> > [...]
> > [ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > [...]
> >
> > In total 80 calls to get_random_bytes.
> >
>
> It is already 8 times what rc80211_minstrel_ht_init uses.
> If you could apply on top of:
> http://marc.info/?l=linux-wireless&m=138392850030987&w=2
> although Johannes has not yet agreed/applied this.
I'll take the patch, I just wanted a more useful commit log :)
I guess if really needed I'll write that myself :(
Anyway, I can't comment on prandom_u32(), but it doesn't really have to
be all that random here, it's just sample tables for what order to try
things in. Technically that could even be static with some per-device
pertubation, I guess?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Willy Tarreau @ 2013-11-12 8:36 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: Cong Wang, edumazet, stable, linux-arm-kernel, netdev
In-Reply-To: <87y54u59zq.fsf@natisbad.org>
Hi Arnaud,
On Tue, Nov 12, 2013 at 08:56:25AM +0100, Arnaud Ebalard wrote:
> I had some offline (*) discussions w/ Eric and did some test w/ the patches
> he sent. It does not fix the regression I see. It would be nice if someone
> w/ the hardware and more knowledge of mvneta driver could reproduce the
> issue and spend some time on it.
I could give it a try but am falling very short of time at the moment.
> That been said, even if the driver is most probably not the only one to
> blame here (considering the result of bisect and current thread on
> netdev), I never managed to get the performance I have on my ReadyNAS
> Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
> platform (RN102, RN104 or RN2120). Understanding why is on an already a
> long todo list.
Yes I found that your original numbers were already quite low, so it is
also possible that you have a different problem (eg: faulty switch or
auto-negociation problem where the switch goes to half duplex because
the neta does not advertise nway or whatever) that is emphasized by the
latest changes.
> Cheers,
>
> a+
>
> (*): for some reasons, my messages to netdev and stable are not published
> even though I can interact w/ {majordomo,autoanswer}@vger.kernel.org. I
> poked postmaster@ bug got no reply yet.
I can confirm that I got this message from you on netdev so it should be OK
now.
Willy
^ permalink raw reply
* Re: [PATCH net] core/dev: do not ignore dmac in dev_forward_skb()
From: Nicolas Dichtel @ 2013-11-12 8:49 UTC (permalink / raw)
To: Alexei Starovoitov, David S. Miller
Cc: Eric Dumazet, netdev, Maciej Zenczykowski
In-Reply-To: <1384206735-4226-1-git-send-email-ast@plumgrid.com>
Le 11/11/2013 22:52, Alexei Starovoitov a écrit :
> commit 06a23fe31ca3
> ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> and refactoring 64261f230a91
> ("dev: move skb_scrub_packet() after eth_type_trans()")
>
> are forcing pkt_type to be PACKET_HOST when skb traverses veth.
>
> which means that ip forwarding will kick in inside netns
> even if skb->eth->h_dest != dev->dev_addr
>
> Revert offending commit
>
> Fixes: 06a23fe31ca3 ("core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()")
> CC: Maciej Zenczykowski <zenczykowski@gmail.com>
> CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
skb_scrub_packet() is also called after eth_type_trans() in ip_tunnel_rcv().
I do it to be consistent with dev_forward_skb(), thus it should be inverted too.
^ permalink raw reply
* Re: linux-next: manual merge of the random tree with the net-next tree
From: Daniel Borkmann @ 2013-11-12 8:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Theodore Ts'o, linux-next, linux-kernel, Hannes Frederic Sowa,
David Miller, netdev
In-Reply-To: <20131112155549.c160273993147244ed6bc81d@canb.auug.org.au>
Hi Stephen,
On 11/12/2013 05:55 AM, Stephen Rothwell wrote:
> Hi Ted,
>
> Today's linux-next merge of the random tree got a conflict in
> drivers/char/random.c between commit 0244ad004a54 ("random32: add
> prandom_reseed_late() and call when nonblocking pool becomes
> initialized") from the net-next tree and commit 301f0595c0e7 ("random:
> printk notifications for urandom pool initialization") from the random
> tree.
>
> I fixed it up (probably not properly - see below) and can carry the fix
> as necessary (no action is required).
As per Hannes' suggestion, the result should look like (see cover
letter in [1]):
if (r->entropy_total > 128) {
r->initialized = 1;
r->entropy_total = 0;
if (r == &nonblocking_pool) {
prandom_reseed_late();
pr_notice("random: %s pool is initialized\n",
r->name);
}
}
Cheers,
Daniel
[1] http://thread.gmane.org/gmane.linux.network/290303
^ permalink raw reply
* [PATCH net] neigh: Force garbage collection if an entry is deleted administratively
From: Steffen Klassert @ 2013-11-12 8:57 UTC (permalink / raw)
To: David Miller; +Cc: YOSHIFUJI Hideaki, netdev
Since git commit 2724680 ("neigh: Keep neighbour cache entries if number
of them is small enough."), we keep all neighbour cache entries if the
number is below a threshold. But if we now delete an entry administratively
and then try to replace this by a permanent one, we get -EEXIST because the
old entry ist still in the table (in NUD_FAILED state).
So lets force a garbage collect if we delete an entry administratively.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/core/neighbour.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 6072610..ec20880 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1659,6 +1659,8 @@ static int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh)
NEIGH_UPDATE_F_OVERRIDE |
NEIGH_UPDATE_F_ADMIN);
neigh_release(neigh);
+
+ neigh_forced_gc(tbl);
goto out;
}
read_unlock(&neigh_tbl_lock);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-12 8:59 UTC (permalink / raw)
To: Julian Anastasov
Cc: hannes, netdev, davem, David.Laight, jiri, vyasevich, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <alpine.LFD.2.03.1311091610090.1411@ssi.bg>
Le 09/11/2013 15:46, Julian Anastasov a écrit :
>
> Hello,
>
> On Sat, 9 Nov 2013, Nicolas Dichtel wrote:
>
>> This feature allows to a send packets with address source set to 0.0.0.0 even if
>> an ip address is available on another interface.
>>
>> It's useful for DHCP client, to allow them to use UDP sockets and be compliant
>> with the RFC2131, Section 4.1:
>>
>> 4.1 Constructing and sending DHCP messages
>> ...
>> DHCP messages broadcast by a client prior to that client obtaining
>> its IP address must have the source address field in the IP header
>> set to 0.
>>
>> Based on a previous work from
>> Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> ...
>
>> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
>> index 89909dd730dd..f58945187dbd 100644
>> --- a/net/ipv4/udp.c
>> +++ b/net/ipv4/udp.c
>
> ...
>
>> + if (up->src_any && sk->sk_bound_dev_if) {
>> + struct net_device *dev;
>> + struct in_device *in_dev;
>> +
>> + rcu_read_lock();
>> + dev = dev_get_by_index_rcu(sock_net(sk), sk->sk_bound_dev_if);
>> + in_dev = dev ? __in_dev_get_rcu(dev) : NULL;
>> + if (!inet_confirm_addr(sock_net(sk), in_dev, 0, 0,
>> + RT_SCOPE_HOST))
>
> I don't have an opinion about UDP_SRC_ANY, just some
> comments...
>
> Can a simple !in_dev->ifa_list check replace the
> !inet_confirm_addr call? Looking at __inet_insert_ifa()
> it seems only 0.0.0.0 does not add an ifa. Long ago
> adding 0.0.0.0 was a way to create in_dev for dev but
> now in_dev is created on device registration, i.e. even
> before addresses are added.
>
> For the first patch, may be it is not needed.
> We have two choices:
>
> 1. Do not change args and just fix comments. Of course,
> it is tricky to use this function by using scope instead
> of in_dev as a key for device-specific matching because
> such interface is confusing.
I hesitated to take this choice, but I think that keeping the
original behavior is better.
>
> 2. Add 'net' arg and use in_dev as explained in my
> previous email. Not sure if changing args of exported
> function is acceptable.
FWIK, it's not a problem.
Regards,
Nicolas
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-12 9:14 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Cong Wang, linux-arm-kernel, netdev, stable, edumazet
In-Reply-To: <20131112083633.GB10318@1wt.eu>
Hi,
Willy Tarreau <w@1wt.eu> writes:
>> That been said, even if the driver is most probably not the only one to
>> blame here (considering the result of bisect and current thread on
>> netdev), I never managed to get the performance I have on my ReadyNAS
>> Duo v2 (i.e. 108MB/s for a file served by an Apache) with a mvneta-based
>> platform (RN102, RN104 or RN2120). Understanding why is on an already a
>> long todo list.
>
> Yes I found that your original numbers were already quite low,
Tests for the rgression were done w/ scp, and were hence limited by the
crypto (16MB/s using arcfour128). But I also did some tests w/ a simple
wget for a file served by Apache *before* the regression and I never got
more than 60MB/s from what I recall. Can you beat that?
> so it is also possible that you have a different problem (eg: faulty
> switch or auto-negociation problem where the switch goes to half
> duplex because the neta does not advertise nway or whatever) that is
> emphasized by the latest changes
Tested w/ back to back connections to the NAS from various hosts and
through different switch. Never saturated the link.
> I can confirm that I got this message from you on netdev so it should be OK
> now.
Good. Thanks for the info.
a+
^ permalink raw reply
* Re: xen-netback regression in 3.10.18
From: Ian Campbell @ 2013-11-12 9:27 UTC (permalink / raw)
To: David Miller; +Cc: david.vrabel, netdev, stable, paul.durrant, wei.liu2
In-Reply-To: <20131109.155705.1091114498622318881.davem@davemloft.net>
On Sat, 2013-11-09 at 15:57 -0500, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 7 Nov 2013 12:15:33 +0000
>
> > 3.10.18 included 279f438e36c0 (xen-netback: Don't destroy the netdev
> > until the vif is shut down) but this has a regression that was fixed by
> > dc62ccaccfb1 (xen-netback: transition to CLOSED when removing a VIF)
> >
> > dc62ccaccfb1 depends on ea732dff5cfa (xen-netback: Handle backend state
> > transitions in a more robust way) which is also a bug fix for certain
> > Windows frontend drivers and is thus also a stable candidate.
> >
> > Dave can you ensure these two commits are tagged for the next 3.10.y
> > stable release?
> >
> > ea732dff5cfa10789007bf4a5b935388a0bb2a8f
> > dc62ccaccfb139d9b04bbc5a2688a4402adbfab3
>
> Ian already asked me to do this,
Sorry, bit of a race condition after Dave V and I spoke. Seems like I
won by 3s ;-)
> and the commits are necessary for 3.11 -stable as well.
>
> They've been queued up.
Thanks.
Ian.
^ permalink raw reply
* RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: David Laight @ 2013-11-12 9:43 UTC (permalink / raw)
To: Alan Stern; +Cc: Sarah Sharp, netdev, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1311111525480.17105-100000@netrider.rowland.org>
> You're right. I do wish the spec had been written more clearly.
I've read a lot of hardware specs in my time ...
> > Reading it all again makes me think that a LINK trb is only
> > allowed on the burst boundary (which might be 16k bytes).
> > The only real way to implement that is to ensure that TD never
> > contain LINK TRB.
>
> That's one way to do it. Or you could allow a Link TRB at an
> intermediate MBP boundary.
If all the fragments are larger than the MBP (assume 16k) then
that would be relatively easy. However that is very dependant
on the source of the data. It might be true for disk data, but
is unlikely to be true for ethernet data.
For bulk data the link TRB can be forced at a packet boundary
by splitting the TD up - the receiving end won't know the difference.
> It comes down to a question of how often you want the controller to
> issue an interrupt. If a ring segment is 4 KB (one page), then it can
> hold 256 TRBs. With scatter-gather transfers, each SG element
> typically refers to something like a 2-page buffer (depends on how
> fragmented the memory is). Therefore a ring segment will describe
> somewhere around 512 pages of data, i.e., something like 2 MB. Since
> SuperSpeed is 500 MB/s, you'd end up getting in the vicinity of 250
> interrupts every second just because of ring segment crossings.
250 interrupts/sec is noise. Send/receive 13000 ethernet packets/sec
and then look at the interrupt rate!
There is no necessity for taking an interrupt from every link segment.
OTOH an interrupt is requested for every bulk TD.
I'm sending ethernet data (with TSO) and each TD is just under 64k
mostly made up of 3 or 4 fragments.
The receive side is interrupting for every receive packet.
> Using larger ring segments would help.
The current ring segments contain 64 entries, a strange choice
since they are created with 2 segments.
(The ring expansion code soon doubles that for my ethernet traffic.)
I would change the code to use a single segment (for coding simplicity)
and queue bulk URB when there isn't enough ring space.
URB with too many fragments could either be rejected, sent in sections,
or partially linearised (and probably still sent in sections).
David
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Willy Tarreau @ 2013-11-12 10:01 UTC (permalink / raw)
To: Arnaud Ebalard; +Cc: Cong Wang, edumazet, linux-arm-kernel, stable, netdev
In-Reply-To: <87a9hagex1.fsf@natisbad.org>
Hi Arnaud,
On Tue, Nov 12, 2013 at 10:14:34AM +0100, Arnaud Ebalard wrote:
> Tests for the rgression were done w/ scp, and were hence limited by the
> crypto (16MB/s using arcfour128). But I also did some tests w/ a simple
> wget for a file served by Apache *before* the regression and I never got
> more than 60MB/s from what I recall. Can you beat that?
Yes, I finally picked my mirabox out of my bag for a quick test. It boots
off 3.10.0-rc7 and I totally saturate one port (stable 988 Mbps) with even
a single TCP stream.
With two systems, one directly connected (dockstar) and the other one via
a switch, I get 2*650 Mbps (a single TCP stream is enough on each).
I'll have to re-run some tests using a more up to date kernel, but that
will probably not be today though.
Regards,
Willy
^ permalink raw reply
* [PATCH net 1/2] tuntap: limit head length of skb allocated
From: Jason Wang @ 2013-11-12 10:02 UTC (permalink / raw)
To: davem, netdev, linux-kernel, mst, stefanha; +Cc: Jason Wang
We currently use hdr_len as a hint of head length which is advertised by
guest. But when guest advertise a very big value, it can lead to an 64K+
allocating of kmalloc() which has a very high possibility of failure when host
memory is fragmented or under heavy stress. The huge hdr_len also reduce the
effect of zerocopy or even disable if a gso skb is linearized in guest.
To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
head, which guarantees an order 0 allocation each time.
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch was needed for stable.
---
drivers/net/tun.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7cb105c..5537b65 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -954,6 +954,11 @@ static struct sk_buff *tun_alloc_skb(struct tun_file *tfile,
struct sock *sk = tfile->socket.sk;
struct sk_buff *skb;
int err;
+ int good_linear = SKB_MAX_HEAD(prepad);
+
+ /* Don't use huge linear part */
+ if (linear > good_linear)
+ linear = good_linear;
/* Under a page? Don't bother with paged skb. */
if (prepad + len < PAGE_SIZE || !linear)
--
1.8.3.2
^ permalink raw reply related
* [PATCH net 2/2] macvtap: limit head length of skb allocated
From: Jason Wang @ 2013-11-12 10:02 UTC (permalink / raw)
To: davem, netdev, linux-kernel, mst, stefanha; +Cc: Jason Wang
In-Reply-To: <1384250577-20330-1-git-send-email-jasowang@redhat.com>
We currently use hdr_len as a hint of head length which is advertised by
guest. But when guest advertise a very big value, it can lead to an 64K+
allocating of kmalloc() which has a very high possibility of failure when host
memory is fragmented or under heavy stress. The huge hdr_len also reduce the
effect of zerocopy or even disable if a gso skb is linearized in guest.
To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
head, which guarantees an order 0 allocation each time.
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch was needed for stable.
---
drivers/net/macvtap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 9dccb1e..7ee6f9d 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -523,6 +523,11 @@ static inline struct sk_buff *macvtap_alloc_skb(struct sock *sk, size_t prepad,
int noblock, int *err)
{
struct sk_buff *skb;
+ int good_linear = SKB_MAX_HEAD(prepad);
+
+ /* Don't use huge linear part */
+ if (linear > good_linear)
+ linear = good_linear;
/* Under a page? Don't bother with paged skb. */
if (prepad + len < PAGE_SIZE || !linear)
--
1.8.3.2
^ permalink raw reply related
* RE: Handle new frag_list of frags GRO packets
From: David Laight @ 2013-11-12 10:12 UTC (permalink / raw)
To: Herbert Xu, Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131111185207.GA12277@gondor.apana.org.au>
> Recently GRO started generating packets with frag_lists of frags.
> This was not handled by GSO, thus leading to a crash.
Is the build_dma_sg() code in net/usb/usbnet.c correct?
It creates a 'struct scatterlist' array for all the fragments
in and skb.
I'm not at clear of exactly how skb get put together.
David
^ permalink raw reply
* Re: bridge not getting ip since 3.11.5 and 3.4.66
From: Mark Trompell @ 2013-11-12 10:57 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux-Kernel, netdev
In-Reply-To: <CAEPa5y=tgdGpDMBGY0ijyWSgQ0m5SZW8EMP072OF=sZZUjqN1g@mail.gmail.com>
On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote:
> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote:
>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
>>> What information would be helpful and required to find out what's going wrong.
>>
>> CC netdev
>>
>> First thing would be to provide the network scheme. Do you use vlans?
>> Which network
>> cards/drivers are you using? Do you use some kind of virtualization?
>> Is bonding involved?
>>
> Actually this is my desktop machine using kvm for a virtual machine
> that uses eth0 which is connected to the bridge
> which is used as interface for the host.
>
> $ ip addr
> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
> master br0 qlen 1000
> ...
> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
> ...
>
> Anything else?
Okay more about my hardware and configuration:
from lspci:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
Connection (rev 04)
/etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
ONBOOT=yes
MACADDR=00:19:99:ac:b3:24
TYPE=Bridge
BOOTPROTO=dhcp
STP=on
NM_CONTROLLED=no
DELAY=0
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:19:99:cd:a5:e6
#BOOTPROTO=dhcp
ONBOOT=yes
BRIDGE=br0
TYPE=Ethernet
NM_CONTROLLED=no
> Greetings
> Mark
^ permalink raw reply
* Re: IPv6: Blackhole route support partial ?
From: Kamala R @ 2013-11-12 11:09 UTC (permalink / raw)
To: Kamala R, davem, linux-kernel, netdev
In-Reply-To: <20131111203954.GB3043@order.stressinduktion.org>
Hi,
Sure, here it is.
--- linux-3.12/net/ipv6/route.c.orig 2013-11-12 16:23:46.000000000 +0530
+++ linux-3.12/net/ipv6/route.c 2013-11-12 16:30:51.000000000 +0530
@@ -1570,9 +1570,13 @@ int ip6_route_add(struct fib6_config *cf
switch (cfg->fc_type) {
case RTN_BLACKHOLE:
rt->dst.error = -EINVAL;
+ rt->dst.input = dst_discard;
+ rt->dst.discard = dst_discard;
break;
case RTN_PROHIBIT:
rt->dst.error = -EACCES;
+ rt->dst.input = ip6_pkt_prohibit;
+ rt->dst.output = ip6_pkt_prohibit_out;
break;
case RTN_THROW:
rt->dst.error = -EAGAIN;
Is this ok ?
Regards,
Kamala
On Tue, Nov 12, 2013 at 2:09 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hello!
>
> On Mon, Nov 11, 2013 at 07:25:14PM +0530, Kamala R wrote:
>> On adding IPv6 blackhole routes, ICMP unreachable messages are being
>> sent back to source. According to the definition, packets destined to
>> a blackhole address must be dropped silently.
>
> Yes, this is a bug.
>
>> I applied the patch submitted to the 3.7 kernel that indicates that it
>> supports blackhole and prohibit routes correctly. However, the patch
>> only sets the error code and route type correctly, so the show command
>> displays the appropriate output.
>>
>>
>> It seems to me that the input and output function pointers of the dst
>> variable, which determine packet processing, need to be set to
>> dst_discard. This would enable correct behaviour for blackhole routes.
>> Am I on the right path here ?
>
> I think you are. ip6_pkt_discard is not the correct input/output
> function for blackhole routes. In ip6_route_add simply set up the
> function pointers in the switch instead to just initializing them to
> ip6_pkt_discard. dst_discard is fine. Looks like prohibit rules are not
> handled correctly either. They should go to ip6_pkt_prohibit. (Just look at
> how the templates are initialized.)
>
> Could you cook a patch?
>
> Thanks,
>
> Hannes
>
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Karl Beldan @ 2013-11-12 11:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Hannes Frederic Sowa, Theodore Ts'o, Daniel Borkmann,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
shemminger-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
fweimer-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
Eric Dumazet, linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1384245375.14301.1.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On Tue, Nov 12, 2013 at 09:36:15AM +0100, Johannes Berg wrote:
> On Tue, 2013-11-12 at 01:37 +0100, Karl Beldan wrote:
>
> > > > 1) I'm pretty sure, but it would be good to get netdev confirmation,
> > > > that the call to get_random_bytes() in
> > > > net/mac80211/rc80211_minstrel.c's init_sample_table() can be replaced
> > > > by calls to prandom_u32().
> > >
> > > Would make sense. I added wireless-devel to confirm.
> > >
> > > [...]
> > > [ 0.673260] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.674024] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.675012] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.676032] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.677020] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.678011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [ 0.679011] random: rc80211_minstrel_ht_init+0x47/0xaa get_random_bytes called with 3 bits of entropy available
> > > [...]
> > >
> > > In total 80 calls to get_random_bytes.
> > >
> >
> > It is already 8 times what rc80211_minstrel_ht_init uses.
> > If you could apply on top of:
> > http://marc.info/?l=linux-wireless&m=138392850030987&w=2
> > although Johannes has not yet agreed/applied this.
>
> I'll take the patch, I just wanted a more useful commit log :)
>
The commit log still feels very right to me, but I don't want you to go
grumpy ;) and will reword the log - Hannes, have you staged replacing
get_random_bytes with prandom_u32 already or can I do it in a reworded
v2 for minstrel ?
> I guess if really needed I'll write that myself :(
>
> Anyway, I can't comment on prandom_u32(), but it doesn't really have to
> be all that random here, it's just sample tables for what order to try
> things in. Technically that could even be static with some per-device
> pertubation, I guess?
>
The LFSR is way enough for minstrel, as for moving from prandom to
handcrafted sample table, this will be another discussion I guess.
Karl
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* FW: [REGRESSION] be2net: not work in 3.12
From: Sathya Perla @ 2013-11-12 11:13 UTC (permalink / raw)
To: Guo Chao (yan@linux.vnet.ibm.com); +Cc: netdev@vger.kernel.org
In-Reply-To: <20131112010807.GA6044@yanx>
> -----Original Message-----
> From: Guo Chao [mailto:yan@linux.vnet.ibm.com]
>
> Hello:
>
> After commit 92bf14ab(be2net: refactor be_get_resources() code),
> be2net is not working on a PowerPC machine.
>
> [ 72.653560] be2net 0001:01:00.0: Could not use PCIe error reporting
> [ 73.933727] be2net 0001:01:00.0: Max: txqs 8, rxqs 8, rss 7, eqs 0,
> vfs 20
> [ 73.933794] be2net 0001:01:00.0: Max: uc-macs 64, mc-macs 64, vlans 8
> [ 73.933875] be2net 0001:01:00.0: MSIx enable failed
> [ 73.973728] be2net 0001:01:00.0: created 0 TX queue(s)
> [ 73.973795] be2net 0001:01:00.0: created -1 RSS queue(s) and 1
> default RX queue
> [ 74.013735] be2net 0001:01:00.0: opcode 12-1 failed:status 3-11
> [ 74.013811] be2net 0001:01:00.0: queue_setup failed
> [ 74.013949] be2net 0001:01:00.0: Emulex OneConnect(Lancer)
> initialization failed
> [ 74.014018] be2net: probe of 0001:01:00.0 failed with error -1
>
> This change makes it work:
>
> --- a/drivers/net/ethernet/emulex/benet/be_cmds.c
> +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
> @@ -3187,6 +3187,8 @@ static void be_copy_nic_desc(struct be_resources
> *res,
> res->max_rss_qs = le16_to_cpu(desc->rssq_count);
> res->max_rx_qs = le16_to_cpu(desc->rq_count);
> res->max_evt_qs = le16_to_cpu(desc->eq_count);
> + if (res->max_evt_qs == 0)
> + res->max_evt_qs = 8;
> /* Clear flags that driver is not interested in */
> res->if_cap_flags = le32_to_cpu(desc->cap_flags) &
> BE_IF_CAP_FLAGS_WANT;
>
> Looks like firmware returns corrupted value. Can you fall back all
> limits to static ones if detected this?
Could you report the old (working) FW version and the new (broken) FW version.
This clearly seems like a FW bug and I think it should be fixed in FW rather than
the driver.
thanks,
-Sathya
^ permalink raw reply
* Re: [PATCH net 1/2] tuntap: limit head length of skb allocated
From: Michael S. Tsirkin @ 2013-11-12 11:20 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, stefanha
In-Reply-To: <1384250577-20330-1-git-send-email-jasowang@redhat.com>
On Tue, Nov 12, 2013 at 06:02:56PM +0800, Jason Wang wrote:
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> The patch was needed for stable.
> ---
> drivers/net/tun.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 7cb105c..5537b65 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -954,6 +954,11 @@ static struct sk_buff *tun_alloc_skb(struct tun_file *tfile,
> struct sock *sk = tfile->socket.sk;
> struct sk_buff *skb;
> int err;
> + int good_linear = SKB_MAX_HEAD(prepad);
> +
> + /* Don't use huge linear part */
> + if (linear > good_linear)
> + linear = good_linear;
>
> /* Under a page? Don't bother with paged skb. */
> if (prepad + len < PAGE_SIZE || !linear)
> --
> 1.8.3.2
>
> --
> 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
* [PATCH net] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-12 11:25 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
I met a Bug when I add ip target with the wrong ip address:
echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
the wrong ip address will transfor to 245.245.245.244 and add
to the ip target success, it is uncorrect, so I add checks to avoid
adding wrong address.
The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
the next check and will not add to ip target.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 4838a97..5b7bf37 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -612,7 +612,7 @@ static ssize_t bonding_store_arp_targets(struct device *d,
return restart_syscall();
targets = bond->params.arp_targets;
- newtarget = in_aton(buf + 1);
+ in4_pton(buf + 1, strlen(buf) - 1, (u8 *)&newtarget, -1, NULL);
/* look for adds */
if (buf[0] == '+') {
if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH net] bonding: add ip checks when store ip target
From: Veaceslav Falico @ 2013-11-12 11:36 UTC (permalink / raw)
To: Ding Tianhong
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <52821024.6050607@huawei.com>
On Tue, Nov 12, 2013 at 07:25:24PM +0800, Ding Tianhong wrote:
>I met a Bug when I add ip target with the wrong ip address:
>
>echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
>
>the wrong ip address will transfor to 245.245.245.244 and add
>to the ip target success, it is uncorrect, so I add checks to avoid
>adding wrong address.
>
>The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
>the next check and will not add to ip target.
>
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Your mail client, apparently, transformed tabs into spaces, so the patch
doesn't apply.
>
>diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>index 4838a97..5b7bf37 100644
>--- a/drivers/net/bonding/bond_sysfs.c
>+++ b/drivers/net/bonding/bond_sysfs.c
>@@ -612,7 +612,7 @@ static ssize_t bonding_store_arp_targets(struct device *d,
> return restart_syscall();
>
> targets = bond->params.arp_targets;
>- newtarget = in_aton(buf + 1);
>+ in4_pton(buf + 1, strlen(buf) - 1, (u8 *)&newtarget, -1, NULL);
> /* look for adds */
> if (buf[0] == '+') {
> if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
>--
>1.8.2.1
>
>
^ permalink raw reply
* Re: [PATCH net 2/2] macvtap: limit head length of skb allocated
From: Michael S. Tsirkin @ 2013-11-12 11:20 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, stefanha
In-Reply-To: <1384250577-20330-2-git-send-email-jasowang@redhat.com>
On Tue, Nov 12, 2013 at 06:02:57PM +0800, Jason Wang wrote:
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> The patch was needed for stable.
> ---
> drivers/net/macvtap.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 9dccb1e..7ee6f9d 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -523,6 +523,11 @@ static inline struct sk_buff *macvtap_alloc_skb(struct sock *sk, size_t prepad,
> int noblock, int *err)
> {
> struct sk_buff *skb;
> + int good_linear = SKB_MAX_HEAD(prepad);
> +
> + /* Don't use huge linear part */
> + if (linear > good_linear)
> + linear = good_linear;
>
> /* Under a page? Don't bother with paged skb. */
> if (prepad + len < PAGE_SIZE || !linear)
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Theodore Ts'o @ 2013-11-12 11:53 UTC (permalink / raw)
To: Daniel Borkmann, davem, shemminger, fweimer, netdev, Eric Dumazet,
linux-wireless
In-Reply-To: <20131112000307.GB14929@order.stressinduktion.org>
On Tue, Nov 12, 2013 at 01:03:07AM +0100, Hannes Frederic Sowa wrote:
>
> We are much too early to enumerate hardware, so it would be hard to
> integrate something like mac addresses etc.
Stupid question --- is there a reason why the minstrel code is
initialized so early when it is compiled into the kernel? Can we
change it so it gets initialized later, after the devices are
initialized and we get the mac addresses?
> Btw. do you see problems regarding get_random_int on architectures without
> hardware offloading?
>
> We are initializing random_int_secret really late (after all the init
> calls) and I wonder if we should also use a two stage initialization
> there, so we have a more unpredictable MD5 hash at early boot.
Most of the users of get_random_int(), at least to date, have been for
things like ASLR. A quick audit shows only one device driver user
that might be impacted: drivers/net/wireless/cw1200/wsm.c.
It's not a bad idea to do a two stage init just in case
get_random_int() gets used by other code --- although that brings up
something that I know is really needed, but which I haven't had time
to try to address yet: we really need to document all of the various
interfaces that various kernel routines can use to get random numbers,
and document what their performance and security characteristics are.
We have probably have a lot of code where the authors didn't realize
that some other interface would be a better match for their needs, or
the code is old enough that predates some of the newer interfaces.
- Ted
^ permalink raw reply
* Re: [PATCH net-next 3/6] random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized
From: Johannes Berg @ 2013-11-12 12:04 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Daniel Borkmann, davem, shemminger, fweimer, netdev, Eric Dumazet,
linux-wireless
In-Reply-To: <20131112115350.GA14077@thunk.org>
On Tue, 2013-11-12 at 06:53 -0500, Theodore Ts'o wrote:
> On Tue, Nov 12, 2013 at 01:03:07AM +0100, Hannes Frederic Sowa wrote:
> >
> > We are much too early to enumerate hardware, so it would be hard to
> > integrate something like mac addresses etc.
>
> Stupid question --- is there a reason why the minstrel code is
> initialized so early when it is compiled into the kernel? Can we
> change it so it gets initialized later, after the devices are
> initialized and we get the mac addresses?
It's a bit of a chicken & egg problem - the minstrel rate control is
needed for the wireless device to get registered - if anything were to
fail there then we wouldn't want to register.
johannes
^ permalink raw reply
* RE: [PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Shaohui Xie @ 2013-11-12 12:30 UTC (permalink / raw)
To: shh.xie@gmail.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Cc: Madalin-Cristian Bucur, Shruti Kanetkar, davem@davemloft.net,
jg1.han@samsung.com, f.fainelli@gmail.com, peppe.cavallaro@st.com,
michal.simek@xilinx.com, netdev@vger.kernel.org
In-Reply-To: <1384167864-2457-1-git-send-email-shh.xie@gmail.com>
Added more people and list.
Best Regards,
Shaohui Xie
> -----Original Message-----
> From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> Sent: Monday, November 11, 2013 7:04 PM
> To: linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Cc: Bucur Madalin-Cristian-B32716; Kanetkar Shruti-B44454; Xie Shaohui-B21989
> Subject: [PATCH 1/4] phylib: Add Clause 45 read/write functions
>
> From: Andy Fleming
>
> You need an extra parameter to read or write Clause 45 PHYs, so we need a
> different API with the extra parameter.
>
> Signed-off-by: Andy Fleming
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> include/linux/phy.h | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h index 64ab823..684925a
> 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev, u32
> regnum) }
>
> /**
> + * phy_read_mmd - Convenience function for reading a register
> + * from an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + *
> + * Same rules as for phy_read();
> + */
> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
> +u32 regnum) {
> + return mdiobus_read(phydev->bus, phydev->addr,
> + MII_ADDR_C45 | (devad << 16) | (regnum & 0xffff)); }
> +
> +/**
> * phy_write - Convenience function for writing a given PHY register
> * @phydev: the phy_device struct
> * @regnum: register number to write
> @@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device
> *phydev)
> return phydev->is_internal;
> }
>
> +/**
> + * phy_write_mmd - Convenience function for writing a register
> + * on an MMD on a given PHY.
> + * @phydev: The phy_device struct
> + * @devad: The MMD to read from
> + * @regnum: The register on the MMD to read
> + * @val: value to write to @regnum
> + *
> + * Same rules as for phy_write();
> + */
> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
> + u32 regnum, u16 val)
> +{
> + regnum = MII_ADDR_C45 | ((devad & 0x1f) << 16) | (regnum & 0xffff);
> +
> + return mdiobus_write(phydev->bus, phydev->addr, regnum, val); }
> +
> struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
> bool is_c45, struct phy_c45_device_ids *c45_ids); struct
> phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
> --
> 1.8.4.1
^ 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