* Re:...
From: Young Chang @ 2011-02-10 23:13 UTC (permalink / raw)
***********************
This message has been scanned by the InterScan for CSC SSM and found to be free of known security risks.
***********************
May I ask if you would be eligible to pursue a Business Proposal of $19.7m with me if you dont mind? Let me know if you are interested.
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses.
The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.
Wijeya Newspapers Ltd : 2010
^ permalink raw reply
* Re: [RFC PATCH 0/5] Cache PMTU/redirects in inetpeer
From: David Miller @ 2011-02-10 23:09 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110209.221249.112596220.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 09 Feb 2011 22:12:49 -0800 (PST)
> This is what I've been working on for the past several days.
Just FYI I've pushed just the infrastructure bits (patches 1, 2,
and 3) into net-next-2.6 since those have no side effects.
I won't push the other two until I can do some good testing on
them.
^ permalink raw reply
* Re: GRO/GSO hiding PMTU?
From: David Miller @ 2011-02-10 23:07 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel
In-Reply-To: <20110210.145555.39165146.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 10 Feb 2011 14:55:55 -0800 (PST)
> I suspect that the packet arrives on eth1, accumulates into GRO, and
> thus marked as GSO as well, then GSO/TSO on output to eth0 is
> re-segmenting things transparently, and we're not getting the ICMP
> frag-needed message and the packet drop because of the skb_is_gso()
> check in ip_forward().
>
> if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
> (ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df) {
> IP_INC_STATS(dev_net(rt->dst.dev), IPSTATS_MIB_FRAGFAILS);
> icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
> htonl(dst_mtu(&rt->dst)));
> goto drop;
> }
>
> So if that's what is happening, that's cute, but I think we need to
> fix this :-)
>
> Perhaps the check in ip_forward() should instead validate the gso_size
> in the skb_is_gso() case?
>
> That'd be a little tricky since gso_size is an MSS value whereas what
> we're checking against (skb->len) is the full packet size, headers and
> all.
Nevermind, I turned off gso/tso on eth0 (outgoing interface) and it still
happens.
I guess netfilter or something else is causing this.
^ permalink raw reply
* GRO/GSO hiding PMTU?
From: David Miller @ 2011-02-10 22:55 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel
I was trying to setup something simple to trigger PMTU to test my
PMTU patches, and the simplest (I thought) would be to simply down
the mtu of the internet facing side of my simple NAT box.
All I did was "ip link set eth0 mtu 1400", and try to send large
TCP sequences from inside.
To my surprise I saw no ICMP messages, on input to the NAT machine the
TCP packets had length 1448 and on output they had length 1348.
This NAT box has TG3 on both input and output, so supports GRO and
TSO. The kernel is 2.6.34-rc7 vintage :-)
I suspect that the packet arrives on eth1, accumulates into GRO, and
thus marked as GSO as well, then GSO/TSO on output to eth0 is
re-segmenting things transparently, and we're not getting the ICMP
frag-needed message and the packet drop because of the skb_is_gso()
check in ip_forward().
if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
(ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df) {
IP_INC_STATS(dev_net(rt->dst.dev), IPSTATS_MIB_FRAGFAILS);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(dst_mtu(&rt->dst)));
goto drop;
}
So if that's what is happening, that's cute, but I think we need to
fix this :-)
Perhaps the check in ip_forward() should instead validate the gso_size
in the skb_is_gso() case?
That'd be a little tricky since gso_size is an MSS value whereas what
we're checking against (skb->len) is the full packet size, headers and
all.
^ permalink raw reply
* Re: netfilter is not a filesystem
From: David Miller @ 2011-02-10 22:22 UTC (permalink / raw)
To: akpm; +Cc: netdev, linux-kernel
In-Reply-To: <20110210141119.56d789fc.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Thu, 10 Feb 2011 14:11:19 -0800
> On Thu, 10 Feb 2011 21:55:26 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=28862
>>
>> Summary: /proc/net/ip_conntrack: no space left on device
>> systematically
>
> This is why I'm forever nagging people to not just grab some errno
> because its name happens to sound similar to the error you just detected.
>
> Yes, it superficially seems nice and logical for netfilter to use
> ENOSPC when it runs out of space. But when that error code propagates
> up to the user, they see "no space left on device" and will then run
> "df" and wonder what the hell happened to their computer.
>
> The kernel makes this mistake a *lot*. EFBIG in the rtc drivers? Really?
We are in this conundrum because the granularity of errors which can
be indicated by errno signalling is very low.
And one way people handle this is to use all sorts of different types
of errno values to indicate the different cases.
Also, one can argue that it is erroneous for userspace to assume that
error codes are not context dependent. They most certainly are.
^ permalink raw reply
* netfilter is not a filesystem
From: Andrew Morton @ 2011-02-10 22:11 UTC (permalink / raw)
To: netdev, linux-kernel
In-Reply-To: <bug-28862-10286@https.bugzilla.kernel.org/>
On Thu, 10 Feb 2011 21:55:26 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=28862
>
> Summary: /proc/net/ip_conntrack: no space left on device
> systematically
This is why I'm forever nagging people to not just grab some errno
because its name happens to sound similar to the error you just detected.
Yes, it superficially seems nice and logical for netfilter to use
ENOSPC when it runs out of space. But when that error code propagates
up to the user, they see "no space left on device" and will then run
"df" and wonder what the hell happened to their computer.
The kernel makes this mistake a *lot*. EFBIG in the rtc drivers? Really?
^ permalink raw reply
* [PATCH 2/2] network: Allow af_packet to transmit +4 bytes for VLAN packets.
From: greearb @ 2011-02-10 21:59 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
In-Reply-To: <1297375149-18458-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This allows user-space to send a '1500' MTU VLAN packet on a
1500 MTU ethernet frame. The extra 4 bytes of a VLAN header is
not usually charged against the MTU when other parts of the
network stack is transmitting vlans...
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 91cb1d7... ef7f378... M net/packet/af_packet.c
net/packet/af_packet.c | 31 +++++++++++++++++++++++++++++--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 91cb1d7..ef7f378 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -466,7 +466,7 @@ retry:
*/
err = -EMSGSIZE;
- if (len > dev->mtu + dev->hard_header_len)
+ if (len > dev->mtu + dev->hard_header_len + VLAN_HLEN)
goto out_unlock;
if (!skb) {
@@ -497,6 +497,19 @@ retry:
goto retry;
}
+ if (len > (dev->mtu + dev->hard_header_len)) {
+ /* Earlier code assumed this would be a VLAN pkt,
+ * double-check this now that we have the actual
+ * packet in hand.
+ */
+ struct ethhdr *ehdr;
+ skb_reset_mac_header(skb);
+ ehdr = eth_hdr(skb);
+ if (ehdr->h_proto != htons(ETH_P_8021Q)) {
+ err = -EMSGSIZE;
+ goto out_unlock;
+ }
+ }
skb->protocol = proto;
skb->dev = dev;
@@ -1200,7 +1213,7 @@ static int packet_snd(struct socket *sock,
}
err = -EMSGSIZE;
- if (!gso_type && (len > dev->mtu+reserve))
+ if (!gso_type && (len > dev->mtu + reserve + ETH_HLEN))
goto out_unlock;
err = -ENOBUFS;
@@ -1225,6 +1238,20 @@ static int packet_snd(struct socket *sock,
if (err < 0)
goto out_free;
+ if (!gso_type && (len > dev->mtu + reserve)) {
+ /* Earlier code assumed this would be a VLAN pkt,
+ * double-check this now that we have the actual
+ * packet in hand.
+ */
+ struct ethhdr *ehdr;
+ skb_reset_mac_header(skb);
+ ehdr = eth_hdr(skb);
+ if (ehdr->h_proto != htons(ETH_P_8021Q)) {
+ err = -EMSGSIZE;
+ goto out_free;
+ }
+ }
+
skb->protocol = proto;
skb->dev = dev;
skb->priority = sk->sk_priority;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] igb: Allow extra 4 bytes on RX for vlan tags.
From: greearb @ 2011-02-10 21:59 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
This allows the NIC to receive 1518 byte (not counting
FCS) packets when MTU is 1500, thus allowing 1500 MTU
VLAN frames to be received. Please note that no VLANs
were actually configured on the NIC...it was just acting
as pass-through device.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 58c665b... 30c9cc6... M drivers/net/igb/igb_main.c
drivers/net/igb/igb_main.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 58c665b..30c9cc6 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -2281,7 +2281,8 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
adapter->rx_itr_setting = IGB_DEFAULT_ITR;
adapter->tx_itr_setting = IGB_DEFAULT_ITR;
- adapter->max_frame_size = netdev->mtu + ETH_HLEN + ETH_FCS_LEN;
+ adapter->max_frame_size = (netdev->mtu + ETH_HLEN + ETH_FCS_LEN
+ + VLAN_HLEN);
adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
spin_lock_init(&adapter->stats64_lock);
@@ -4303,7 +4304,7 @@ static int igb_change_mtu(struct net_device *netdev, int new_mtu)
{
struct igb_adapter *adapter = netdev_priv(netdev);
struct pci_dev *pdev = adapter->pdev;
- int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+ int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
u32 rx_buffer_len, i;
if ((new_mtu < 68) || (max_frame > MAX_JUMBO_FRAME_SIZE)) {
--
1.7.2.3
^ permalink raw reply related
* [PATCH] Don't potentially dereference NULL in net/dcb/dcbnl.c:dcbnl_getapp()
From: Jesper Juhl @ 2011-02-10 21:57 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Alexey Dobriyan, Dan Carpenter, Shmulik Ravid,
John Fastabend, David S. Miller, Lucy Liu
nla_nest_start() may return NULL. If it does then we'll blow up in
nla_nest_end() when we dereference the pointer.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
dcbnl.c | 3 +++
1 file changed, 3 insertions(+)
only compile tested.
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 6b03f56..13cdc30 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -626,6 +626,9 @@ static int dcbnl_getapp(struct net_device *netdev, struct nlattr **tb,
dcb->cmd = DCB_CMD_GAPP;
app_nest = nla_nest_start(dcbnl_skb, DCB_ATTR_APP);
+ if (!app_nest)
+ goto out_cancel;
+
ret = nla_put_u8(dcbnl_skb, DCB_APP_ATTR_IDTYPE, idtype);
if (ret)
goto out_cancel;
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: [PATCH] tcp: undo_retrans counter fixes
From: Ilpo Järvinen @ 2011-02-10 21:31 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Netdev
In-Reply-To: <AANLkTikN9C6XV3JHUoypmVQ0H0cChmmvUU3zSWa8Fva8@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3170 bytes --]
On Thu, 10 Feb 2011, Yuchung Cheng wrote:
> On Tue, Feb 8, 2011 at 1:54 AM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> >
> > On Mon, 7 Feb 2011, Yuchung Cheng wrote:
> >
> > > On Mon, Feb 7, 2011 at 3:36 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> > > >
> > > > On Mon, 7 Feb 2011, David Miller wrote:
> > > >
> > > > > From: Yuchung Cheng <ycheng@google.com>
> > > > > Date: Mon, 7 Feb 2011 14:57:04 -0800
> > > > >
> > > > > > Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> > > > > > not set or undo_retrans is already 0. This happens when sender receives
> > > > > > more DSACK ACKs than packets retransmitted during the current
> > > > > > undo phase. This may also happen when sender receives DSACK after
> > > > > > the undo operation is completed or cancelled.
> > > > > >
> > > > > > Fix another bug that undo_retrans is incorrectly incremented when
> > > > > > sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> > > > > > is rare but not impossible.
> > > > > >
> > > > > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > > >
> > > > Neither is harmful to "fix" but I think they're partially also checking
> > > > for things which shouldn't cause problems... E.g., undo_retrans is only
> > > > used after checking undo_marker's validity first so I don't think
> > > > undo_marker check is exactly necessary there (but on the other hand it
> > > > does no harm)...
> > >
> > > logically we should check the validity of undo_marker/undo_retrans
> > > before we use them? The current code has no problem if
> > > tcp_fastretrans_alert() always call tcp_try_undo_* functions whenever
> > > undo_marker != 0 and undo_retrans == 0. I don't think that's always
> > > true.
> >
> > We certainly should be letting the undo_retrans to underflow that in this
> > your patch has merit (the added tp->undo_retrans check).
> >
> > However, the only users are:
> >
> > static inline int tcp_may_undo(struct tcp_sock *tp)
> > {
> > return tp->undo_marker && (!tp->undo_retrans ...)
> >
> > and:
> >
> > static void tcp_try_undo_dsack(struct sock *sk)
> > {
> > struct tcp_sock *tp = tcp_sk(sk);
> >
> > if (tp->undo_marker && !tp->undo_retrans) {
> >
> >
> > ...which check that undo_retrans is valid.
> But that does not make this bug go away.
> The sender does not always call these functions in tcp_fastretrans_alert().
>
> A common example is that the sender receives a DUPACK with DSACK option
> during CA_Recovery and undo_retrans goes to 0. Since it's not a partial ACK,
> no undo function is called (another bug?) while processing the DUPACK. If the
> sender receives another DSACK, undo_retrans underflows and the undo
> chance is missed forever.
But the underflow can be fixed without checking for tp->undo_marker with
the tp->undo_retrans > 0 condition only before decrementing it, right
(in sacktag code like you do)? ...I don't understand what that has to do
with these functions being called from tcp_fastretrans_alert or not.
> I think that's another potential bug in handling this situation but I
> want to fix in
> this boundary checks first.
--
i.
^ permalink raw reply
* Re: [PATCH 1/3] tg3: Avoid setting power.can_wakeup for devices that cannot wake up
From: Rafael J. Wysocki @ 2011-02-10 21:08 UTC (permalink / raw)
To: Matt Carlson
Cc: netdev@vger.kernel.org, David Miller, Michael Chan,
Linux PM mailing list, Thomas Fjellstrom, Jay Cliburn,
Chris Snook, Jie Yang
In-Reply-To: <20110210204844.GA4158@mcarlson.broadcom.com>
On Thursday, February 10, 2011, Matt Carlson wrote:
> On Thu, Feb 10, 2011 at 08:53:09AM -0800, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > The tg3 driver uses device_init_wakeup() in such a way that the
> > device's power.can_wakeup flag may be set even though the PCI
> > subsystem cleared it before, in which case the device cannot wake
> > up the system from sleep states. Modify the driver to only change
> > the power.can_wakeup flag if the device is not capable of generating
> > wakeup signals.
> >
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > ---
> > drivers/net/tg3.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > Index: linux-2.6/drivers/net/tg3.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/net/tg3.c
> > +++ linux-2.6/drivers/net/tg3.c
> > @@ -12403,9 +12403,11 @@ static void __devinit tg3_get_eeprom_hw_
> > tp->tg3_flags3 |= TG3_FLG3_RGMII_EXT_IBND_TX_EN;
> > }
> > done:
> > - device_init_wakeup(&tp->pdev->dev, tp->tg3_flags & TG3_FLAG_WOL_CAP);
> > - device_set_wakeup_enable(&tp->pdev->dev,
> > + if (tp->tg3_flags & TG3_FLAG_WOL_CAP)
> > + device_set_wakeup_enable(&tp->pdev->dev,
> > tp->tg3_flags & TG3_FLAG_WOL_ENABLE);
> > + else
> > + device_set_wakeup_capable(&tp->pdev->dev, false);
>
> I did this because I couldn't see where 'can_wakeup' gets set. I don't
> see a call to device_init_wakeup() that would be relevant to tg3
> devices. I do see a couple calls to device_set_wakeup_capable() in
> acpi/glue.c and acpi/scan.c. Is that the place?
No, it's pci_pm_init() or platform_pci_wakeup_init() and they both use
device_set_wakeup_capable() rather tha device_init_wakeup(), which is just a
combination of device_set_wakeup_capable() and device_set_wakeup_enable()
anyway.
And there's no why reason PCI drivers should use device_pm_init() at all.
> > }
> >
> > static int __devinit tg3_issue_otp_command(struct tg3 *tp, u32 cmd)
>
> This is something I was always curious about too. The TG3_FLAG_WOL_CAP
> tracks whether or not the device can handle WOL. Is it safe to do away
> with this flag and lean on the 'can_wakeup' flag instead?
I don't think so. power.can_wakeup only tracks the capability to generate
wakeup signals from the PCI perspective and it is set by PCI if the device
appears to be able to generate wakeup signals.
So, I think the driver should work as in the $subject patch - reset the
power.can_wakeup flag if TG3_FLAG_WOL_CAP is unset and don't touch it
otherwise.
Thanks,
Rafael
^ permalink raw reply
* Re: jme driver loses connection after resuming from suspend
From: Leonardo L. P. da Mata @ 2011-02-10 21:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Guo-Fu Tseng, netdev
In-Reply-To: <20110128163315.1e4e8346.akpm@linux-foundation.org>
Updated information on the bug, Guo-Fu Tseng says that might not be a
bug on the driver, but i've tested other network cards and they don't
share the same issue.
Also, on interesting update that people may consider is that after
running tcpdump on the device, the network starts working again.
Information are updated in the bug.
On Fri, Jan 28, 2011 at 10:33 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> (cc's added)
>
> On Fri, 28 Jan 2011 16:03:11 -0200
> "Leonardo L. P. da Mata" <barroca@gmail.com> wrote:
>
>> Hello, i'm testing the kernel 2.6.37 on my hardware, Once connect on
>> wired network, i call the suspend with:
>> echo "mem" >/sys/power/state
>>
>> The system goes on suspend. After resuming from suspend, the network card
>> cannot be used anymore.
>>
>>
>> The bug is reported here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=27692
>>
>> Can you please point me to similar problems on other network cards so
>> i can get possible solutions on this.
>
>
--
Leonardo Luiz Padovani da Mata
barroca@gmail.com
"May the force be with you, always"
"Nerd Pride... eu tenho. Voce tem?"
^ permalink raw reply
* [PATCH] USB Network driver infrastructure: Fix leak when usb_autopm_get_interface() returns less than zero in kevent().
From: Jesper Juhl @ 2011-02-10 20:58 UTC (permalink / raw)
To: linux-kernel
Cc: linux-usb, netdev, Greg Kroah-Hartman, David Brownell,
David Hollis
We'll leak the memory allocated to 'urb' in
drivers/net/usb/usbnet.c:kevent() when we 'goto fail_lowmem' and the 'urb'
variable goes out of scope while still completely unused.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
usbnet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
compile tested only.
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index ed9a416..95c41d5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -931,8 +931,10 @@ fail_halt:
if (urb != NULL) {
clear_bit (EVENT_RX_MEMORY, &dev->flags);
status = usb_autopm_get_interface(dev->intf);
- if (status < 0)
+ if (status < 0) {
+ usb_free_urb(urb);
goto fail_lowmem;
+ }
if (rx_submit (dev, urb, GFP_KERNEL) == -ENOLINK)
resched = 0;
usb_autopm_put_interface(dev->intf);
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: Problem with igb and vlans in 2.6.38-rc4
From: Ben Greear @ 2011-02-10 20:51 UTC (permalink / raw)
To: netdev
In-Reply-To: <4D5426ED.7000801@candelatech.com>
On 02/10/2011 09:57 AM, Ben Greear wrote:
>
> We have a user-space app that uses packet-sockets to grab and send
> Ethernet frames (basically a user-space bridge).
FYI: I'll post some patches for comment soon..seems
I have it working now, just need to clean them up and
eat lunch :)
Thanks,
Ben
>
> This has stopped working for VLANs unless we set the physical
> port MTU to be vlan-MTU + 4 (ie, 1504 for standard MTU size vlan frames).
> I think this started post 2.6.34 kernel..but not exactly sure at this
> time.
>
> The test setup is essentially:
>
> client -- vlan 5 -- [ eth4 {software-bridge} eth3 ] -- vlan 5 -- server
>
> The software bridge machine has no VLANs enabled..it is supposed to just
> read Ethernet frames from one port and xmit out the other.
>
> The bridge machine sees rx-length errors, and if only one port is
> set to 1504, the other shows xmit errors (since it doesn't like sending
> a frame 4 bytes larger than MTU probably).
>
> This used to work, and I'm hoping this change wasn't done on purpose.
>
> Thanks,
> Ben
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/3] tg3: Avoid setting power.can_wakeup for devices that cannot wake up
From: Matt Carlson @ 2011-02-10 20:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: netdev@vger.kernel.org, David Miller, Matthew Carlson,
Michael Chan, Linux PM mailing list, Thomas Fjellstrom,
Jay Cliburn, Chris Snook, Jie Yang
In-Reply-To: <201102101753.09504.rjw@sisk.pl>
On Thu, Feb 10, 2011 at 08:53:09AM -0800, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> The tg3 driver uses device_init_wakeup() in such a way that the
> device's power.can_wakeup flag may be set even though the PCI
> subsystem cleared it before, in which case the device cannot wake
> up the system from sleep states. Modify the driver to only change
> the power.can_wakeup flag if the device is not capable of generating
> wakeup signals.
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/net/tg3.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/drivers/net/tg3.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/tg3.c
> +++ linux-2.6/drivers/net/tg3.c
> @@ -12403,9 +12403,11 @@ static void __devinit tg3_get_eeprom_hw_
> tp->tg3_flags3 |= TG3_FLG3_RGMII_EXT_IBND_TX_EN;
> }
> done:
> - device_init_wakeup(&tp->pdev->dev, tp->tg3_flags & TG3_FLAG_WOL_CAP);
> - device_set_wakeup_enable(&tp->pdev->dev,
> + if (tp->tg3_flags & TG3_FLAG_WOL_CAP)
> + device_set_wakeup_enable(&tp->pdev->dev,
> tp->tg3_flags & TG3_FLAG_WOL_ENABLE);
> + else
> + device_set_wakeup_capable(&tp->pdev->dev, false);
I did this because I couldn't see where 'can_wakeup' gets set. I don't
see a call to device_init_wakeup() that would be relevant to tg3
devices. I do see a couple calls to device_set_wakeup_capable() in
acpi/glue.c and acpi/scan.c. Is that the place?
> }
>
> static int __devinit tg3_issue_otp_command(struct tg3 *tp, u32 cmd)
This is something I was always curious about too. The TG3_FLAG_WOL_CAP
tracks whether or not the device can handle WOL. Is it safe to do away
with this flag and lean on the 'can_wakeup' flag instead? My concern is
that some other part of the system might enable that flag after
tg3_get_invariants() has run. If that happens and the device isn't
really WOL capable bad things can occur.
^ permalink raw reply
* Re: [PATCH] tcp: undo_retrans counter fixes
From: Yuchung Cheng @ 2011-02-10 19:59 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: David Miller, Netdev
In-Reply-To: <alpine.DEB.2.00.1102081110050.26191@melkinpaasi.cs.helsinki.fi>
On Tue, Feb 8, 2011 at 1:54 AM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
>
> On Mon, 7 Feb 2011, Yuchung Cheng wrote:
>
> > On Mon, Feb 7, 2011 at 3:36 PM, Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> wrote:
> > >
> > > On Mon, 7 Feb 2011, David Miller wrote:
> > >
> > > > From: Yuchung Cheng <ycheng@google.com>
> > > > Date: Mon, 7 Feb 2011 14:57:04 -0800
> > > >
> > > > > Fix a bug that undo_retrans is incorrectly decremented when undo_marker is
> > > > > not set or undo_retrans is already 0. This happens when sender receives
> > > > > more DSACK ACKs than packets retransmitted during the current
> > > > > undo phase. This may also happen when sender receives DSACK after
> > > > > the undo operation is completed or cancelled.
> > > > >
> > > > > Fix another bug that undo_retrans is incorrectly incremented when
> > > > > sender retransmits an skb and tcp_skb_pcount(skb) > 1 (TSO). This case
> > > > > is rare but not impossible.
> > > > >
> > > > > Signed-off-by: Yuchung Cheng <ycheng@google.com>
> > >
> > > Neither is harmful to "fix" but I think they're partially also checking
> > > for things which shouldn't cause problems... E.g., undo_retrans is only
> > > used after checking undo_marker's validity first so I don't think
> > > undo_marker check is exactly necessary there (but on the other hand it
> > > does no harm)...
> >
> > logically we should check the validity of undo_marker/undo_retrans
> > before we use them? The current code has no problem if
> > tcp_fastretrans_alert() always call tcp_try_undo_* functions whenever
> > undo_marker != 0 and undo_retrans == 0. I don't think that's always
> > true.
>
> We certainly should be letting the undo_retrans to underflow that in this
> your patch has merit (the added tp->undo_retrans check).
>
> However, the only users are:
>
> static inline int tcp_may_undo(struct tcp_sock *tp)
> {
> return tp->undo_marker && (!tp->undo_retrans ...)
>
> and:
>
> static void tcp_try_undo_dsack(struct sock *sk)
> {
> struct tcp_sock *tp = tcp_sk(sk);
>
> if (tp->undo_marker && !tp->undo_retrans) {
>
>
> ...which check that undo_retrans is valid.
But that does not make this bug go away.
The sender does not always call these functions in tcp_fastretrans_alert().
A common example is that the sender receives a DUPACK with DSACK option
during CA_Recovery and undo_retrans goes to 0. Since it's not a partial ACK,
no undo function is called (another bug?) while processing the DUPACK. If the
sender receives another DSACK, undo_retrans underflows and the undo
chance is missed forever.
I think that's another potential bug in handling this situation but I
want to fix in
this boundary checks first.
HTH
>
> > > The tcp_retransmit_skb problem I don't understand at all as we should be
> > > fragmenting or resetting pcount to 1 (the latter is true only if all
> > > bugfixes were included to the kernel where >1 pcount for a rexmitted skb
> > > was seen). If pcount is indeed >1 we might have other issues too somewhere
> >
> > We found that sometimes pcount > 1 on real servers. This change keeps
> > the retrans_out/undo_retrans counters consistent.
>
> There's still some bug then I guess... It might be related to the issues
> seen by those other guys who were complaining about small segments with
> >1 pcount breaking their hardware (few months ago). For the record, the
> last fix is from 2.6.31 or so.
>
> Like I said, I don't oppose this change anyway:
>
> > > but I fail to remember immediately what they would be. That change is not
> > > bad though since using +/-1 is something we should be getting rid of
> > > anyway and on long term it would be nice to make tcp_retransmit_skb to be
> > > able to take advantage of TSO anyway whenever possible.
>
> ...it certainly won't hurt to be on the safe side here if/when something
> else is wrong.
>
> > > I also noticed that the undo_retrans code in sacktag side is still doing
> > > undo_retrans-- ops which could certainly cause real miscounts, though
> > > it is extremely unlikely due to the fact that DSACK should be sent
> > > immediately for a single segment at a time (so the sender would need to
> > > split+recollapse in between).
> >
> > I have the same doubt but our servers never hit this condition (pcount
> > 1). So I keep this part intact.
>
> I could think of some scenario you cannot even reproduce in a large scale
> tests, unlikely indeed :-). ...Or too stable connectivity on the sender
> side. But I've changed my mind... the -1 operation is the correct one as
> we could otherwise overestimate due to pcount=1->2 split after the
> retransmission that triggered the DSACK (now that I remember this, I think
> I've once thought this line through already earlier... I'll try to write a
> comment one day there).
>
> For -rc/next purposes I don't see any big enough reasons to withhold:
>
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>
> ...but if you want this to stables too I don't think it's minimal w.r.t.
> undo_marker check.
>
> --
> i.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28532] New: Link state change detection problem on Moschip MCS7832 [mcs7830]
From: Dan Williams @ 2011-02-10 19:58 UTC (permalink / raw)
To: Andreas Mohr
Cc: Andrew Morton, netdev, linux-usb, bugzilla-daemon, bugme-daemon,
myxal.mxl
In-Reply-To: <20110208205247.GA4617@rhlx01.hs-esslingen.de>
On Tue, 2011-02-08 at 21:52 +0100, Andreas Mohr wrote:
> Hi,
>
> > > I have a network adapter which uses the aforementioned driver and while
> > > checking for the link state via ethtool reports the correct state, many
> > > networking userspace utilities seem to have no clue about it (NM 0.8.1 starts
> > > dhclient BEFORE any cable is plugged) - and more importantly, don't notice when
> > > the cable is (dis)connected. Since there's not even a kernel message when
> > > (dis)connecting the cable, I suspect the driver does not implement Link state
> > > change detection at all. Is this accurate?
>
> Ah, perhaps that is why as long as network-mangler is running, my
If the driver does not support link detection, NM can only assume that
the device always has a carrier. NM actually just uses the 'carrier'
flag from netlink, and since drivers that don't support link detection
never set the carrier flag to 0, carrier is always 1 as seen by NM. If
the device says it has a carrier, that means stuff that listens for that
(ie, NM, ifplugd, whatever) will try to configure IP on the device.
Drivers should really, really support link detection.
Dan
> .resume_reset() handler improvements (managing to keep an active interface
> even directly after resume) actually do _not_ work (since it seems it simply
> down:s the iface and that's it).
> I know that there is link info functionality in other drivers yet not
> as much in mcs7830.
>
> Note that the mcs7830 driver still has a rather stubby appearance
> (many more "advanced" features are either weak or not available at all).
>
> I've got a patch series sitting here to improve several parts
> (and waiting to cook a bit more), but I hadn't even identified the link issue.
> It appears that this would need fixing, presto.
>
> > > LSCD works in Windows, where it's apparently implemented through periodic
> > > polling (judging by virtualbox's blinking USB icon).
> > > How is this situation normally handled? Is it kernel's job to do the polling?
> > > Or are userspace utilities expected to do this?
>
> I'm afraid a painful solution would be to activate the .status callback
> for periodic USB status descriptor polling. I've got a
> half-implementation of that, however it's very painful in terms of
> obscene amounts of CPU wakeups.
> There _has_ to be a better solution...
>
> Thank you for your (the OP's) report (and for my extra notification!),
> this seems very helpful!
> (I am determined to post related useful patches soon,
> especially since this card is in active use here)
>
> Andreas Mohr
> --
> 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
* [GIT] Networking
From: David Miller @ 2011-02-10 19:33 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix for x25 rmmod hang w/DEBUG_PAGE_ALLOC found by Randy Dunlap.
2) Fix for the hysdn "writes to const" bug, also found by Randy.
3) virtio_net napi_enable() fix from Bruce Rogers via Rusty.
4) Fix network device queue lockdep regression, we initialize the
lockdep class (based upon dev->type) before we invoke setup()
callback, which is where dev->type is actually set properly.
5) While fixing #4 I found a bug in net/caif wherein is uses
the setup() function to create state that would need to
be unwound on failure, which isn't possible in this context.
6) x25 leaks SKBs on bad facilities, fix from Andrew Hendry.
7) pch_gbe wedges when rx offload is set by ethtool, fix from Toshiharu Okada.
8) pch_can bug fixes from Tomoya MORINAGA.
9) batman-adv packet merging can crash on non-linear packets, fix from
Sven Eckelmann.
10) Double SKB free fix in ath9k from Mohammed Shafi Shajakhan.
11) Mem leak in sis900 RX error path, from Jesper Juhl.
12) Fix mac80211 SKB clone check in TX path, from Felix Fietkau.
13) ixgbe header split erratum fix from Don Skidmore.
Please pull, thanks a lot!
The following changes since commit 6148a47ac3872092d4bc4888838bec6dff16654d:
Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-02-09 16:56:33 -0800)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Ajit Khaparde (1):
benet: Avoid potential null deref in be_cmd_get_seeprom_data()
Alexander Duyck (1):
ixgbe: limit VF access to network traffic
Alexey Orishko (2):
CDC NCM errata updates for cdc.h
USB CDC NCM errata updates for cdc_ncm host driver
Bruce Rogers (1):
virtio_net: Add schedule check to napi_enable call
Christian Lamparter (1):
carl9170: fix typo in PS code
David S. Miller (8):
Merge branch 'batman-adv/merge' of git://git.open-mesh.org/ecsv/linux-merge
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Merge branch 'master' of master.kernel.org:/.../jkirsher/net-2.6
net/caif: Fix dangling list pointer in freed object on error.
net: Fix lockdep regression caused by initializing netdev queues too early.
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
isdn: hysdn: Kill (partially buggy) CVS regision log reporting.
x25: Do not reference freed memory.
Don Fry (1):
iwlagn: Re-enable RF_KILL interrupt when down
Don Skidmore (3):
ixgbe: fix for 82599 erratum on Header Splitting
ixgbe: cleanup variable initialization
ixgbe: update version string
Emil Tantilov (1):
ixgbe: fix variable set but not used warnings by gcc 4.6
Felix Fietkau (1):
mac80211: fix the skb cloned check in the tx path
Florian Fainelli (1):
e1000: add support for Marvell Alaska M88E1118R PHY
Jesper Juhl (2):
wireless, wl1251: Fix potential NULL pointer dereference in wl1251_op_bss_info_changed()
sis900: Fix mem leak in sis900_rx error path
Jesse Brandeburg (1):
e1000e: tx_timeout should not increment for non-hang events
Johannes Berg (1):
mac80211: fix TX status cookie in HW offload case
Michael Buesch (1):
ssb-pcmcia: Fix parsing of invariants tuples
Mohammed Shafi Shajakhan (1):
ath9k: Fix possible double free of PAPRD skb's
Pablo Neira Ayuso (1):
netfilter: nf_conntrack: set conntrack templates again if we return NF_REPEAT
Randy Dunlap (1):
can: softing_cs needs slab.h
Sven Eckelmann (1):
batman-adv: Linearize fragment packets before merge
Tomoya (3):
pch_can: fix 800k comms issue
pch_can: fix rmmod issue
pch_can: fix module reload issue with MSI
Tomoya MORINAGA (1):
pch_can: fix tseg1/tseg2 setting issue
Toshiharu Okada (1):
pch_gbe: Fix the issue which a driver locks when rx offload is set by ethtool
Vladislav Zolotarov (1):
bnx2x: Duplication in promisc mode
Wey-Yi Guy (1):
iwlagn: overwrite EEPROM chain setting for 6250 devices
andrew hendry (1):
x25: possible skb leak on bad facilities
drivers/isdn/hysdn/hysdn_defs.h | 2 -
drivers/isdn/hysdn/hysdn_init.c | 26 +----
drivers/isdn/hysdn/hysdn_net.c | 3 -
drivers/isdn/hysdn/hysdn_procconf.c | 3 +-
drivers/net/benet/be_cmds.c | 5 +
drivers/net/bnx2x/bnx2x_main.c | 32 +++--
drivers/net/can/pch_can.c | 5 +-
drivers/net/can/softing/softing_cs.c | 1 +
drivers/net/e1000/e1000_hw.c | 4 +-
drivers/net/e1000/e1000_hw.h | 1 +
drivers/net/e1000e/netdev.c | 1 -
drivers/net/ixgbe/ixgbe_common.c | 3 +
drivers/net/ixgbe/ixgbe_fcoe.c | 2 +-
drivers/net/ixgbe/ixgbe_main.c | 16 ++-
drivers/net/ixgbe/ixgbe_sriov.c | 2 -
drivers/net/ixgbe/ixgbe_x540.c | 6 +-
drivers/net/pch_gbe/pch_gbe_main.c | 12 +-
drivers/net/sis900.c | 1 +
drivers/net/usb/cdc_ncm.c | 227 ++++++++++++++++++++-----------
drivers/net/virtio_net.c | 27 ++--
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 2 -
drivers/net/wireless/ath/ath9k/xmit.c | 7 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 6 +
drivers/net/wireless/wl1251/main.c | 3 +
drivers/ssb/pcmcia.c | 2 +-
include/linux/usb/cdc.h | 23 +++-
net/batman-adv/unicast.c | 15 ++-
net/caif/chnl_net.c | 4 +-
net/core/dev.c | 27 ++--
net/mac80211/cfg.c | 2 +
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/status.c | 7 +-
net/mac80211/tx.c | 2 +-
net/netfilter/nf_conntrack_core.c | 11 ++-
net/x25/x25_facilities.c | 28 +++--
net/x25/x25_in.c | 14 ++-
net/x25/x25_link.c | 5 +-
40 files changed, 342 insertions(+), 203 deletions(-)
^ permalink raw reply
* Re: [PATCH] virtio_net: Add schedule check to napi_enable call
From: David Miller @ 2011-02-10 19:03 UTC (permalink / raw)
To: rusty; +Cc: herbert, netdev, virtualization, kstailey
In-Reply-To: <201102101232.50526.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 10 Feb 2011 12:32:50 +1030
> From: "Bruce Rogers" <brogers@novell.com>
>
> Under harsh testing conditions, including low memory, the guest would
> stop receiving packets. With this patch applied we no longer see any
> problems in the driver while performing these tests for extended periods
> of time.
>
> Make sure napi is scheduled subsequent to each napi_enable.
>
> Signed-off-by: Bruce Rogers <brogers@novell.com>
> Signed-off-by: Olaf Kirch <okir@suse.de>
> Cc: stable@kernel.org
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] virtio_net: Add schedule check to napi_enable call
From: David Miller @ 2011-02-10 19:01 UTC (permalink / raw)
To: mst; +Cc: rusty, herbert, netdev, virtualization, kstailey
In-Reply-To: <20110210175725.GA9674@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 10 Feb 2011 19:57:26 +0200
> On Thu, Feb 10, 2011 at 12:32:50PM +1030, Rusty Russell wrote:
>> From: "Bruce Rogers" <brogers@novell.com>
>>
>> Under harsh testing conditions, including low memory, the guest would
>> stop receiving packets. With this patch applied we no longer see any
>> problems in the driver while performing these tests for extended periods
>> of time.
>>
>> Make sure napi is scheduled subsequent to each napi_enable.
>>
>> Signed-off-by: Bruce Rogers <brogers@novell.com>
>> Signed-off-by: Olaf Kirch <okir@suse.de>
>> Cc: stable@kernel.org
>> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> Rusty, so this is 2.6.38 material - you'll send this to Linus? Or DaveM?
Don't worry I'll apply this to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH v5 0/4] Adding HID Feature Report Support to hidraw
From: Gustavo F. Padovan @ 2011-02-10 18:14 UTC (permalink / raw)
To: Jiri Kosina
Cc: Alan Ott, Marcel Holtmann, David S. Miller, Michael Poole,
Eric Dumazet, linux-input, linux-kernel, linux-usb,
linux-bluetooth, netdev
In-Reply-To: <alpine.LNX.2.00.1101191316230.26685@pobox.suse.cz>
Hi Jiri,
* Jiri Kosina <jkosina@suse.cz> [2011-01-19 13:17:00 +0100]:
> On Tue, 18 Jan 2011, Alan Ott wrote:
>
> > This patch adds Feature Report support for USB and Bluetooth HID devices
> > through hidraw.
> >
> > The first two patches prepare the bluetooth side for the change.
> > a. Make sure the hidp_session() thread is started before
> > device's probe() functions are called.
> > b. Wait for ACK/NAK on sent reports, and return proper
> > error codes.
> > The third patch is the hidraw core and USB changes.
> > The fourth patch is the Bluetooth changes.
> >
> > Thanks to Antonio Ospite and Bill Good for providing testing and feedback.
> >
> >
> > Alan Ott (4):
> > bt hidp: Move hid_add_device() call to after hidp_session() has
> > started.
> > bt hidp: Wait for ACK on Sent Reports
> > HID: Add Support for Setting and Getting Feature Reports from hidraw
> > Bluetooth hidp: Add support for hidraw HIDIOCGFEATURE and
> > HIDIOCSFEATURE
> >
> > drivers/hid/hidraw.c | 106 +++++++++++++++++++-
> > drivers/hid/usbhid/hid-core.c | 35 +++++++
> > include/linux/hid.h | 3 +
> > include/linux/hidraw.h | 3 +
> > net/bluetooth/hidp/core.c | 214 ++++++++++++++++++++++++++++++++++++++---
> > net/bluetooth/hidp/hidp.h | 15 +++
>
> Before proceeding with these patches, I'd really like to have comment
> (ideally 'Acked-by') from Marcel on the net/bluetooth/hidp part,
> obviously.
I have tested it and it seems ok to me and to Marcel. For net/bluetooth/
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
Regards,
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] bluetooth: l2cap: fix 1 byte infoleak to userspace
From: Gustavo F. Padovan @ 2011-02-10 18:11 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1297360783-21452-1-git-send-email-segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
Hi Vasiliy,
* Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org> [2011-02-10 20:59:42 +0300]:
> Structure l2cap_options has one padding byte between max_tx and
> txwin_size fields. This byte in "opts" is copied to userspace
> uninitialized.
>
> Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
> ---
> Compile tested only.
>
> net/bluetooth/l2cap_sock.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Patch has been applied, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH] bluetooth: l2cap: fix 1 byte infoleak to userspace
From: Vasiliy Kulikov @ 2011-02-10 17:59 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann,
Gustavo F. Padovan, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Structure l2cap_options has one padding byte between max_tx and
txwin_size fields. This byte in "opts" is copied to userspace
uninitialized.
Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
---
Compile tested only.
net/bluetooth/l2cap_sock.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index adf4169..21f5385 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -392,6 +392,7 @@ static int l2cap_sock_getsockopt_old(struct socket *sock, int optname, char __us
switch (optname) {
case L2CAP_OPTIONS:
+ memset(&opts, 0, sizeof(opts));
opts.imtu = l2cap_pi(sk)->imtu;
opts.omtu = l2cap_pi(sk)->omtu;
opts.flush_to = l2cap_pi(sk)->flush_to;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] virtio_net: Add schedule check to napi_enable call
From: Michael S. Tsirkin @ 2011-02-10 17:57 UTC (permalink / raw)
To: Rusty Russell
Cc: Herbert Xu, netdev, David Miller, virtualization, Ken Stailey
In-Reply-To: <201102101232.50526.rusty@rustcorp.com.au>
On Thu, Feb 10, 2011 at 12:32:50PM +1030, Rusty Russell wrote:
> From: "Bruce Rogers" <brogers@novell.com>
>
> Under harsh testing conditions, including low memory, the guest would
> stop receiving packets. With this patch applied we no longer see any
> problems in the driver while performing these tests for extended periods
> of time.
>
> Make sure napi is scheduled subsequent to each napi_enable.
>
> Signed-off-by: Bruce Rogers <brogers@novell.com>
> Signed-off-by: Olaf Kirch <okir@suse.de>
> Cc: stable@kernel.org
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty, so this is 2.6.38 material - you'll send this to Linus? Or DaveM?
> ---
> drivers/net/virtio_net.c | 27 ++++++++++++++++-----------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -446,6 +446,20 @@ static void skb_recv_done(struct virtque
> }
> }
>
> +static void virtnet_napi_enable(struct virtnet_info *vi)
> +{
> + napi_enable(&vi->napi);
> +
> + /* If all buffers were filled by other side before we napi_enabled, we
> + * won't get another interrupt, so process any outstanding packets
> + * now. virtnet_poll wants re-enable the queue, so we disable here.
> + * We synchronize against interrupts via NAPI_STATE_SCHED */
> + if (napi_schedule_prep(&vi->napi)) {
> + virtqueue_disable_cb(vi->rvq);
> + __napi_schedule(&vi->napi);
> + }
> +}
> +
> static void refill_work(struct work_struct *work)
> {
> struct virtnet_info *vi;
> @@ -454,7 +468,7 @@ static void refill_work(struct work_stru
> vi = container_of(work, struct virtnet_info, refill.work);
> napi_disable(&vi->napi);
> still_empty = !try_fill_recv(vi, GFP_KERNEL);
> - napi_enable(&vi->napi);
> + virtnet_napi_enable(vi);
>
> /* In theory, this can happen: if we don't get any buffers in
> * we will *never* try to fill again. */
> @@ -638,16 +652,7 @@ static int virtnet_open(struct net_devic
> {
> struct virtnet_info *vi = netdev_priv(dev);
>
> - napi_enable(&vi->napi);
> -
> - /* If all buffers were filled by other side before we napi_enabled, we
> - * won't get another interrupt, so process any outstanding packets
> - * now. virtnet_poll wants re-enable the queue, so we disable here.
> - * We synchronize against interrupts via NAPI_STATE_SCHED */
> - if (napi_schedule_prep(&vi->napi)) {
> - virtqueue_disable_cb(vi->rvq);
> - __napi_schedule(&vi->napi);
> - }
> + virtnet_napi_enable(vi);
> return 0;
> }
>
> --
> 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
* Problem with igb and vlans in 2.6.38-rc4
From: Ben Greear @ 2011-02-10 17:57 UTC (permalink / raw)
To: netdev
We have a user-space app that uses packet-sockets to grab and send
Ethernet frames (basically a user-space bridge).
This has stopped working for VLANs unless we set the physical
port MTU to be vlan-MTU + 4 (ie, 1504 for standard MTU size vlan frames).
I think this started post 2.6.34 kernel..but not exactly sure at this
time.
The test setup is essentially:
client -- vlan 5 -- [ eth4 {software-bridge} eth3 ] -- vlan 5 -- server
The software bridge machine has no VLANs enabled..it is supposed to just
read Ethernet frames from one port and xmit out the other.
The bridge machine sees rx-length errors, and if only one port is
set to 1504, the other shows xmit errors (since it doesn't like sending
a frame 4 bytes larger than MTU probably).
This used to work, and I'm hoping this change wasn't done on purpose.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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