* Re: e1000 tcp checksum incorrect, x86 64b
From: Jon Smirl @ 2007-09-28 17:39 UTC (permalink / raw)
To: Rick Jones; +Cc: Herbert Xu, netdev
In-Reply-To: <46FD2D3B.4050605@hp.com>
On 9/28/07, Rick Jones <rick.jones2@hp.com> wrote:
> Herbert Xu wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> >
> >>App is writing seven bytes to the socket. Socket write timeout expires
> >>and the seven bytes are sent. The checksum is not getting inserted
> >>into the packet. It is set to a constant 0x8389 instead of the right
> >>value. App is gmpc 0.15.4.95, Revision: 6794
> >>
> >>Attached Wireshark packet trace show the problem. e1000 is 192.168.1.4
> >>64bit, Q6600. Dell Dimension 9200
> >
> >
> > Wireshark is broken. It needs to know TP_STATUS_CSUMNOTREADY
> > means that the checksum is partial and will only be completed
> > when the hardware sends the packet out.
> >
> > Alternatively disable checksum offload with ethtool.
>
> Or take the packet traces "outboard" of the NIC somewhere/somehow.
>
> What problem(s) led to your taking the packet trace in the first place?
I was working on the Ethernet driver for another embedded system
attached to the box. I noticed these errors going to my NSLU2 which I
thought was working ok. But now I know they are not real errors.
Ethernet driver for MPC5200 in embedded system still has some
problems. It is being discussed on linuxppc-embedded.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: /proc/net/ bad hard links count [Was: 2.6.23-rc8-mm2]
From: Eric W. Biederman @ 2007-09-28 17:03 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, netdev, Linux Containers
In-Reply-To: <46FD2C10.8050105@gmail.com>
Jiri Slaby <jirislaby@gmail.com> writes:
> On 09/27/2007 11:22 AM, Andrew Morton wrote:
>>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
Yep.
> # find /proc >/dev/null
> find: WARNING: Hard link count is wrong for /proc/net: this may be a bug in your
> filesystem driver. Automatically turning on find's -noleaf option. Earlier
> results may have failed to include directories that should have been searched.
> # stat net
> File: `net'
> Size: 0 Blocks: 0 IO Block: 1024 directory
> Device: 3h/3d Inode: 4026531864 Links: 2
> Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2007-09-28 18:21:24.651209759 +0200
> Modify: 2007-09-28 18:21:24.651209759 +0200
> Change: 2007-09-28 18:21:24.651209759 +0200
> # stat net/
> File: `net/'
> Size: 0 Blocks: 0 IO Block: 1024 directory
> Device: 3h/3d Inode: 4026531909 Links: 4
> Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2007-09-28 18:26:48.813048220 +0200
> Modify: 2007-09-28 18:26:48.813048220 +0200
> Change: 2007-09-28 18:26:48.813048220 +0200
>
> hmm, this is some kind of weirdness :)
Yes.
I can explain it. For the network namespace stuff we need special handling
of /proc/net so that depending on the network namespace we are resolving
against you see a different behavior. So you actually are observing
two different directories, one being a magic invisible symlink to the
other.
Currently I am resolving against current (which has a number of
limitations) and the weird ugly effect you are current seeing.
So it looks like I need to either make /proc/net a symlink to
/proc/self/net or make the network namespace something that we capture
at mount time of /proc.
This was my don't get hung up on this implementation detail version.
Thanks for pointing out it has user visible problems. I will see
what I can do to resolve this.
Eric
^ permalink raw reply
* Re: [PKT_SCHED]: Add stateless NAT
From: Patrick McHardy @ 2007-09-28 16:55 UTC (permalink / raw)
To: David Miller; +Cc: hadi, herbert, netdev, kuznet
In-Reply-To: <20070927.120803.39482469.davem@davemloft.net>
David Miller wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Thu, 27 Sep 2007 08:39:45 -0400
>
>>>+config NET_ACT_NAT
>>>+ tristate "Stateless NAT"
>>>+ depends on NET_CLS_ACT
>>>+ select NETFILTER
>>
>>I am gonna have to agree with Evgeniy on this Herbert;->
>>The rewards are it will improve performance for people who dont need
>>netfilter.
>
>
> I agree that we should move the functions out. However...
>
> You have to realize that this logic is a complete crock
> of shit for %99.99999999999999999999 of Linux users out there
> who get and only use distribution compiled kernels which are
> going to enable everything anyways.
>
> So we better make sure there are zero performance implications at some
> point just for compiling netfilter into the tree. I know that isn't
> the case currently, but that means that we aren't helping out the
> majority of Linux users and are thus only adding these optimizations
> for such a small sliver of users and that is totally pointless and
> sucks.
The hooks themselves actually shouldn't be that much of a problem
since without any registered users they come down to a simple
list_empty check. The bigger problem is probably the fact that
the "okfn" is usually declared inline, but we also take its address
for nf_hook_slow, so at least with forced inlining, we end up
with one inlined and one out-of-line version.
Looking at ip_input.o as example (everything without forced inlining):
text data bss dec hex filename
2076 8 0 2084 824 net/ipv4/ip_input.o
3483 8 0 3491 da3 net/ipv4/ip_input.o
So we have roughly 1.75 more code for the two hooks. For reference,
without using the function pointer it increases a lot less:
text data bss dec hex filename
2319 8 0 2327 917 net/ipv4/ip_input.o
similar with not inlining ip_rcv_finish() and ip_local_deliver_finish():
text data bss dec hex filename
2282 8 0 2290 8f2 net/ipv4/ip_input.o
Any ideas how to do this better? Unforunately we need the function
pointers for reinjecting queued packets ..
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Eric W. Biederman @ 2007-09-28 16:52 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, Oliver Hartkopp, Urs Thuermann, Daniel Lezcano
In-Reply-To: <46FCBFC3.7020106@hartkopp.net>
Oliver Hartkopp <oliver@hartkopp.net> writes:
> Eric W. Biederman wrote:
>>
>> Currently IFF_LOOPBACK set in dev->flags means we are dealing
>> with drivers/net/loopback.c.
>>
>
> This is a very general view, don't you think? The one is an interface
> flag and the other one is an interface itself. This looks like a risky
> mixture, when there is no clean separation.
The better definition followed that IFF_LOOPBACK means all packets
will loopback. Currently we only have one such device in the tree.
And the CAN devices do not have that property.
>> So at a first glance the CAN usage of IFF_LOOPBACK looks completely
>> broken, and likely to confuse other networking layers if they see
>> a CAN device. Say if someone attempts to run IP over CAN or
>> something like that.
>>
>
> The CAN protocol family is some kind of a closed ecosystem with a
> complete different addressing scheme that uses the bare networking
> functionality of the Linux Kernel as well as DECNET or ARCNET. You would
> never been able to run the IP-stack on a CAN netdev (ARPHDR_CAN,
> ETH_P_CAN) due to several technical differences in addressing, etc.
However when register_netdev is the netdev_notifier chain is called
with NETDEV_REGISTER
So then we enter code paths such as "net/ipv4/inetdev_event()" and
process the network device. There is some small amount of treatment
given to devices that have IFF_LOOPBACK set.
The core point being that CAN devices as currently constructed are not
in a closed ecosystem. Other networking layers see them even if they
can not use the properly.
I don't know what all of the implications are but I do know we
need to be careful.
>> Do you think you can remove this incompatible usage of IFF_LOOPBACK
>> from the can code?
>>
>
> Yes. We might pick another name for it (see below).
Thanks.
>> If I have read your documentation properly the only reason you are
>> doing this is so that the timing of frames to cansniffer more
>> accurately reflects when the frame hits the wire. If CAN runs over a
>> very slow medium I guess I can see where that can be a concern.
>
> So it's not an issue of having better timings but to reproduce the
> *correct message order* from the CAN bus. One year ago this problem has
> originally been pointed out by Michael Schulze from the University of
> Magdeburg as having a correct message order created by the CSMA/CA
> treatment is a vital requirement for CAN bus users. As you might see now
> the CAN netdriver has to offer additional functionalities due to the
> CSMA/CA treatment in opposite to the 'standard' CSMA/CD behaviour you
> know from Ethernet netdrivers. And this arbitration information of the
> CAN controller is only available on driver level. It is therefore no
> question IF the CAN netdriver supports the CSMA/CA treatment but HOW to
> provide an interface for this functionality on a basis of a standard
> netdriver (which simply only sends and receives frames).
Ok. So the difference here is that CAN devices provide ordering on
the wire between their transmitted packets and their received packets,
and you need an additional hook so you can properly observe this case.
Hmm. My gut feel says that we just want function your drivers can
call post transmit that will call dev_queue_xmit_nit if someone else
is watching. Although calling netif_rx seems to work but at least
in the general case with routing I would be concerned that would get
you into packets that would get routed out the incoming interface
and cause a loop.
> As the CAN netdrivers (as described above) are only available and used
> by the PF_CAN core, the use of IFF_LOOPBACK looked like reasonable
> solution to distinguish whether the CAN netdriver is capable to do the
> loopback (e.g. due to the ability of the controller to generate
> TX-interrupts) or not. The usage of IFF_LOOPBACK in CAN netdrivers
> didn't affect or confuse the rest of the Linux networking system up to
> now. Btw. if you state that IFF_LOOPBACK means for a netdriver, that
> "all packets from a device will come right back to the current machine,
> and go nowhere else.", we should think about a new IFF_-flag here.
Yes. IFF_LOOPBACK for a netdriver means that all packets from a device
will come right back to the current machine. I stated that in a
later message, as that seems a clearer way to express what it means.
Further I still don't see any mechanism that isolates CAN netdrivers
from the other protocol layers.
What makes this problem a little stronger is that I have been
simplifying some of the tests in some of the other networking layers
from being "if (dev == loopback_dev)" to "if (dev->flags &
IFF_LOOPBACK)" So there are fewer special cases I need to deal with.
I believe that if you now use your current CAN patches unless I have
misread something your can devices will now show up with ip 127.0.0.1
> I don't have any concerns creating a new IFF_-flag for this "loopback
> approved by CSMA/CA media access" i just have no idea for a really good
> name for it. But maybe the use of IFF_LOOPBACK for CAN netdrivers
> (ARPHRD_CAN) is also ok for you now?!?
Serial devices tend to call this echo or local echo, so how about
IFF_ECHO.
Eric
^ permalink raw reply
* [PATCH 2/3] sky2: fix VLAN receive processing
From: Stephen Hemminger @ 2007-09-28 16:48 UTC (permalink / raw)
To: Krzysztof Oledzki, Greg KH; +Cc: stable, netdev, Pierre-Yves Ritschard
In-Reply-To: <20070928164811.387831540@linux-foundation.org>
[-- Attachment #1: sky2-vlan-len.patch --]
[-- Type: text/plain, Size: 1221 bytes --]
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Signed-off-by: Pierre-Yves Ritschard <pyr@spootnik.org>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-09-28 09:13:38.000000000 -0700
+++ b/drivers/net/sky2.c 2007-09-28 09:21:26.000000000 -0700
@@ -2049,6 +2049,7 @@ static struct sk_buff *sky2_receive(stru
struct sky2_port *sky2 = netdev_priv(dev);
struct rx_ring_info *re = sky2->rx_ring + sky2->rx_next;
struct sk_buff *skb = NULL;
+ u16 count;
if (unlikely(netif_msg_rx_status(sky2)))
printk(KERN_DEBUG PFX "%s: rx slot %u status 0x%x len %d\n",
@@ -2063,7 +2064,13 @@ static struct sk_buff *sky2_receive(stru
if (!(status & GMR_FS_RX_OK))
goto resubmit;
- if (status >> 16 != length)
+ count = (status & GMR_FS_LEN) >> 16;
+#ifdef SKY2_VLAN_TAG_USED
+ /* Account for vlan tag */
+ if (sky2->vlgrp && (status & GMR_FS_VLAN))
+ count -= VLAN_HLEN;
+#endif
+ if (count != length)
goto len_mismatch;
if (length < copybreak)
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 1/3] sky2: reduce impact of watchdog timer
From: Stephen Hemminger @ 2007-09-28 16:48 UTC (permalink / raw)
To: Krzysztof Oledzki, Greg KH; +Cc: stable, netdev
In-Reply-To: <20070928164811.387831540@linux-foundation.org>
[-- Attachment #1: sky2-hw-watchdog.patch --]
[-- Type: text/plain, Size: 4147 bytes --]
This is the 2.6.22 version of a regression fix that is already
in 2.6.23. Change the watchdog timer form 10 per second all the time,
to 1 per second and only if interface is up.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-09-17 10:39:47.000000000 -0700
+++ b/drivers/net/sky2.c 2007-09-28 09:13:38.000000000 -0700
@@ -96,10 +96,6 @@ static int disable_msi = 0;
module_param(disable_msi, int, 0);
MODULE_PARM_DESC(disable_msi, "Disable Message Signaled Interrupt (MSI)");
-static int idle_timeout = 100;
-module_param(idle_timeout, int, 0);
-MODULE_PARM_DESC(idle_timeout, "Watchdog timer for lost interrupts (ms)");
-
static const struct pci_device_id sky2_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9000) }, /* SK-9Sxx */
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9E00) }, /* SK-9Exx */
@@ -1693,6 +1689,8 @@ static void sky2_link_up(struct sky2_por
netif_carrier_on(sky2->netdev);
+ mod_timer(&hw->watchdog_timer, jiffies + 1);
+
/* Turn on link LED */
sky2_write8(hw, SK_REG(port, LNK_LED_REG),
LINKLED_ON | LINKLED_BLINK_OFF | LINKLED_LINKSYNC_OFF);
@@ -2384,25 +2382,25 @@ static void sky2_le_error(struct sky2_hw
sky2_write32(hw, Q_ADDR(q, Q_CSR), BMU_CLR_IRQ_CHK);
}
-/* If idle then force a fake soft NAPI poll once a second
- * to work around cases where sharing an edge triggered interrupt.
- */
-static inline void sky2_idle_start(struct sky2_hw *hw)
-{
- if (idle_timeout > 0)
- mod_timer(&hw->idle_timer,
- jiffies + msecs_to_jiffies(idle_timeout));
-}
-
-static void sky2_idle(unsigned long arg)
+/* Force a fake soft NAPI poll to handle lost IRQ's */
+static void sky2_watchdog(unsigned long arg)
{
struct sky2_hw *hw = (struct sky2_hw *) arg;
struct net_device *dev = hw->dev[0];
+ int i, active = 0;
if (__netif_rx_schedule_prep(dev))
__netif_rx_schedule(dev);
- mod_timer(&hw->idle_timer, jiffies + msecs_to_jiffies(idle_timeout));
+ for (i = 0; i < hw->ports; i++) {
+ dev = hw->dev[i];
+ if (!netif_running(dev))
+ continue;
+ ++active;
+ }
+
+ if (active)
+ mod_timer(&hw->watchdog_timer, round_jiffies(jiffies + HZ));
}
/* Hardware/software error handling */
@@ -2692,8 +2690,6 @@ static void sky2_restart(struct work_str
dev_dbg(&hw->pdev->dev, "restarting\n");
- del_timer_sync(&hw->idle_timer);
-
rtnl_lock();
sky2_write32(hw, B0_IMSK, 0);
sky2_read32(hw, B0_IMSK);
@@ -2722,8 +2718,6 @@ static void sky2_restart(struct work_str
}
}
- sky2_idle_start(hw);
-
rtnl_unlock();
}
@@ -3713,11 +3707,9 @@ static int __devinit sky2_probe(struct p
sky2_show_addr(dev1);
}
- setup_timer(&hw->idle_timer, sky2_idle, (unsigned long) hw);
+ setup_timer(&hw->watchdog_timer, sky2_watchdog, (unsigned long) hw);
INIT_WORK(&hw->restart_work, sky2_restart);
- sky2_idle_start(hw);
-
pci_set_drvdata(pdev, hw);
return 0;
@@ -3752,7 +3744,7 @@ static void __devexit sky2_remove(struct
if (!hw)
return;
- del_timer_sync(&hw->idle_timer);
+ del_timer_sync(&hw->watchdog_timer);
flush_scheduled_work();
@@ -3796,7 +3788,7 @@ static int sky2_suspend(struct pci_dev *
if (!hw)
return 0;
- del_timer_sync(&hw->idle_timer);
+ del_timer_sync(&hw->watchdog_timer);
netif_poll_disable(hw->dev[0]);
for (i = 0; i < hw->ports; i++) {
@@ -3862,7 +3854,7 @@ static int sky2_resume(struct pci_dev *p
}
netif_poll_enable(hw->dev[0]);
- sky2_idle_start(hw);
+
return 0;
out:
dev_err(&pdev->dev, "resume failed (%d)\n", err);
@@ -3879,7 +3871,6 @@ static void sky2_shutdown(struct pci_dev
if (!hw)
return;
- del_timer_sync(&hw->idle_timer);
netif_poll_disable(hw->dev[0]);
for (i = 0; i < hw->ports; i++) {
--- a/drivers/net/sky2.h 2007-08-21 10:59:11.000000000 -0700
+++ b/drivers/net/sky2.h 2007-09-28 09:13:15.000000000 -0700
@@ -1921,7 +1921,7 @@ struct sky2_hw {
u32 st_idx;
dma_addr_t st_dma;
- struct timer_list idle_timer;
+ struct timer_list watchdog_timer;
struct work_struct restart_work;
int msi;
wait_queue_head_t msi_wait;
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 0/3] sky2: patches for 2.6.22.y
From: Stephen Hemminger @ 2007-09-28 16:48 UTC (permalink / raw)
To: Krzysztof Oledzki, Greg KH; +Cc: stable, netdev
Fixes for power regression, VLAN and resume problems.
These are all in 2.6.23.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 3/3] sky2: fix transmit state on resume
From: Stephen Hemminger @ 2007-09-28 16:48 UTC (permalink / raw)
To: Krzysztof Oledzki, Greg KH; +Cc: stable, netdev
In-Reply-To: <20070928164811.387831540@linux-foundation.org>
[-- Attachment #1: sky2-tx-sum-resume.patch --]
[-- Type: text/plain, Size: 1190 bytes --]
After resume, driver has reset the chip so the current state
of transmit checksum offload state machine and DMA state machine
will be undefined.
The fix is to set the state so that first Tx will set MSS and offset
values.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-09-28 09:21:26.000000000 -0700
+++ b/drivers/net/sky2.c 2007-09-28 09:21:37.000000000 -0700
@@ -831,6 +831,20 @@ static inline struct sky2_tx_le *get_tx_
return le;
}
+static void tx_init(struct sky2_port *sky2)
+{
+ struct sky2_tx_le *le;
+
+ sky2->tx_prod = sky2->tx_cons = 0;
+ sky2->tx_tcpsum = 0;
+ sky2->tx_last_mss = 0;
+
+ le = get_tx_le(sky2);
+ le->addr = 0;
+ le->opcode = OP_ADDR64 | HW_OWNER;
+ sky2->tx_addr64 = 0;
+}
+
static inline struct tx_ring_info *tx_le_re(struct sky2_port *sky2,
struct sky2_tx_le *le)
{
@@ -1244,7 +1258,8 @@ static int sky2_up(struct net_device *de
GFP_KERNEL);
if (!sky2->tx_ring)
goto err_out;
- sky2->tx_prod = sky2->tx_cons = 0;
+
+ tx_init(sky2);
sky2->rx_le = pci_alloc_consistent(hw->pdev, RX_LE_BYTES,
&sky2->rx_le_map);
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: e1000 tcp checksum incorrect, x86 64b
From: Rick Jones @ 2007-09-28 16:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jon Smirl, netdev
In-Reply-To: <E1Ib79E-0006CN-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
>
>>App is writing seven bytes to the socket. Socket write timeout expires
>>and the seven bytes are sent. The checksum is not getting inserted
>>into the packet. It is set to a constant 0x8389 instead of the right
>>value. App is gmpc 0.15.4.95, Revision: 6794
>>
>>Attached Wireshark packet trace show the problem. e1000 is 192.168.1.4
>>64bit, Q6600. Dell Dimension 9200
>
>
> Wireshark is broken. It needs to know TP_STATUS_CSUMNOTREADY
> means that the checksum is partial and will only be completed
> when the hardware sends the packet out.
>
> Alternatively disable checksum offload with ethtool.
Or take the packet traces "outboard" of the NIC somewhere/somehow.
What problem(s) led to your taking the packet trace in the first place?
rick jones
^ permalink raw reply
* Re: [PKT_SCHED]: Add stateless NAT
From: Patrick McHardy @ 2007-09-28 16:31 UTC (permalink / raw)
To: David Miller; +Cc: johnpol, herbert, netdev, kuznet, hadi
In-Reply-To: <20070927.125239.129764503.davem@davemloft.net>
David Miller wrote:
> I still think the nf_*() prefixes should all go and the extern
> prototypes should go into an independant header file.
>
> These are not netfilter routines, they are "INET" helpers.
Agreed. Evgeniy, can you send a new patch for this?
> And we should make similar treatment for all of the ipv6
> packet parser helper functions that ipv6 netfilter needs.
I'll look into that.
^ permalink raw reply
* /proc/net/ bad hard links count [Was: 2.6.23-rc8-mm2]
From: Jiri Slaby @ 2007-09-28 16:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Eric Biederman
In-Reply-To: <20070927022220.c76a7a6e.akpm@linux-foundation.org>
On 09/27/2007 11:22 AM, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
# find /proc >/dev/null
find: WARNING: Hard link count is wrong for /proc/net: this may be a bug in your
filesystem driver. Automatically turning on find's -noleaf option. Earlier
results may have failed to include directories that should have been searched.
# stat net
File: `net'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 4026531864 Links: 2
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-09-28 18:21:24.651209759 +0200
Modify: 2007-09-28 18:21:24.651209759 +0200
Change: 2007-09-28 18:21:24.651209759 +0200
# stat net/
File: `net/'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 4026531909 Links: 4
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-09-28 18:26:48.813048220 +0200
Modify: 2007-09-28 18:26:48.813048220 +0200
Change: 2007-09-28 18:26:48.813048220 +0200
hmm, this is some kind of weirdness :)
regards,
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
^ permalink raw reply
* Re: [PATCH 2/7] CAN: Add PF_CAN core module
From: Thomas Gleixner @ 2007-09-28 16:27 UTC (permalink / raw)
To: David Miller; +Cc: urs, shemminger, netdev, kaber, joe, oliver, oliver.hartkopp
In-Reply-To: <20070925.140910.41653604.davem@davemloft.net>
On Tue, 2007-09-25 at 14:09 -0700, David Miller wrote:
> > > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > > sure that the other CAN protocol can not reuse your infrastructure.
> >
> > We don't want to force other CAN protocol implementations to be GPL
> > also. AFAIR from discussions on LKML, it was mostly agreed upon that
> > this decision is up to the authors of code.
>
> To a certain extent, yes.
>
> However, the core issue is whether anyone who uses the symbol
> is creating a derivative work. If it is pretty clear that this
> is the case, you really should mark the exported symbols GPL.
>
> In my opinion, in this case it is pretty clear that any use of
> these new symbols would be a derivative work and therefore they
> all should be marked GPL.
Hmm, the code in question is dual licensed. So it's not that clear to
me.
But it's a legal grey area anyway if somebody loads non GPL code into
the kernel, though IANAL and we can spend years on this discussion.
I'm not inclined either way and we really should not make this a
religious question whether that code goes in or not, especially not when
we granted the mac80211 to export everything w/o _GPL suffix not too
long ago.
Thanks,
tglx
^ permalink raw reply
* [IPV6] Fix ICMPv6 redirect handling with target multicast address
From: Brian Haley @ 2007-09-28 16:26 UTC (permalink / raw)
To: David Miller, YOSHIFUJI Hideaki; +Cc: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it. The problem is in this code in
ndisc_redirect_rcv():
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not
link-local.\n");
return;
}
This second check will succeed if the Target address is, for example,
FF02::1 because it has link-local scope. Instead, it should be checking
if it's a unicast link-local address, as stated in RFC 2461/4861 Section
8.1:
- The ICMP Target Address is either a link-local address (when
redirected to a router) or the same as the ICMP Destination
Address (when redirected to the on-link destination).
I know this doesn't explicitly say unicast link-local address, but it's
implied.
This bug is preventing Linux kernels from achieving IPv6 Logo Phase II
certification because of a recent error that was found in the TAHI test
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the
multicast address in the Destination field instead of Target field, so
we were passing the test. This won't be the case anymore.
The patch below fixes this problem, and also fixes ndisc_send_redirect()
to not send an invalid redirect with a multicast address in the Target
field. I re-ran the TAHI Neighbor Discovery section to make sure Linux
passes all 245 tests now.
-Brian
Signed-off-by: Brian Haley <brian.haley@hp.com>
[-- Attachment #2: ipv6.redirect.patch --]
[-- Type: text/x-patch, Size: 1313 bytes --]
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 31b3f1b..4f47d29 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -368,6 +368,11 @@ static inline int ipv6_prefix_equal(const struct in6_addr *a1,
prefixlen);
}
+static inline int ipv6_addr_linklocal(const struct in6_addr *a)
+{
+ return ((a->s6_addr32[0] & htonl(0xFFC00000)) == htonl(0xFE800000));
+}
+
static inline int ipv6_addr_any(const struct in6_addr *a)
{
return ((a->s6_addr32[0] | a->s6_addr32[1] |
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 74c4d8d..8f953a7 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1267,7 +1267,7 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
- } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
+ } else if (!ipv6_addr_linklocal(target)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not link-local.\n");
return;
@@ -1343,7 +1343,7 @@ void ndisc_send_redirect(struct sk_buff *skb, struct neighbour *neigh,
}
if (!ipv6_addr_equal(&ipv6_hdr(skb)->daddr, target) &&
- !(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
+ !ipv6_addr_linklocal(target)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not link-local.\n");
return;
^ permalink raw reply related
* Re: [PATCH] sb1250-mac: Driver model & phylib update
From: Maciej W. Rozycki @ 2007-09-28 16:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, netdev, linux-mips, linux-kernel
In-Reply-To: <20070924095559.c81f7061.akpm@linux-foundation.org>
On Mon, 24 Sep 2007, Andrew Morton wrote:
> > Well, this is against Jeff's netdev-2.6 tree which hopefully is not as
> > crufty as Linus's old mainline; if it is not possible to queue this change
> > for 2.6.25 or suchlike, then I will try to resubmit later.
>
> Most of Jeff's netdev tree got dumped into Dave's net-2.6.24 tree. That's
> the one you want to be raising patches against for the next few weeks.
OK, thanks for clarification. Then both patches already submitted:
patch-netdev-2.6.23-rc6-20070920-sb1250-mac-typedef-9
patch-netdev-2.6.23-rc6-20070920-sb1250-mac-29
apply cleanly to net-2.6.24 one on top of the other in this order.
I can resubmit them -- where? netdev? As I say I am fine with 2.6.25 as
the target.
Maciej
^ permalink raw reply
* Re: [stable] Upgrading 2.6.21.7->2.6.22.9 kills my network (sky2): sky2 eth0: rx error, status 0x402300 length 60
From: Greg KH @ 2007-09-28 16:13 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: Stephen Hemminger, Linux Netdev List, stable
In-Reply-To: <Pine.LNX.4.64.0709281304590.17152@bizon.gios.gov.pl>
On Fri, Sep 28, 2007 at 01:11:27PM +0200, Krzysztof Oledzki wrote:
>
>
> On Fri, 28 Sep 2007, Krzysztof Oledzki wrote:
>
>>
>>
>> On Fri, 28 Sep 2007, Krzysztof Oledzki wrote:
>>
>>> Hello,
>>> After upgrading my kernel from 2.6.21.7 to 2.6.22.9 my 88E8053 no longer
>>> works:
>>
>> Small update: 2.6.22.9 with sky2.c/sky2.h from 2.4.22.4 works without any
>> problems.
>
> Final update.
>
> Reverting this patch:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff_plain;h=8c07a8e30ba8a2e0831da4b134202598435f8358
> solved my problem.
>
> I also found this one:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d6532232cd3de79c852685823a9c52f723816d0a
>
> Could it go to a next -stable ASAP, please? It seems that 2.6.22.5-2.6.22.9
> kernels have broken sky2 if used with vlans. :( Such regression in a
> -stable kernel isn't nice. :(
So should we just apply the second patch? I'll let Stephen tell us what
we should do :)
thanks,
greg k-h
^ permalink raw reply
* Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
From: Cedric Le Goater @ 2007-09-28 15:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Ilpo Järvinen, David Miller
In-Reply-To: <20070927022220.c76a7a6e.akpm@linux-foundation.org>
Hello !
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
I just found that warning in my logs. It seems that it's been
happening since rc7-mm1 at least.
Thanks !
C.
WARNING: at /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314 tcp_fastretrans_alert()
Call Trace:
<IRQ> [<ffffffff8040fdc3>] tcp_ack+0xcd6/0x1894
[<ffffffff80411c79>] tcp_data_queue+0x5be/0xae7
[<ffffffff80412b54>] tcp_rcv_established+0x61f/0x6df
[<ffffffff80254146>] __lock_acquire+0x8a1/0xf1b
[<ffffffff80419cfd>] tcp_v4_do_rcv+0x3e/0x394
[<ffffffff8041a66f>] tcp_v4_rcv+0x61c/0x9a9
[<ffffffff803ff1e3>] ip_local_deliver+0x1da/0x2a4
[<ffffffff803ffb4e>] ip_rcv+0x583/0x5c9
[<ffffffff8046d33f>] packet_rcv_spkt+0x19a/0x1a8
[<ffffffff803e081c>] netif_receive_skb+0x2cf/0x2f5
[<ffffffff88042505>] :tg3:tg3_poll+0x65d/0x8a4
[<ffffffff803e09e8>] net_rx_action+0xb8/0x191
[<ffffffff8023a927>] __do_softirq+0x5f/0xe0
[<ffffffff8020c98c>] call_softirq+0x1c/0x28
[<ffffffff8020e9c3>] do_softirq+0x3b/0xb8
[<ffffffff8023aa1e>] irq_exit+0x4e/0x50
[<ffffffff8020e7df>] do_IRQ+0xbd/0xd7
[<ffffffff80209cb9>] mwait_idle+0x0/0x4d
[<ffffffff8020bce6>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff80209cfc>] mwait_idle+0x43/0x4d
[<ffffffff802099fb>] enter_idle+0x22/0x24
[<ffffffff80209c4f>] cpu_idle+0x9d/0xc0
[<ffffffff80476a91>] rest_init+0x55/0x57
[<ffffffff80630815>] start_kernel+0x2d6/0x2e2
[<ffffffff80630134>] _sinittext+0x134/0x13b
^ permalink raw reply
* Re: Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Jeff Garzik @ 2007-09-28 15:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <7F0D5001-BDDC-48A3-A414-2D3C1CE1574B@kernel.crashing.org>
Kumar Gala wrote:
> Begin forwarded message:
>
>> From: Jochen Friedrich <jochen@scram.de>
>> Date: September 24, 2007 12:15:35 PM CDT
>> To: linuxppc-embedded@ozlabs.org
>> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
>> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
>
> Jeff,
>
> Please pick up for 2.6.23 if you don't mind.
Please send an apply-able patch...
Jeff, off to bed
^ permalink raw reply
* Re: 2.6.23-rc8: cannot make netconsole work
From: Matt Mackall @ 2007-09-28 15:32 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: netdev, linux-kernel
In-Reply-To: <200709281327.59317.arvidjaar@mail.ru>
On Fri, Sep 28, 2007 at 01:27:55PM +0400, Andrey Borzenkov wrote:
> I finally decided to try netconsole in attempt to get some more information
> why my system does not resume (but that is different story). But I cannot
> make it work - it does load but I see no traffic flowing ever. This is
> notebook with e100 driver and it works just fine for normal traffic.
> netconsole is currently compiled as module, loading it I get:
>
> sudo modprobe netconsole netconsole=@/eth0,@/
>
> [ 2395.838094] netconsole: local port 6665
> [ 2395.838126] netconsole: interface eth0
> [ 2395.838132] netconsole: remote port 6666
> [ 2395.838140] netconsole: remote IP 0.0.0.0
> [ 2395.838150] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
> [ 2395.838175] netconsole: local IP 192.168.1.8
> [ 2395.843798] console [netcon0] enabled
> [ 2395.844722] netconsole: network logging started
>
> but I cannot see any packet flowing via eth0 not can I catch anything on
> remote side using netcat. This does not work when I add explicitly source and
> target addresses either:
>
> pts/0}% sudo modprobe netconsole netconsole=@192.168.1.8/eth0,@192.168.1.5/
> {pts/0}% dmesg | tail
> [ 2427.128947] device eth0 left promiscuous mode
> [ 2427.129005] audit(1190970818.972:5): dev=eth0 prom=0 old_prom=256
> auid=4294967295
> [ 2541.831721] netconsole: local port 6665
> [ 2541.831756] netconsole: local IP 192.168.1.8
> [ 2541.831763] netconsole: interface eth0
> [ 2541.831769] netconsole: remote port 6666
> [ 2541.831776] netconsole: remote IP 192.168.1.5
> [ 2541.831787] netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
> [ 2541.838832] console [netcon0] enabled
> [ 2541.839964] netconsole: network logging started
What is your console log level set to? If the messages don't come out
on the local console, they won't get sent out the network either.
Fedora at least defaults to hiding most messages. Adding 'debug' to
your kernel command line will change that.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Fwd: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
From: Kumar Gala @ 2007-09-28 15:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-ppc-embedded ((((E-Mail))))
In-Reply-To: <46F7F0B7.2090205@scram.de>
Begin forwarded message:
> From: Jochen Friedrich <jochen@scram.de>
> Date: September 24, 2007 12:15:35 PM CDT
> To: linuxppc-embedded@ozlabs.org
> Cc: linux-kernel@vger.kernel.org, Marcelo Tosatti <marcelo@kvack.org>
> Subject: [PATCH#2 3/4] [PPC] Compile fix for 8xx CPM Ehernet driver
Jeff,
Please pick up for 2.6.23 if you don't mind.
- k
>
>
> Add #include <asm/cacheflush.h> for flush_dcache_range
> to make the driver compile again.
>
> CC arch/ppc/8xx_io/enet.o
> arch/ppc/8xx_io/enet.c: In function 'scc_enet_start_xmit':
> arch/ppc/8xx_io/enet.c:240: error: implicit declaration of function
> 'flush_dcache_range'
> make[1]: *** [arch/ppc/8xx_io/enet.o] Error 1
> make: *** [arch/ppc/8xx_io] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/ppc/8xx_io/enet.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
> index 703d47e..eace3bc 100644
> --- a/arch/ppc/8xx_io/enet.c
> +++ b/arch/ppc/8xx_io/enet.c
> @@ -44,6 +44,7 @@
> #include <asm/mpc8xx.h>
> #include <asm/uaccess.h>
> #include <asm/commproc.h>
> +#include <asm/cacheflush.h>
>
> /*
> * Theory of Operation
>
^ permalink raw reply
* Re: [RFC/PATCH 3/3] UDP memory usage accounting (take 2): measurement
From: Evgeniy Polyakov @ 2007-09-28 14:37 UTC (permalink / raw)
To: Satoshi OSHIMA
Cc: Andi Kleen, netdev, 吉藤 英明,
Yumiko SUGITA, 青木@RedHat
In-Reply-To: <46FD048B.9010409@hitachi.com>
On Fri, Sep 28, 2007 at 10:41:31PM +0900, Satoshi OSHIMA (satoshi.oshima.fk@hitachi.com) wrote:
> This patch introduces memory usage measurement for UDP.
>
> These 3 points were updated.
>
> - UDP specific codes in IP layer were removed.
>
> - atomic_sub() in a loop was removed
>
> - accounting during socket destruction
Another approach is to account only at the highest UDP layer and having
datagram skb destructor just like it is done in TCP, but this approach
is also resonable.
I already told that patches 1 and 3 have broken indent, please fix that.
A hint: when you are about to submit something network related for inclusion,
and strongly believes it is ready, it can be a not that bad idea to add
David Miller <davem@davemloft.net> to copy list, he can complain about
backlog and so on, but will read you mail twice :) but do not tell anyone.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC/PATCH 0/3] UDP memory usage accounting
From: Satoshi OSHIMA @ 2007-09-28 13:26 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, haoki, ?? ??, Yumiko SUGITA
In-Reply-To: <20070921125843.GA15810@2ka.mipt.ru>
Hi,
Thank you for your comment.
Evgeniy Polyakov wrote:
> Hi.
>
> On Fri, Sep 21, 2007 at 09:18:07PM +0900, Satoshi OSHIMA
(satoshi.oshima.fk@hitachi.com) wrote:
>> This patch set try to introduce memory usage accounting for
>> UDP(currently ipv4 only).
>>
>> Currently, memory usage of UDP can be observed as the sam of
>> usage of tx_queue and rx_queue. But I believe that the system
>> wide accounting is usefull when heavy loaded condition.
>>
>> In the next step, I would like to add memory usage quota
>> for UDP to avoid unlimited memory consumption problem
>> under DDOS attack.
>
> Could you please desribed such attack in more details?
> Each UDP socket has its queue length which can not be exceeded
> (roughly), no new sockets are created when remote side sends a packet
> (like after special steps in TCP), so where is possibility to eat all
> the mem?
For example, sk_buff is put on the slab and
slab can be acquired only from ZONE_NORMAL in i386.
In such case, from 300 to 500MB memory consumption will
be fatal. Users can easily open 1000 sockets per process
under default ulimit. If such sockets hold messages but
user processes don't receive it. Almost all slab will
be occupied by sk_buff.
>> This patch set is for 2.6.23-rc7.
>
> I seriously doubt you want to put udp specific hacks and zillions of
> atomic ops all around the code just to know exact number of bytes eaten
> for UDP.
> Please use udp specific code (like udp_sendmsg()) for proper accounting
> if you need that, but not hacks in generic ip code.
I couldn't find the way to account UDP memory consumption
in UDP layer.
In receive path, accounting can be done in UDP layer
because sk_buff is marked for UDP in UDP layer and it is
released in UDP layer.
In send path, sk_buff is aquired in IP layer and also
released in IP layer. Especially, there is a possibility
of "appending data" to the preceding sk_buff in send
queue.
On the other hand, I agree that UDP specific code
in IP layer is not preferable. So I generalize UDP
specific code in IP layer in take 2.
Could you take a look at my take 2 patch set?
Satoshi Oshima
^ permalink raw reply
* [RFC/PATCH 3/3] UDP memory usage accounting (take 2): measurement
From: Satoshi OSHIMA @ 2007-09-28 13:41 UTC (permalink / raw)
To: Andi Kleen, Evgeniy Polyakov, netdev
Cc: 吉藤 英明, Yumiko SUGITA,
"青木@RedHat"
This patch introduces memory usage measurement for UDP.
These 3 points were updated.
- UDP specific codes in IP layer were removed.
- atomic_sub() in a loop was removed
- accounting during socket destruction
signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
Index: 2.6.23-rc8-udp_limit/net/ipv4/ip_output.c
===================================================================
--- 2.6.23-rc8-udp_limit.orig/net/ipv4/ip_output.c
+++ 2.6.23-rc8-udp_limit/net/ipv4/ip_output.c
@@ -743,6 +743,8 @@ static inline int ip_ufo_append_data(str
/* specify the length of each IP datagram fragment*/
skb_shinfo(skb)->gso_size = mtu - fragheaderlen;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
__skb_queue_tail(&sk->sk_write_queue, skb);
return 0;
@@ -924,6 +926,9 @@ alloc_new_skb:
}
if (skb == NULL)
goto error;
+ if (sk->sk_prot->memory_allocated)
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
/*
* Fill in the control structures
@@ -1023,6 +1028,8 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
skb->truesize += PAGE_SIZE;
atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc);
+ if (sk->sk_prot->memory_allocated)
+ atomic_inc(sk->sk_prot->memory_allocated);
} else {
err = -EMSGSIZE;
goto error;
@@ -1123,7 +1130,9 @@ ssize_t ip_append_page(struct sock *sk,
if (unlikely(!skb)) {
err = -ENOBUFS;
goto error;
- }
+ } else if (sk->sk_prot->memory_allocated)
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
/*
* Fill in the control structures
@@ -1152,6 +1161,8 @@ ssize_t ip_append_page(struct sock *sk,
/*
* Put the packet on the pending queue.
*/
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
__skb_queue_tail(&sk->sk_write_queue, skb);
continue;
}
@@ -1202,13 +1213,14 @@ int ip_push_pending_frames(struct sock *
struct iphdr *iph;
__be16 df = 0;
__u8 ttl;
- int err = 0;
+ int err = 0, send_page_size;
if ((skb = __skb_dequeue(&sk->sk_write_queue)) == NULL)
goto out;
tail_skb = &(skb_shinfo(skb)->frag_list);
/* move skb->data to ip header from ext header */
+ send_page_size = sk_datagram_pages(skb->truesize);
if (skb->data < skb_network_header(skb))
__skb_pull(skb, skb_network_offset(skb));
while ((tmp_skb = __skb_dequeue(&sk->sk_write_queue)) != NULL) {
@@ -1218,6 +1230,7 @@ int ip_push_pending_frames(struct sock *
skb->len += tmp_skb->len;
skb->data_len += tmp_skb->len;
skb->truesize += tmp_skb->truesize;
+ send_page_size += sk_datagram_pages(tmp_skb->truesize);
__sock_put(tmp_skb->sk);
tmp_skb->destructor = NULL;
tmp_skb->sk = NULL;
@@ -1269,6 +1282,8 @@ int ip_push_pending_frames(struct sock *
/* Netfilter gets whole the not fragmented skb. */
err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
skb->dst->dev, dst_output);
+ if (sk->sk_prot->memory_allocated)
+ atomic_sub(send_page_size, sk->sk_prot->memory_allocated);
if (err) {
if (err > 0)
err = inet->recverr ? net_xmit_errno(err) : 0;
@@ -1298,9 +1313,15 @@ void ip_flush_pending_frames(struct sock
{
struct inet_sock *inet = inet_sk(sk);
struct sk_buff *skb;
+ int num_flush_mem = 0;
- while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL)
+ while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) {
+ num_flush_mem += sk_datagram_pages(skb->truesize);
kfree_skb(skb);
+ }
+
+ if (sk->sk_prot->memory_allocated)
+ atomic_sub(num_flush_mem, sk->sk_prot->memory_allocated);
inet->cork.flags &= ~IPCORK_OPT;
kfree(inet->cork.opt);
Index: 2.6.23-rc8-udp_limit/net/ipv4/udp.c
===================================================================
--- 2.6.23-rc8-udp_limit.orig/net/ipv4/udp.c
+++ 2.6.23-rc8-udp_limit/net/ipv4/udp.c
@@ -887,6 +887,9 @@ try_again:
err = ulen;
out_free:
+ atomic_sub(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
+
skb_free_datagram(sk, skb);
out:
return err;
@@ -894,6 +897,9 @@ out:
csum_copy_err:
UDP_INC_STATS_BH(UDP_MIB_INERRORS, is_udplite);
+ atomic_sub(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
+
skb_kill_datagram(sk, skb, flags);
if (noblock)
@@ -1019,6 +1025,9 @@ int udp_queue_rcv_skb(struct sock * sk,
goto drop;
}
+ atomic_add(sk_datagram_pages(skb->truesize),
+ sk->sk_prot->memory_allocated);
+
UDP_INC_STATS_BH(UDP_MIB_INDATAGRAMS, up->pcflag);
return 0;
@@ -1443,6 +1452,7 @@ struct proto udp_prot = {
.hash = udp_lib_hash,
.unhash = udp_lib_unhash,
.get_port = udp_v4_get_port,
+ .memory_allocated = &udp_memory_allocated,
.obj_size = sizeof(struct udp_sock),
#ifdef CONFIG_COMPAT
.compat_setsockopt = compat_udp_setsockopt,
Index: 2.6.23-rc8-udp_limit/net/ipv4/af_inet.c
===================================================================
--- 2.6.23-rc8-udp_limit.orig/net/ipv4/af_inet.c
+++ 2.6.23-rc8-udp_limit/net/ipv4/af_inet.c
@@ -126,13 +126,41 @@ extern void ip_mc_drop_socket(struct soc
static struct list_head inetsw[SOCK_MAX];
static DEFINE_SPINLOCK(inetsw_lock);
+/**
+ * __skb_queue_purge_and_sub_memory_allocated
+ * - empty a list and subtruct memory allocation counter
+ * @sk: sk
+ * @list: list to empty
+ * Delete all buffers on an &sk_buff list and subtruct the
+ * turesize of the sk_buff for memory accounting. Each buffer
+ * is removed from the list and one reference dropped. This
+ * function does not take the list lock and the caller must
+ * hold the relevant locks to use it.
+ */
+void __skb_queue_purge_and_sub_memory_allocated(struct sock *sk,
+ struct sk_buff_head *list)
+{
+ struct sk_buff *skb;
+ int purged_skb_size = 0;
+ while ((skb = __skb_dequeue(list)) != NULL) {
+ purged_skb_size += sk_datagram_pages(skb->truesize);
+ kfree_skb(skb);
+ }
+ atomic_sub(purged_skb_size, sk->sk_prot->memory_allocated);
+}
+
/* New destruction routine */
void inet_sock_destruct(struct sock *sk)
{
struct inet_sock *inet = inet_sk(sk);
- __skb_queue_purge(&sk->sk_receive_queue);
+ if (sk->sk_prot->memory_allocated && sk->sk_type != SOCK_STREAM)
+ __skb_queue_purge_and_sub_memory_allocated(sk,
+ &sk->sk_receive_queue);
+ else
+ __skb_queue_purge(&sk->sk_receive_queue);
+
__skb_queue_purge(&sk->sk_error_queue);
if (sk->sk_type == SOCK_STREAM && sk->sk_state != TCP_CLOSE) {
^ permalink raw reply
* [RFC/PATCH 2/3] UDP memory usage accounting: accounting unit and variable
From: Satoshi OSHIMA @ 2007-09-28 13:40 UTC (permalink / raw)
To: Andi Kleen, Evgeniy Polyakov, netdev
Cc: Yumiko SUGITA, "青木@RedHat",
吉藤 英明
This patch introduces global variable for UDP memory accounting.
The unit is page.
signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
Index: 2.6.23-rc3-udp_limit/include/net/sock.h
===================================================================
--- 2.6.23-rc3-udp_limit.orig/include/net/sock.h
+++ 2.6.23-rc3-udp_limit/include/net/sock.h
@@ -723,6 +723,13 @@ static inline int sk_stream_wmem_schedul
sk_stream_mem_schedule(sk, size, 0);
}
+#define SK_DATAGRAM_MEM_QUANTUM ((int)PAGE_SIZE)
+
+static inline int sk_datagram_pages(int amt)
+{
+ return DIV_ROUND_UP(amt, SK_DATAGRAM_MEM_QUANTUM);
+}
+
/* Used by processes to "lock" a socket state, so that
* interrupts and bottom half handlers won't change it
* from under us. It essentially blocks any incoming
Index: 2.6.23-rc3-udp_limit/include/net/udp.h
===================================================================
--- 2.6.23-rc3-udp_limit.orig/include/net/udp.h
+++ 2.6.23-rc3-udp_limit/include/net/udp.h
@@ -65,6 +65,8 @@ extern rwlock_t udp_hash_lock;
extern struct proto udp_prot;
+extern atomic_t udp_memory_allocated;
+
struct sk_buff;
/*
Index: 2.6.23-rc3-udp_limit/net/ipv4/proc.c
===================================================================
--- 2.6.23-rc3-udp_limit.orig/net/ipv4/proc.c
+++ 2.6.23-rc3-udp_limit/net/ipv4/proc.c
@@ -66,7 +66,8 @@ static int sockstat_seq_show(struct seq_
fold_prot_inuse(&tcp_prot), atomic_read(&tcp_orphan_count),
tcp_death_row.tw_count, atomic_read(&tcp_sockets_allocated),
atomic_read(&tcp_memory_allocated));
- seq_printf(seq, "UDP: inuse %d\n", fold_prot_inuse(&udp_prot));
+ seq_printf(seq, "UDP: inuse %d mem %d\n", fold_prot_inuse(&udp_prot),
+ atomic_read(&udp_memory_allocated));
seq_printf(seq, "UDPLITE: inuse %d\n", fold_prot_inuse(&udplite_prot));
seq_printf(seq, "RAW: inuse %d\n", fold_prot_inuse(&raw_prot));
seq_printf(seq, "FRAG: inuse %d memory %d\n", ip_frag_nqueues,
Index: 2.6.23-rc3-udp_limit/net/ipv4/udp.c
===================================================================
--- 2.6.23-rc3-udp_limit.orig/net/ipv4/udp.c
+++ 2.6.23-rc3-udp_limit/net/ipv4/udp.c
@@ -113,6 +113,10 @@ DEFINE_SNMP_STAT(struct udp_mib, udp_sta
struct hlist_head udp_hash[UDP_HTABLE_SIZE];
DEFINE_RWLOCK(udp_hash_lock);
+atomic_t udp_memory_allocated;
+
+EXPORT_SYMBOL(udp_memory_allocated);
+
static int udp_port_rover;
static inline int __udp_lib_lport_inuse(__u16 num, struct hlist_head udptable[])
^ permalink raw reply
* [RFC/PATCH 1/3] UDP memory usage accounting (take 2): fix send buffer check
From: Satoshi OSHIMA @ 2007-09-28 13:37 UTC (permalink / raw)
To: Andi Kleen, Evgeniy Polyakov, netdev
Cc: Yumiko SUGITA, "青木@RedHat",
吉藤 英明
This patch introduces sndbuf size check before
memory allcation for send buffer.
signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
Index: 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
===================================================================
--- 2.6.23-rc7-udp_limit.orig/net/ipv4/ip_output.c
+++ 2.6.23-rc7-udp_limit/net/ipv4/ip_output.c
@@ -1004,6 +1004,11 @@ alloc_new_skb:
frag = &skb_shinfo(skb)->frags[i];
}
} else if (i < MAX_SKB_FRAGS) {
+ if (atomic_read(&sk->sk_wmem_alloc) + PAGE_SIZE
+ > 2 * sk->sk_sndbuf) {
+ err = -ENOBUFS;
+ goto error;
+ }
if (copy > PAGE_SIZE)
copy = PAGE_SIZE;
page = alloc_pages(sk->sk_allocation, 0);
^ permalink raw reply
* [PATCH] mv643xx_eth: Check ETH_INT_CAUSE_STATE bit
From: Dale Farnsworth @ 2007-09-28 13:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Martyn Welch
Commit 468d09f8946d40228c56de26fe4874b2f98067ed masked the "state"
interrupt (bit 20 of the cause register). This results in Radstone's
PPC7D repeatedly re-entering the interrupt routine, locking up the
board. The following patch returns the required handling for this
interrupt.
Signed-off-by: Martyn Welch <martyn.welch@radstone.co.uk>
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
Jeff, this is a bug fix.
drivers/net/mv643xx_eth.c | 2 +-
drivers/net/mv643xx_eth.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 1799eee..1785d15 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -534,7 +534,7 @@ static irqreturn_t mv643xx_eth_int_handler(int irq, void *dev_id)
}
/* PHY status changed */
- if (eth_int_cause_ext & ETH_INT_CAUSE_PHY) {
+ if (eth_int_cause_ext & (ETH_INT_CAUSE_PHY | ETH_INT_CAUSE_STATE)) {
struct ethtool_cmd cmd;
if (mii_link_ok(&mp->mii)) {
diff --git a/drivers/net/mv643xx_eth.h b/drivers/net/mv643xx_eth.h
index 82f8c0c..565b966 100644
--- a/drivers/net/mv643xx_eth.h
+++ b/drivers/net/mv643xx_eth.h
@@ -64,7 +64,9 @@
#define ETH_INT_CAUSE_TX_ERROR (ETH_TX_QUEUES_ENABLED << 8)
#define ETH_INT_CAUSE_TX (ETH_INT_CAUSE_TX_DONE | ETH_INT_CAUSE_TX_ERROR)
#define ETH_INT_CAUSE_PHY 0x00010000
-#define ETH_INT_UNMASK_ALL_EXT (ETH_INT_CAUSE_TX | ETH_INT_CAUSE_PHY)
+#define ETH_INT_CAUSE_STATE 0x00100000
+#define ETH_INT_UNMASK_ALL_EXT (ETH_INT_CAUSE_TX | ETH_INT_CAUSE_PHY | \
+ ETH_INT_CAUSE_STATE)
#define ETH_INT_MASK_ALL 0x00000000
#define ETH_INT_MASK_ALL_EXT 0x00000000
^ permalink raw reply related
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