* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Paweł Staszewski @ 2010-12-09 12:40 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andrew Morton, netdev, Paul Mackerras, bugzilla-daemon,
bugme-daemon, pstaszewski
In-Reply-To: <4D000045.3040102@gmail.com>
W dniu 2010-12-08 23:01, Jarek Poplawski pisze:
> Paweł Staszewski wrote:
>> W dniu 2010-12-08 21:22, Andrew Morton pisze:
>>> (switched to email. Please respond via emailed reply-to-all, not via the
>>> bugzilla web interface).
>>>
>>> On Wed, 8 Dec 2010 20:14:45 GMT
>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>>>>
>>>> Summary: Kernel panic - not syncing: Fatal Exception
>>>> Product: Drivers
>>>> Version: 2.5
>>>> Kernel Version: 2.6.36.1
> Hi,
> Could you try to revert this patch?:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=55c95e738da85373965cb03b4f975d0fd559865b
>
After reverting this patch all is working
200 connects-disconnects and no kernel panic
I will make more session and test more.
Thanks
Pawel
> Jarek P.
> --
> 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: IPsecv6 tunnel mode fragmentation
From: Herbert Xu @ 2010-12-09 12:44 UTC (permalink / raw)
To: Joy Latten; +Cc: netdev, samudrala, rashmin, davem, dlstevens
In-Reply-To: <1291861242.11224.265.camel@faith.austin.ibm.com>
On Wed, Dec 08, 2010 at 08:20:42PM -0600, Joy Latten wrote:
>
> We did attempt to debug in kernel to see whether the pkt-too-big
> was being discarded... from what we saw, it did not seem to be.
> Also, an "ip -6 r l c" on TARGET showed the adjusted mtu for the route
> to HOST, which the pkt-too-big was for. tunnel's mtu is untouched.
Oh I see what you're saying. Sorry I misunderstood the issue
earlier.
> Thus why I reached my original conclusion, that perhaps
> esp/ah disregard inner hdr mtu since does not fragment.
> Thus inner pkt will be too big when it reaches link for
> inner/original pkt to be sent on.
Indeed we don't have any fragmentation capbility at all on the
IPsec output path inside the tunnel. For IPv4 this isn't an issue
because the other end can perform fragmentation. This is clearly
not an option with IPv6.
I'll look into this.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] kptr_restrict for hiding kernel pointers from unprivileged users
From: Dan Rosenberg @ 2010-12-09 12:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, linux-security-module, netdev
In-Reply-To: <1291895472.2965.4.camel@Dan>
> > So caller can not block BH ?
> >
> > This seems wrong to me, please consider :
> >
> > normal process context :
> >
> > spin_lock_bh() ...
> >
> > for (...)
> > {xxx}printf( ... "%pK" ...)
> >
> > spin_unlock_bh();
> >
>
> I will think about this and address it.
Would you be happier if I omitted the in_interrupt() check entirely?
-Dan
^ permalink raw reply
* Re: [PATCH 0/3] xfrm: ESP Traffic Flow Confidentiality padding (v3)
From: Herbert Xu @ 2010-12-09 12:47 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev
In-Reply-To: <1291819071-17538-1-git-send-email-martin@strongswan.org>
On Wed, Dec 08, 2010 at 03:37:48PM +0100, Martin Willi wrote:
> The following patchset adds Traffic Flow Confidentiality padding. The
> first patch introduces a new Netlink XFRM attribute to configure TFC via
> userspace. Patch two and three implement the padding logic in IPv4 and
> IPv6 ESP. Padding is always done using the RFC4303 format an is clamped
> to the PMTU.
>
> Changes from v2:
> - Remove unused flag field in attribute, use a plain u32 as attribute payload
> - Reject installation of TFC padding on non-tunnel SAs
Looks good to me. Thanks for the hard work Martin!
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] kptr_restrict for hiding kernel pointers from unprivileged users
From: Eric Dumazet @ 2010-12-09 13:30 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: linux-kernel, linux-security-module, netdev
In-Reply-To: <1291898801.2965.6.camel@Dan>
Le jeudi 09 décembre 2010 à 07:46 -0500, Dan Rosenberg a écrit :
> > > So caller can not block BH ?
> > >
> > > This seems wrong to me, please consider :
> > >
> > > normal process context :
> > >
> > > spin_lock_bh() ...
> > >
> > > for (...)
> > > {xxx}printf( ... "%pK" ...)
> > >
> > > spin_unlock_bh();
> > >
> >
> > I will think about this and address it.
>
> Would you be happier if I omitted the in_interrupt() check entirely?
>
Well, it seems difficult to make a check here, its a generic function
that happens to be used from different contexts.
Even using in_irq() might be a problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/5] HID: roccat: Achieve userspace notification on sysfs attribute creation
From: Jiri Kosina @ 2010-12-09 13:30 UTC (permalink / raw)
To: Stefan Achatz
Cc: Randy Dunlap, Greg Kroah-Hartman, linux-doc, linux-kernel,
linux-input, netdev
In-Reply-To: <1290801444.18750.161.camel@neuromancer>
On Fri, 26 Nov 2010, Stefan Achatz wrote:
> Adding sysfs attributes to an already created device raises no userland
> notification.
>
> Instead of fiddling around in the depths of busses and devices I reuse the
> event char device (module hid-roccat). This device gets now created with
> a hardware specific class that contains the device attributes.
Hi Stefan,
I have applied the series, and removed the #pragma pack ugliness. Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO_* attr
From: Stefan Berger @ 2010-12-09 13:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <20101208042925.16856.89232.stgit@savbu-pc100.cisco.com>
Christian Benvenuti <benve <at> cisco.com> writes:
>
> The following series add the new IFLA_PORT_PROTO_* nested
> protocol attributes to rtnetlink and it updates the enic
> driver to support them.
>
> 01/2 - Add new protocol nested IFLA_PORT_PROTO_* attrs
> 02/2 - Update enic driver to support new IFLA_PORT_PROTO_* attrs
>
> Signed-off-by: Christian Benvenuti <benve <at> cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu <at> cisco.com>
> Signed-off-by: David Wang <dwang2 <at> cisco.com>
>
[...]
>
> When the protocol nested attributes IFLA_PORT_PROTO_* will be
> populated with new sub-attributes (like the CLUSTER_UUID we would like
> to add), the user space clients will have to adapt to the new
> attribute scheme if they want to be able to see/receive the new
> attributes (like CLUSTER_UUID).
>
I don't have a problem with these changes. Just on the libvirt level it's going
to be a lot more messy. We'll need another level of #ifdef's for when these new
attributes became available. In case they are there we should not just create
the netlink messages with the new attributes but first independently probe for
802.1Qbg and 802.1Qbh for whether lldpad or the kernel respectively saw the same
level of if_link.h include and/or support the new attributes and fall back to
using the old ones in case the probing failed. That way we can support
multi-boot installations with kernels before and after these changes or an
lldpad that doesn't support the new attributes and still give the user the
experience that the starting of the VM 'works' as before (the new kernel was
installed). I am assuming that it worked with 802.1Qbh before even though you
didn't have the CLUSTER_UUID support... Now that will probably add quite a bit
to the complexity of the code and the testing. I hope you'll submit a patch like
that to libvirt mailing list.
Stefan
> Thanks
> /Christian
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH net-2.6] net/ipv6/udp.c: fix typo in flush_stack()
From: Jiri Pirko @ 2010-12-09 13:40 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
skb1 should be passed as parameter to sk_rcvqueues_full() here.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 91def93..d2b268e 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -602,7 +602,7 @@ static void flush_stack(struct sock **stack, unsigned int count,
sk = stack[i];
if (skb1) {
- if (sk_rcvqueues_full(sk, skb)) {
+ if (sk_rcvqueues_full(sk, skb1)) {
kfree_skb(skb1);
goto drop;
}
^ permalink raw reply related
* Aw: Re: [PATCH 0/5] HID: roccat: Achieve userspace notification on sysfs attribute creation
From: Stefan Achatz @ 2010-12-09 13:44 UTC (permalink / raw)
To: jkosina, erazor_de
Cc: rdunlap, gregkh, linux-doc, linux-kernel, linux-input, netdev
In-Reply-To: <alpine.LNX.2.00.1012091430130.508@pobox.suse.cz>
----- Original Nachricht ----
Von: Jiri Kosina <jkosina@suse.cz>
An: Stefan Achatz <erazor_de@users.sourceforge.net>
Datum: 09.12.2010 14:30
Betreff: Re: [PATCH 0/5] HID: roccat: Achieve userspace notification on sysfs
attribute creation
> On Fri, 26 Nov 2010, Stefan Achatz wrote:
>
> > Adding sysfs attributes to an already created device raises no userland
> > notification.
> >
> > Instead of fiddling around in the depths of busses and devices I reuse
> the
> > event char device (module hid-roccat). This device gets now created with
> > a hardware specific class that contains the device attributes.
>
> Hi Stefan,
>
> I have applied the series, and removed the #pragma pack ugliness. Thanks,
Hello Jiri,
Using my patch replacing the #pragma pack with the __packed macro would have saved you some time:
https://lkml.org/lkml/2010/11/27/14
Just for the future: Whats better using the verbose version __attribute__ ((__packed__)) or the macro
__packed as I did?
Thanks, Stefan
^ permalink raw reply
* Re: [PATCH net-2.6] net/ipv6/udp.c: fix typo in flush_stack()
From: Eric Dumazet @ 2010-12-09 13:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <20101209134029.GB2820@psychotron.brq.redhat.com>
Le jeudi 09 décembre 2010 à 14:40 +0100, Jiri Pirko a écrit :
> skb1 should be passed as parameter to sk_rcvqueues_full() here.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 91def93..d2b268e 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -602,7 +602,7 @@ static void flush_stack(struct sock **stack, unsigned int count,
>
> sk = stack[i];
> if (skb1) {
> - if (sk_rcvqueues_full(sk, skb)) {
> + if (sk_rcvqueues_full(sk, skb1)) {
> kfree_skb(skb1);
> goto drop;
> }
net-2.6 ? Its the same truesize anyway...
So it's not a bug, but a cosmetic change.
(I am ok with it, but for net-next-2.6)
/*
* Take into account size of receive queue and backlog queue
*/
static inline bool sk_rcvqueues_full(const struct sock *sk, const struct sk_buff *skb)
{
unsigned int qsize = sk->sk_backlog.len + atomic_read(&sk->sk_rmem_alloc);
return qsize + skb->truesize > sk->sk_rcvbuf;
}
^ permalink raw reply
* Re: Aw: Re: [PATCH 0/5] HID: roccat: Achieve userspace notification on sysfs attribute creation
From: Jiri Kosina @ 2010-12-09 13:52 UTC (permalink / raw)
To: Stefan Achatz
Cc: rdunlap, gregkh, linux-doc, linux-kernel, linux-input, netdev
In-Reply-To: <2069123096.22885.1291902246397.JavaMail.ngmail@webmail07.arcor-online.net>
On Thu, 9 Dec 2010, Stefan Achatz wrote:
> > I have applied the series, and removed the #pragma pack ugliness. Thanks,
>
> Hello Jiri,
> Using my patch replacing the #pragma pack with the __packed macro would
> have saved you some time: https://lkml.org/lkml/2010/11/27/14
Ah, missed that. Never mind.
> Just for the future: Whats better using the verbose version
> __attribute__ ((__packed__)) or the macro __packed as I did?
I don't think I really care deeply here.
For some rationale why these shortcuts exist, please see commit
82ddcb0405704.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* [PATCH] bridge: Fix return value of br_multicast_add_group()
From: Tobias Klauser @ 2010-12-09 14:02 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge; +Cc: netdev
If br_multicast_new_group returns NULL, we would return 0 (no error) to
the caller, which is not what we want. Instead we should return -ENOMEM
in this case.
Also replace IS_ERR(x) || !x by IS_ERR_OR_NULL(x)
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/bridge/br_multicast.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 326e599..d4e1e81 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -713,8 +713,11 @@ static int br_multicast_add_group(struct net_bridge *br,
mp = br_multicast_new_group(br, port, group);
err = PTR_ERR(mp);
- if (unlikely(IS_ERR(mp) || !mp))
+ if (IS_ERR_OR_NULL(mp)) {
+ if (!mp)
+ err = -ENOMEM;
goto err;
+ }
if (!port) {
hlist_add_head(&mp->mglist, &br->mglist);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] netfilter: don't need to initialize instance_table
From: Jan Engelhardt @ 2010-12-09 14:03 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <1291889421-10794-1-git-send-email-xiaosuo@gmail.com>
On Thursday 2010-12-09 11:10, Changli Gao wrote:
>Since instance_table is a static array, and has been zeroed already, we
>don't need to take CPU cycles to initialize it.
>
>Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>---
> net/netfilter/nfnetlink_queue.c | 3 ---
> 1 file changed, 3 deletions(-)
>diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
>index 68e67d1..9c80d6f 100644
>--- a/net/netfilter/nfnetlink_queue.c
>+++ b/net/netfilter/nfnetlink_queue.c
>@@ -893,9 +893,6 @@ static int __init nfnetlink_queue_init(void)
> {
> int i, status = -ENOMEM;
>
>- for (i = 0; i < INSTANCE_BUCKETS; i++)
>- INIT_HLIST_HEAD(&instance_table[i]);
>-
> netlink_register_notifier(&nfqnl_rtnl_notifier);
> status = nfnetlink_subsys_register(&nfqnl_subsys);
> if (status < 0) {
This is here for correctness and documentation. If the hlist
implementation changed, one would have a hard time figuring out the
callsites which then need to add the initialization back.
^ permalink raw reply
* Re: [PATCH] netfilter: don't need to initialize instance_table
From: Changli Gao @ 2010-12-09 14:27 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1012091501270.21049@obet.zrqbmnf.qr>
On Thu, Dec 9, 2010 at 10:03 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> This is here for correctness and documentation. If the hlist
> implementation changed, one would have a hard time figuring out the
> callsites which then need to add the initialization back.
>
I am quite sure there are other users rely on this assumption. So who
wants to change the macro INIT_HLIST_HEAD() has to review all the
code. It is a huge task, but can't be avoided.
For now, calling INIT_HLIST_HEAD() has no benefit, but wastes CPU
cycles and increases the image size.
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH net-2.6] net/ipv6/udp.c: fix typo in flush_stack()
From: Jiri Pirko @ 2010-12-09 14:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1291902488.4063.28.camel@edumazet-laptop>
Thu, Dec 09, 2010 at 02:48:08PM CET, eric.dumazet@gmail.com wrote:
>Le jeudi 09 décembre 2010 à 14:40 +0100, Jiri Pirko a écrit :
>> skb1 should be passed as parameter to sk_rcvqueues_full() here.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
>> index 91def93..d2b268e 100644
>> --- a/net/ipv6/udp.c
>> +++ b/net/ipv6/udp.c
>> @@ -602,7 +602,7 @@ static void flush_stack(struct sock **stack, unsigned int count,
>>
>> sk = stack[i];
>> if (skb1) {
>> - if (sk_rcvqueues_full(sk, skb)) {
>> + if (sk_rcvqueues_full(sk, skb1)) {
>> kfree_skb(skb1);
>> goto drop;
>> }
>
>net-2.6 ? Its the same truesize anyway...
I know it is.
>
>So it's not a bug, but a cosmetic change.
>(I am ok with it, but for net-next-2.6)
Anything you like.
>
>/*
> * Take into account size of receive queue and backlog queue
> */
>static inline bool sk_rcvqueues_full(const struct sock *sk, const struct sk_buff *skb)
>{
> unsigned int qsize = sk->sk_backlog.len + atomic_read(&sk->sk_rmem_alloc);
>
> return qsize + skb->truesize > sk->sk_rcvbuf;
>}
>
>
^ permalink raw reply
* [PATCH] inet6: Remove redundant unlikely()
From: Tobias Klauser @ 2010-12-09 14:37 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: netdev, kernel-janitors
IS_ERR() already implies unlikely(), so it can be omitted here.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/ipv6/af_inet6.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 54e8e42..059a3de 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -810,7 +810,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb, int features)
}
rcu_read_unlock();
- if (unlikely(IS_ERR(segs)))
+ if (IS_ERR(segs))
goto out;
for (skb = segs; skb; skb = skb->next) {
--
1.7.0.4
^ permalink raw reply related
* RE: Adding Support for SG,GSO,GRO
From: Govindarajan, Sriramakrishnan @ 2010-12-09 14:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1291891816.4063.5.camel@edumazet-laptop>
Hi Eric,
> > Internally the module supports scatter gather DMA(which is currently not
> > exercised) but there is no HW checksum support.
> >
> > To specifically implement GRO, GSO support would it be sufficient to add
> > SG support to the driver? Are there other means of increasing the
> throughput
> > and decreasing the CPU loading?
> >
> > Any pointers to reference implementation for adding SG/GRO/GSO support
> will be helpful.
>
> Adding GRO is pretty easy, since you already are NAPI.
>
> call
> napi_gro_receive(&adapter->napi, skb)
> instead of
> netif_receive_skb(skb);
>
[Sriram] I have tried this, but didn't see any improvement in performance.
For GRO and GSO, will adding SG capability alone suffice or the real gains
are realized only if HW checksum is also supported.
Can adding SG support alone yield any improvement?
Regards
Sriram
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Eilon Greenstein @ 2010-12-09 14:49 UTC (permalink / raw)
To: Matt Domsch
Cc: Dimitris Michailidis, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, narendra_k@dell.com,
jordan_hargrave@dell.com
In-Reply-To: <4CFD29BE.2060201@chelsio.com>
On Mon, 2010-12-06 at 10:21 -0800, Dimitris Michailidis wrote:
> Matt Domsch wrote:
...
> /sys/class/net/<ifname>/dev_id indicates the physical port <ifname> is
> associated with. At least a few drivers set up dev_id this way.
>
>
So we are on agreement? This can satisf all needs? If so, we will add
this scheme to the bnx2x as well.
Thanks,
Eilon
^ permalink raw reply
* [PATCH] stmmac: Remove redundant unlikely()
From: Tobias Klauser @ 2010-12-09 14:50 UTC (permalink / raw)
To: Giuseppe Cavallaro, netdev; +Cc: kernel-janitors
IS_ERR() already implies unlikely(), so it can be omitted here.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/stmmac/stmmac_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index c0dc785..20f803d 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -949,7 +949,7 @@ static int stmmac_sw_tso(struct stmmac_priv *priv, struct sk_buff *skb)
skb, skb->len);
segs = skb_gso_segment(skb, priv->dev->features & ~NETIF_F_TSO);
- if (unlikely(IS_ERR(segs)))
+ if (IS_ERR(segs))
goto sw_tso_end;
do {
--
1.7.0.4
^ permalink raw reply related
* Re: Adding Support for SG,GSO,GRO
From: Ben Hutchings @ 2010-12-09 15:02 UTC (permalink / raw)
To: Govindarajan, Sriramakrishnan; +Cc: netdev@vger.kernel.org
In-Reply-To: <FCCFB4CDC6E5564B9182F639FC356087035F21D9F9@dbde02.ent.ti.com>
On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
> Hi
> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
> well at 10/100Mbps loads. Now the same controller/driver is used for
> 1000Mbps
> mode as well, where the CPU gets saturated easily
>
> Internally the module supports scatter gather DMA(which is currently not
> exercised) but there is no HW checksum support.
>
> To specifically implement GRO, GSO support would it be sufficient to add
> SG support to the driver? Are there other means of increasing the throughput
> and decreasing the CPU loading?
[...]
On the RX side, the driver is allocating buffers and the stack doesn't
actually care whether you can do DMA scatter. However GRO depends on
hardware checksum validation.
On the TX side, NETIF_F_SG means that the stack may include data in the
skb by reference to arbitrary pages *even if their contents are still
being changed* (think sendfile()), which means it depends on hardware
checksum generation.
So you really have no choice - you must implement hardware checksum
offload if you want any of the others.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: ctnetlink loop
From: Holger Eitzenberger @ 2010-12-09 15:23 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, netdev, LKML, David S. Miller
In-Reply-To: <4D00B5CD.3050406@netfilter.org>
> Sorry, I finally found your email reporting this:
>
> > nfnetlink: avoid unbound loop on busy Netlink socket
Fair enough, thanks.
^ permalink raw reply
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Brian Haley @ 2010-12-09 15:28 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, netdev, Mahesh Kelkar, Lorenzo Colitti,
YOSHIFUJI Hideaki, Stephen Hemminger, stable
In-Reply-To: <m1mxofa8dg.fsf_-_@fess.ebiederm.org>
On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
> Finding the real bug is beyond me right now, but fixing the regression
> in disable_ipv6 is simple. We can just delete ::1 when we bring down
> the loopback interface, and it will be restored automatically when we
> bring the loopback interface back up.
Hi Eric,
This would work as well, same check, different way.
Signed-off-by: Brian Haley <brian.haley@hp.com>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 23cc8e1..5d16a9d 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2728,7 +2728,8 @@ static int addrconf_ifdown(struct net_device *dev, int how)
and not link-local, then retain it. */
if (!how &&
(ifa->flags&IFA_F_PERMANENT) &&
- !(ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
+ !(ipv6_addr_type(&ifa->addr) &
+ (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) {
list_move_tail(&ifa->if_list, &keep_list);
/* If not doing DAD on this address, just keep it. */
^ permalink raw reply related
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Stephen Hemminger @ 2010-12-09 16:27 UTC (permalink / raw)
To: Brian Haley
Cc: Eric W. Biederman, David Miller, netdev, Mahesh Kelkar,
Lorenzo Colitti, YOSHIFUJI Hideaki, stable
In-Reply-To: <4D00F58A.2050307@hp.com>
On Thu, 09 Dec 2010 10:28:10 -0500
Brian Haley <brian.haley@hp.com> wrote:
> On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
> > Finding the real bug is beyond me right now, but fixing the regression
> > in disable_ipv6 is simple. We can just delete ::1 when we bring down
> > the loopback interface, and it will be restored automatically when we
> > bring the loopback interface back up.
>
> Hi Eric,
>
> This would work as well, same check, different way.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 23cc8e1..5d16a9d 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2728,7 +2728,8 @@ static int addrconf_ifdown(struct net_device *dev, int how)
> and not link-local, then retain it. */
> if (!how &&
> (ifa->flags&IFA_F_PERMANENT) &&
> - !(ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
> + !(ipv6_addr_type(&ifa->addr) &
> + (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) {
> list_move_tail(&ifa->if_list, &keep_list);
>
> /* If not doing DAD on this address, just keep it. */
Checking the address type is incorrect. Any type of address can be applied to
loopback interface. If you look a couple lines there is a special case for
loopback which keeps the address.
> /* If just doing link down, and address is permanent
> and not link-local, then retain it. */
> if (!how &&
> (ifa->flags&IFA_F_PERMANENT) &&
> !(ipv6_addr_type(&ifa->addr) & IPV6_ADDR_LINKLOCAL)) {
> list_move_tail(&ifa->if_list, &keep_list);
>
> /* If not doing DAD on this address, just keep it. */
> if ((dev->flags&(IFF_NOARP|IFF_LOOPBACK)) ||
> idev->cnf.accept_dad <= 0 ||
> (ifa->flags & IFA_F_NODAD))
I think the problem is on coming back up, not on the down step.
^ permalink raw reply
* Re: [PATCH] bridge: Fix return value of br_multicast_add_group()
From: Stephen Hemminger @ 2010-12-09 16:29 UTC (permalink / raw)
To: Tobias Klauser; +Cc: David S. Miller, bridge, netdev
In-Reply-To: <1291903356-30618-1-git-send-email-tklauser@distanz.ch>
On Thu, 9 Dec 2010 15:02:36 +0100
Tobias Klauser <tklauser@distanz.ch> wrote:
> If br_multicast_new_group returns NULL, we would return 0 (no error) to
> the caller, which is not what we want. Instead we should return -ENOMEM
> in this case.
>
> Also replace IS_ERR(x) || !x by IS_ERR_OR_NULL(x)
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
> net/bridge/br_multicast.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 326e599..d4e1e81 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -713,8 +713,11 @@ static int br_multicast_add_group(struct net_bridge *br,
>
> mp = br_multicast_new_group(br, port, group);
> err = PTR_ERR(mp);
> - if (unlikely(IS_ERR(mp) || !mp))
> + if (IS_ERR_OR_NULL(mp)) {
> + if (!mp)
> + err = -ENOMEM;
> goto err;
> + }
>
> if (!port) {
> hlist_add_head(&mp->mglist, &br->mglist);
I would rather fix br_multicast_new_group so it never returns
NULL. Instead return PTR_ERR(-ENOMEM) on out of memory.
--
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Américo Wang @ 2010-12-09 16:47 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Florian Mickler, Ingo Molnar, Américo Wang, Dave Chinner,
Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20101208140822.GA18681@redhat.com>
On Wed, Dec 08, 2010 at 03:08:22PM +0100, Oleg Nesterov wrote:
>On 12/08, Oleg Nesterov wrote:
>>
>> On 12/08, Oleg Nesterov wrote:
>> >
>> > On 12/08, Florian Mickler wrote:
>> > >
>> > > [ ccing Ingo and Oleg ] as suggested
>> >
>> > Well. Of course I can't explain this bug. But, looking at this email
>> > I do not see amything strange in exit/schedule/etc.
>> >
>> > > > >> > > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
>> > > > >> > > >
>> > > > >> > > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
>> > > > >> > > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
>> > > > >> > > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
>> >
>> > That is. ip is a zombie.
>>
>> And. I do not know if this matters or not, but "the command 'ip link
>> set tap0 up' hanging as a zombie" does not look right.
>>
>> This was spawned by
>>
>> > >> > > > if [ -n "$1" ];then
>> > >> > > > /usr/bin/sudo /sbin/ip link set $1 up
>> > >> > > > sleep 0.5s
>> > >> > > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
>> > >> > > > exit 0
>> > >> > > > fi
>>
>> The command does not hang. But it forks the child with pid == 3012,
>> this child exits.
>
>Damn, sorry for noise, forgot to mention...
>
>The parent's trace (pid == 3011) can be more useful. Say, if it
>hangs in do_wait(), then the kernel is obviously wrong.
>
Yeah, there is no point that a zombie can trigger a BUG_ON in kenrel.
But it is still interesting to know why it becomes a zombie...
^ 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