* [PATCH v3 00/12] l2tp: Introduce L2TPv3 support
From: James Chapman @ 2010-03-30 16:17 UTC (permalink / raw)
To: netdev
This patch series adds L2TPv3 support. It splits the existing pppol2tp
driver to separate its L2TP and PPP parts, then adds new L2TPv3
functionality. The patches implement a new socket family for L2TPv3 IP
encapsulation, expose virtual netdevices for each L2TPv3 ethernet
pseudowire and add a netlink interface.
The following drivers are provided:-
l2tp_core - L2TP driver core. Always required.
l2tp_ppp - L2TP PPP (PPPoL2TP). L2TPv2 and L2TPv3.
l2tp_eth - L2TPv3 ethernet pseudowire.
l2tp_ip - L2TPv3 IP encapsulation.
l2tp_netlink - L2TPv3 netlink API.
The combination of l2tp_core and l2tp_ppp provides
backwards-compatible L2TPv2 pppol2tp functionality. Userspace L2TPv2
applications using the existing pppol2tp driver should not need to
change.
The implementation is as I described in a previous posting to netdev,
archived at
http://marc.info/?l=linux-netdev&m=120845482320143&w=4. Unfortunately,
splitting the existing pppol2tp driver into l2tp_core and l2tp_ppp
makes the changes difficult to review. The split is needed to separate
PPP from L2TP, since in L2TPv3, protocols other than PPP can be
carried. I have organised the patches so that the split is done first,
with new features added in separate patches.
Relevant RFCs are:-
- http://www.ietf.org/rfc/rfc3931.txt (L2TPv3)
- http://www.ietf.org/rfc/rfc4719.txt (L2TPv3 ethernet pseudowire)
A patchset is available to iproute2 which adds a number of commands
for unmanaged L2TPv3 tunnels. This will be submitted separately.
TODO:-
- Add IP pseudowires. These carry only IP frames (no L2 header).
- Add VLAN pseudowires.
- Add L2TP tunnel switching.
- Add ATM pseudowires - RFC3355 and RFC4454.
Signed-off-by: James Chapman <jchapman@katalix.com>
Reviewed-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Changelog:-
v3 (this version)
- Use hash_32() instead of hash_long() for better efficiency on 64-bit
archs (Eric Dumazet)
- Add missing setting of sk->sk_no_check for the case when creating
kernel socket for the unmanaged tunnel case. (Eric Dumazet)
- Fix a dev_put leak for the case when user creates an ethernet
pseudowire with a specific device name and a device with that name
already exists. (Eric Dumazet)
- Use dev_forward_skb() in receive path of l2tp_eth driver.
v2 (29-mar-2010)
- Fix compile error when CONFIG_COMPAT is defined. Since l2tp_ip is
not a UDP socket, use compat_ip_[gs]etsockopt directly instead of
config_udp_[gs]etsockopt. (David Miller)
- Fix whitespace issues found by
git apply --check --whitespace=error-all (David Miller)
James Chapman (12):
l2tp: Relocate pppol2tp driver to new net/l2tp directory
l2tp: Split pppol2tp patch into separate l2tp and ppp parts
ppp: Add ppp_dev_name() exported function
l2tp: Add ppp device name to L2TP ppp session data
l2tp: Add L2TPv3 protocol support
l2tp: Update PPP-over-L2TP driver to work over L2TPv3
l2tp: Add L2TPv3 IP encapsulation (no UDP) support
netlink: Export genl_lock() API for use by modules
l2tp: Add netlink control API for L2TP
l2tp: Add L2TP ethernet pseudowire support
l2tp: Add support for static unmanaged L2TPv3 tunnels
l2tp: Update documentation
Documentation/networking/l2tp.txt | 233 +++
drivers/net/Kconfig | 7
drivers/net/Makefile | 2
drivers/net/ppp_generic.c | 19
drivers/net/pppol2tp.c | 2680 -------------------------------------
include/linux/genetlink.h | 8
include/linux/if_pppol2tp.h | 16
include/linux/if_pppox.h | 9
include/linux/l2tp.h | 164 ++
include/linux/ppp_channel.h | 3
net/Kconfig | 1
net/Makefile | 1
net/l2tp/Kconfig | 94 +
net/l2tp/Makefile | 11
net/l2tp/l2tp_core.c | 2016 ++++++++++++++++++++++++++++
net/l2tp/l2tp_core.h | 306 ++++
net/l2tp/l2tp_eth.c | 371 +++++
net/l2tp/l2tp_ip.c | 679 +++++++++
net/l2tp/l2tp_netlink.c | 844 ++++++++++++
net/l2tp/l2tp_ppp.c | 1602 ++++++++++++++++++++++
net/netlink/genetlink.c | 6
21 files changed, 6348 insertions(+), 2724 deletions(-)
delete mode 100644 drivers/net/pppol2tp.c
create mode 100644 include/linux/l2tp.h
create mode 100644 net/l2tp/Kconfig
create mode 100644 net/l2tp/Makefile
create mode 100644 net/l2tp/l2tp_core.c
create mode 100644 net/l2tp/l2tp_core.h
create mode 100644 net/l2tp/l2tp_eth.c
create mode 100644 net/l2tp/l2tp_ip.c
create mode 100644 net/l2tp/l2tp_netlink.c
create mode 100644 net/l2tp/l2tp_ppp.c
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-30 16:06 UTC (permalink / raw)
To: Templin, Fred L
Cc: Andi Kleen, Edgar E. Iglesias, Eric Dumazet, Rick Jones,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A649E05EABD5@XCH-NW-01V.nw.nos.boeing.com>
> Right again. Unlike IPv4, however, IPv6 does not allow
> in-the-network fragmentation. So when in doubt, apps
> that need to send isolated packets that may violate the
> path MTU should really perform host-based fragmentation
> with a maximum fragment size of 1280. Isn't there a
> socket option "IPV6_USE_MIN_MTU" that apps can use to
> force fragmentation on large packets (RFC3542)?
Thanks for the pointer. The option is right now only defined,
but not implemented. But yes it would help.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH 2/2] ath: fix code readability in regd.c
From: Luis de Bethencourt @ 2010-03-30 15:44 UTC (permalink / raw)
To: linville, lrodriguez
Cc: linux-wireless, netdev, linux-kernel, Luis de Bethencourt
In-Reply-To: <ath/regd.c>
This is a patch to the ath/regd.c file that fixes two code
readability issues. A space between to separate two defines
and the indentation inside the ath_redg_is_eeprom_valid
function.
Signed-off-by: Luis de Bethencourt <luisbg@ubuntu.com>
---
drivers/net/wireless/ath/regd.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 04abd1f..d5c2332 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -51,6 +51,7 @@
#define ATH9K_5GHZ_ALL ATH9K_5GHZ_5150_5350, \
ATH9K_5GHZ_5470_5850
+
/* This one skips what we call "mid band" */
#define ATH9K_5GHZ_NO_MIDBAND ATH9K_5GHZ_5150_5350, \
ATH9K_5GHZ_5725_5850
@@ -361,7 +362,7 @@ EXPORT_SYMBOL(ath_reg_notifier_apply);
static bool ath_regd_is_eeprom_valid(struct ath_regulatory *reg)
{
- u16 rd = ath_regd_get_eepromRD(reg);
+ u16 rd = ath_regd_get_eepromRD(reg);
int i;
if (rd & COUNTRY_ERD_FLAG) {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 15:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330142914.GA6840@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 05:01:47PM +0300, Timo Teräs wrote:
>> Since the exported function xfrm_policy_byid() can result in deletion
>> of socket policy, it's safer to leave this change in. This is can be
>> even triggered via xfrm_user since it does not check 'dir' for the
>> policy expired message it handles. Any custom module could do similar
>> harm.
>
> That's a bug. Socket policies should never be deleted by anyone
> other than the socket owner through a setsockopt.
Ok. I can remove the change to xfrm_sk_policy_insert() if you want.
I only added it because it's non-trivial to figure out if there's
any code path that could race. It's a great help for reader of the
code to see that it's correct even if it's not strictly needed.
My initial feeling is that the change produces better code as the
original 'old_pol' does not have to get stored and restored.
I'm fine either way.
I will also include a patch to fix the missing 'dir' check in
xfrm_user.
^ permalink raw reply
* Re: XT_ALIGN changed to use ALIGN breaks iproute2
From: Stephen Hemminger @ 2010-03-30 15:29 UTC (permalink / raw)
To: Ben Hutchings
Cc: Alexey Dobriyan, Andreas Henriksson, Patrick McHardy, jamal,
netdev
In-Reply-To: <1269961278.2174.11.camel@achroite.uk.solarflarecom.com>
On Tue, 30 Mar 2010 16:01:18 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Tue, 2010-03-30 at 16:15 +0300, Alexey Dobriyan wrote:
> > On Tue, Mar 30, 2010 at 12:28 PM, Andreas Henriksson <andreas@fatal.se> wrote:
> > > You updated the kernel header include/linux/netfilter/x_tables.h
> > > in torvalds/linux-2.6.git commit 42107f5009da223daa800d6da6904d77297ae829
> > > with the comment "Use ALIGN() macro while I'm at it for same types.".
> > >
> > > When this header was synced into iproute2 the build broke because the
> > > ALIGN macro apparently only is defined in kernel headers.
> > >
> > > (For iproute2 the problem was introduced in
> > > 8ecdcce08319d0e39b0d32c1d17db3f69d85a35c and found by Stephen
> > > and worked around in 609ceb807deba8e23 and edaaa11e5a3cf2c9c1a39)
> > >
> > > I'm guessing the problem in the iproute2 header sync is just a heads
> > > up for what's going to happen when distributions updates their
> > > system headers to match linux 2.6.33.
> > >
> > >
> > > Could someone who knows how the userspace version of the kernel
> > > headers are generated please find a suitable solution?
> >
> > We can export ALIGN to userspace, but the name is so generic,
> > so it's not clear what breakage more risky.
>
I put a hack in m_xt.c to keep iproute2 building.
But this is a temporary workaround until you guys figure out the
right answer.
--
^ permalink raw reply
* [PATCH net-next] net: remove redundant code
From: Eric Dumazet @ 2010-03-30 15:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
eth_type_trans(skb, netdev) does the "skb->dev = netdev;"
initialization, we can remove it from various network drivers.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/arm/w90p910_ether.c | 1 -
drivers/net/atl1c/atl1c_main.c | 1 -
drivers/net/atl1e/atl1e_main.c | 1 -
drivers/net/atlx/atl2.c | 1 -
drivers/net/bcm63xx_enet.c | 1 -
drivers/net/benet/be_main.c | 1 -
drivers/net/fec_mpc52xx.c | 1 -
drivers/net/greth.c | 1 -
drivers/net/ibm_newemac/core.c | 1 -
drivers/net/ks8851_mll.c | 1 -
drivers/net/ksz884x.c | 2 --
drivers/net/s6gmac.c | 1 -
drivers/net/tehuti.c | 1 -
drivers/net/xilinx_emaclite.c | 1 -
14 files changed, 15 deletions(-)
diff --git a/drivers/net/arm/w90p910_ether.c b/drivers/net/arm/w90p910_ether.c
index febd813..3302df2 100644
--- a/drivers/net/arm/w90p910_ether.c
+++ b/drivers/net/arm/w90p910_ether.c
@@ -743,7 +743,6 @@ static void netdev_rx(struct net_device *dev)
return;
}
- skb->dev = dev;
skb_reserve(skb, 2);
skb_put(skb, length);
skb_copy_to_linear_data(skb, data, length);
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 50dc531..a5508e1 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -1817,7 +1817,6 @@ rrs_checked:
atl1c_clean_rfd(rfd_ring, rrs, rfd_num);
skb_put(skb, length - ETH_FCS_LEN);
skb->protocol = eth_type_trans(skb, netdev);
- skb->dev = netdev;
atl1c_rx_checksum(adapter, skb, rrs);
if (unlikely(adapter->vlgrp) && rrs->word3 & RRS_VLAN_INS) {
u16 vlan;
diff --git a/drivers/net/atl1e/atl1e_main.c b/drivers/net/atl1e/atl1e_main.c
index 73302ae..7231b57 100644
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -1428,7 +1428,6 @@ static void atl1e_clean_rx_irq(struct atl1e_adapter *adapter, u8 que,
"Memory squeeze, deferring packet\n");
goto skip_pkt;
}
- skb->dev = netdev;
memcpy(skb->data, (u8 *)(prrs + 1), packet_size);
skb_put(skb, packet_size);
skb->protocol = eth_type_trans(skb, netdev);
diff --git a/drivers/net/atlx/atl2.c b/drivers/net/atlx/atl2.c
index 7061d71..199f2c9 100644
--- a/drivers/net/atlx/atl2.c
+++ b/drivers/net/atlx/atl2.c
@@ -421,7 +421,6 @@ static void atl2_intr_rx(struct atl2_adapter *adapter)
netdev->stats.rx_dropped++;
break;
}
- skb->dev = netdev;
memcpy(skb->data, rxd->packet, rx_size);
skb_put(skb, rx_size);
skb->protocol = eth_type_trans(skb, netdev);
diff --git a/drivers/net/bcm63xx_enet.c b/drivers/net/bcm63xx_enet.c
index 8cdcab7..37eb802 100644
--- a/drivers/net/bcm63xx_enet.c
+++ b/drivers/net/bcm63xx_enet.c
@@ -340,7 +340,6 @@ static int bcm_enet_receive_queue(struct net_device *dev, int budget)
}
skb_put(skb, len);
- skb->dev = dev;
skb->protocol = eth_type_trans(skb, dev);
priv->stats.rx_packets++;
priv->stats.rx_bytes += len;
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 50ea056..17282df 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -826,7 +826,6 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
- skb->dev = adapter->netdev;
vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl, vtp, rxcp);
vtm = AMAP_GET_BITS(struct amap_eth_rx_compl, vtm, rxcp);
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 0dbd721..704155e 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -435,7 +435,6 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
DMA_FROM_DEVICE);
length = status & BCOM_FEC_RX_BD_LEN_MASK;
skb_put(rskb, length - 4); /* length without CRC32 */
- rskb->dev = dev;
rskb->protocol = eth_type_trans(rskb, dev);
netif_rx(rskb);
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 2b9c1cb..c5e0d28 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -894,7 +894,6 @@ static int greth_rx_gbit(struct net_device *dev, int limit)
else
skb->ip_summed = CHECKSUM_NONE;
- skb->dev = dev;
skb->protocol = eth_type_trans(skb, dev);
dev->stats.rx_packets++;
netif_receive_skb(skb);
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index fb0ac6d..d8533a4 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1699,7 +1699,6 @@ static int emac_poll_rx(void *param, int budget)
skb_put(skb, len);
push_packet:
- skb->dev = dev->ndev;
skb->protocol = eth_type_trans(skb, dev->ndev);
emac_rx_csum(dev, skb, ctrl);
diff --git a/drivers/net/ks8851_mll.c b/drivers/net/ks8851_mll.c
index d3c6a77..ee3fe30 100644
--- a/drivers/net/ks8851_mll.c
+++ b/drivers/net/ks8851_mll.c
@@ -801,7 +801,6 @@ static void ks_rcv(struct ks_net *ks, struct net_device *netdev)
/* read data block including CRC 4 bytes */
ks_read_qmu(ks, (u16 *)skb->data, frame_hdr->len);
skb_put(skb, frame_hdr->len);
- skb->dev = netdev;
skb->protocol = eth_type_trans(skb, netdev);
netif_rx(skb);
} else {
diff --git a/drivers/net/ksz884x.c b/drivers/net/ksz884x.c
index b47a2b3..b843bf7 100644
--- a/drivers/net/ksz884x.c
+++ b/drivers/net/ksz884x.c
@@ -5043,8 +5043,6 @@ static inline int rx_proc(struct net_device *dev, struct ksz_hw* hw,
dma_buf->skb->data, packet_len);
} while (0);
- skb->dev = dev;
-
skb->protocol = eth_type_trans(skb, dev);
if (hw->rx_cfg & (DMA_RX_CSUM_UDP | DMA_RX_CSUM_TCP))
diff --git a/drivers/net/s6gmac.c b/drivers/net/s6gmac.c
index 45f2634..6b12524 100644
--- a/drivers/net/s6gmac.c
+++ b/drivers/net/s6gmac.c
@@ -396,7 +396,6 @@ static void s6gmac_rx_interrupt(struct net_device *dev)
} else {
skb_put(skb, (pfx >> S6_GMAC_BURST_POSTRD_LEN)
& S6_GMAC_BURST_POSTRD_LEN_MASK);
- skb->dev = dev;
skb->protocol = eth_type_trans(skb, dev);
skb->ip_summed = CHECKSUM_UNNECESSARY;
netif_rx(skb);
diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
index f549309..068a471 100644
--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -1303,7 +1303,6 @@ static int bdx_rx_receive(struct bdx_priv *priv, struct rxd_fifo *f, int budget)
priv->net_stats.rx_bytes += len;
skb_put(skb, len);
- skb->dev = priv->ndev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, priv->ndev);
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 1a74594..eaebba8 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -638,7 +638,6 @@ static void xemaclite_rx_handler(struct net_device *dev)
}
skb_put(skb, len); /* Tell the skb how much data we got */
- skb->dev = dev; /* Fill out required meta-data */
skb->protocol = eth_type_trans(skb, dev);
skb->ip_summed = CHECKSUM_NONE;
^ permalink raw reply related
* Re: XT_ALIGN changed to use ALIGN breaks iproute2
From: Ben Hutchings @ 2010-03-30 15:01 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Andreas Henriksson, Patrick McHardy, Stephen Hemminger, jamal,
netdev
In-Reply-To: <b6fcc0a1003300615k54092120nfb8b5378771657@mail.gmail.com>
On Tue, 2010-03-30 at 16:15 +0300, Alexey Dobriyan wrote:
> On Tue, Mar 30, 2010 at 12:28 PM, Andreas Henriksson <andreas@fatal.se> wrote:
> > You updated the kernel header include/linux/netfilter/x_tables.h
> > in torvalds/linux-2.6.git commit 42107f5009da223daa800d6da6904d77297ae829
> > with the comment "Use ALIGN() macro while I'm at it for same types.".
> >
> > When this header was synced into iproute2 the build broke because the
> > ALIGN macro apparently only is defined in kernel headers.
> >
> > (For iproute2 the problem was introduced in
> > 8ecdcce08319d0e39b0d32c1d17db3f69d85a35c and found by Stephen
> > and worked around in 609ceb807deba8e23 and edaaa11e5a3cf2c9c1a39)
> >
> > I'm guessing the problem in the iproute2 header sync is just a heads
> > up for what's going to happen when distributions updates their
> > system headers to match linux 2.6.33.
> >
> >
> > Could someone who knows how the userspace version of the kernel
> > headers are generated please find a suitable solution?
>
> We can export ALIGN to userspace, but the name is so generic,
> so it's not clear what breakage more risky.
Right.
> XT_ALIGN is a macro so breakage will appear only when it's used,
> not when header is included directly or indirectly.
>
> We have tc, iptables, both carry their own copy of headers, what else?
>
> Right now, I'd say, do nothing, and iptables will carry fixlet as in tc,
> eventually.
Why should every user-space consumer have to fix this up? We've been
through this with ethtool.h in the past (wrong type names); please don't
repeat that mistake.
Note that <linux/kernel.h> is exported and could be changed to define a
macro named e.g. __KERNEL_ALIGN() for user-space.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Tiny patch (w/ discussion) to provide the peer information on unix domain sockets
From: Eric Dumazet @ 2010-03-30 14:56 UTC (permalink / raw)
To: Erkki Seppala; +Cc: linux-kernel, netdev
In-Reply-To: <20100330143512.GF7980@coffee.modeemi.cs.tut.fi>
Le mardi 30 mars 2010 à 17:35 +0300, Erkki Seppala a écrit :
> Hello,
>
> Attached you will find a patch that appends the field 'Peer' to
> /proc/net/unix indicating the peer of a connected unix domain
> socket. It shows its kernel address, as this is how unix domain
> sockets are identified in the same file. The preceding optional file
> name (actual address of the socket) field is replaced with "-" if it
> is not set. If there is no peer, 0 is used in its place.
>
> The purpose of the patch is to provide information on onto which
> services processes are connected. This information is readily
> available for TCP/IP sockets but not for unix domain sockets. The
> information can be retrieved with relative ease by using the following
> scripts for GDB, if you have GDB 7.1 and debugging symbols around:
>
> http://www.modeemi.fi/~flux/software/list-unix-sockets.tar.gz
>
> But obviously this is not optimal :). With the patch, this is how you
> can find out the peers of the sockets of the X server:
>
> # grep -E $(lsof -p `pidof X` | grep unix | awk '{print s $6; s="|"}' |
> tr -d '\n' | sed 's/0x//g;s/.*/(&)$/') /proc/net/unix
> d913b000: 00000003 00000000 00000000 0001 03 5494 - d913b200
> d9085600: 00000003 00000000 00000000 0001 03 5487 - d9085800
> ..
>
> The number in the first column is the address, for which the process
> can be most easily found with lsof:
>
> # lsof | grep d913b000
> gnome-pow 1245 gdm 3u unix 0xd913b000 0t0 5494 -
>
> Hopefully this kind of work would be integrated into lsof to display
> the information more easily.
>
> The patch does break the current API, but the impact seems rather
> light. I'm happy to incorporate alternative approaches if this seems
> to severe.
>
> Originally the last field in the field was fully optional: if it was
> not known, the line would terminate immediately after the field
> preceding it. Because we append a new field (instead of inserting it
> before Path, which causes more severe problems), the missing field
> value is indicated with a hyphen instead. So this (where $ indicates
> EOL):
>
> de38f800: 00000003 00000000 00000000 0001 03 2323$
>
> becomes this:
>
> de38f800: 00000003 00000000 00000000 0001 03 2323 - de2e4400$
>
> This changes the output of netstat -x for unix domain sockets that
> don't have a known address. I'm pretty sure nobody cares,
> though.. Similarly this changes the behavior of lsof, which before the
> patch can display:
>
> rxvt 17693 ese 6u unix 0xffff880050ba8900 0t0 746261 socket
>
> but after the patch:
>
> gconf-hel 1377 gdm 3u unix 0xd9197800 0t0 5796 -
>
> Pretty sure this is pretty much the same for everyone as well
> :). Although that could likely be worked around by using "@" in place
> of "-". Infact this might be the proper thing to do: I'm not sure what
> the meaning of UNIX_ABSTRACT used in af_unix.c:unix_seq_show is,
> perhaps just that there is no name to be found? I cannot use the
> macro, though, because it uses the nondefined field addr.
>
> Btw, I noticed that af_unix.c:unix_seq_show does not quote the unix
> domain socket path (possibly due to lacking convenient quoting
> function in seq_file.c), which allows spoofing the contents of the
> file into a certain extent. Atleast spaces should be quoted for this
> patch to work properly in the cases when socket names have spaces in
> them.
>
> Here is the patch, also available at
>
> http://www.modeemi.fi/~flux/software/linux-2.6.31-procfs-unix_peer_information.patch
>
> --- linux-2.6.31/net/unix/af_unix.c 2010-03-30 16:19:52.306372568 +0300
> +++ linux-2.6.31-flux/net/unix/af_unix.c 2010-03-30 14:32:47.000000000 +0300
> @@ -2154,7 +2154,7 @@
>
> if (v == SEQ_START_TOKEN)
> seq_puts(seq, "Num RefCount Protocol Flags Type St "
> - "Inode Path\n");
> + "Inode Path Peer\n");
> else {
> struct sock *s = v;
> struct unix_sock *u = unix_sk(s);
> @@ -2185,7 +2185,14 @@
> }
> for ( ; i < len; i++)
> seq_putc(seq, u->addr->name->sun_path[i]);
> - }
> + } else
> + seq_puts(seq, " -");
> +
> + if (u->peer)
> + seq_printf(seq, " %p", u->peer);
> + else
> + seq_puts(seq, " 0");
> +
> unix_state_unlock(s);
> seq_putc(seq, '\n');
> }
>
Hi Erkki
Such patches should be sent to netdev
I believe you missed some necessary locking.
Prior art from Kenan Kalajdzic :
http://patchwork.ozlabs.org/patch/46561/
^ permalink raw reply
* Re: [PATCH] Allow MACB to connect to a higher addresses PHY.
From: Grant Likely @ 2010-03-30 14:41 UTC (permalink / raw)
To: Anders Darander
Cc: David S. Miller, Ralf Baechle, Maxime Bizon, Anders Darander,
David Daney, Sekhar Nori, Anton Vorontsov, Andy Fleming, netdev,
linux-kernel
In-Reply-To: <1269943112-6975-1-git-send-email-anders.darander@gmail.com>
On Tue, Mar 30, 2010 at 3:58 AM, Anders Darander
<anders.darander@gmail.com> wrote:
> From: Anders Darander <ad@datarespons.se>
>
> Using the Atmel MACB together with an integrated switch, can make only port 1
> work. This is caused by macb_mii_probe trying to attach the MAC to the first
> PHY, which often is on one of the external ports.
>
> E.g. the Micrel KSZ8873 connects to the MAC on port 3, thus phy_addr should be
> set to 3.
>
> Signed-off-by: Anders Darander <ad@datarespons.se>
Hi Anders,
I understand what you are trying to do, but this is the wrong way to
go about it. Hard coding it into Kconfig breaks multiplatform
kernels. Besides, systems may have more than one physical MDIO bus.
This patch would make CONFIG_SWITCHING_PHY_ADDR the only address
accessible on all MDIO busses.
Nak.
The right thing to do is to add a runtime configuration option (ie.
kernel parameter or platform data) to the mac driver to specify
exactly which PHY address it is supposed to use.
g.
> ---
> drivers/net/phy/Kconfig | 19 ++++++++++++++++++-
> drivers/net/phy/phy_device.c | 4 ++++
> 2 files changed, 22 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index fc5938b..64aa003 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -15,11 +15,28 @@ if PHYLIB
>
> comment "MII PHY device drivers"
>
> +config SWITCHING_PHY
> + bool "An Ethernet switch is connected to the MAC"
> + depends on MACB
> + help
> + If an Ethernet switch is connected to the MAC, it
> + is quite common to have the connection on a port
> + higher than the first port. This option allows to
> + select the desired port number
> +
> +config SWITCHING_PHY_ADDR
> + int "PHYA address"
> + depends on SWITCHING_PHY
> + default "3"
> + help
> + On e.g. the Micrel KSZ8873MLL, port 3 (and thus phy_addr
> + 3) is the one connected to the MAC of the MCU.
> +
> config MARVELL_PHY
> tristate "Drivers for Marvell PHYs"
> ---help---
> Currently has a driver for the 88E1011S
> -
> +
> config DAVICOM_PHY
> tristate "Drivers for Davicom PHYs"
> ---help---
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index db17945..891bd0d 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -284,7 +284,11 @@ struct phy_device *phy_find_first(struct mii_bus *bus)
> {
> int addr;
>
> +#ifdef CONFIG_SWITCHING_PHY
> + for (addr = CONFIG_SWITCHING_PHY_ADDR; addr < PHY_MAX_ADDR; addr++) {
> +#else
> for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
> +#endif
> if (bus->phy_map[addr])
> return bus->phy_map[addr];
> }
> --
> 1.7.0.3
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 14:37 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1FDC0.5020200@iki.fi>
On Tue, Mar 30, 2010 at 04:33:52PM +0300, Timo Teräs wrote:
>
> It also seems that the by-index hash is also used when
> generating new index. It's to double check that the index
> is unique. So deleting the by-index hash from per-socket
> policies seems tricky.
>
> Removing bydst hashing should be trivial.
Yes that makes sense.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 14:34 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <20100330143048.GB6840@gondor.apana.org.au>
On Tue, Mar 30, 2010 at 10:30:48PM +0800, Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 04:33:52PM +0300, Timo Teräs wrote:
> > Herbert Xu wrote:
> >> On Tue, Mar 30, 2010 at 03:41:02PM +0300, Timo Teräs wrote:
> >>> So it'd make more sense to nuke the hashes entirely for
> >>> per-socket policies?
> >>
> >> Absolutely.
> >
> > I checked now the xfrm_user, and mostly it seems to prevent
> > modification to per-socket policies.
> >
> > The only exception is XFRM_MSG_POLEXPIRE handler
> > xfrm_add_pol_expire(). It calls xfrm_policy_byid() without
> > verifying the direction, and can thus complete successfully on
> > a per-socket policy. This can actually result in per-socket
> > policy deletion via netlink.
>
> That shouldn't be possible since the directions used by socket
> policies cannot be set through xfrm_user.
If there is a missing direction check then we should add it.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 14:30 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1FDC0.5020200@iki.fi>
On Tue, Mar 30, 2010 at 04:33:52PM +0300, Timo Teräs wrote:
> Herbert Xu wrote:
>> On Tue, Mar 30, 2010 at 03:41:02PM +0300, Timo Teräs wrote:
>>> So it'd make more sense to nuke the hashes entirely for
>>> per-socket policies?
>>
>> Absolutely.
>
> I checked now the xfrm_user, and mostly it seems to prevent
> modification to per-socket policies.
>
> The only exception is XFRM_MSG_POLEXPIRE handler
> xfrm_add_pol_expire(). It calls xfrm_policy_byid() without
> verifying the direction, and can thus complete successfully on
> a per-socket policy. This can actually result in per-socket
> policy deletion via netlink.
That shouldn't be possible since the directions used by socket
policies cannot be set through xfrm_user.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 14:29 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB2044B.5080704@iki.fi>
On Tue, Mar 30, 2010 at 05:01:47PM +0300, Timo Teräs wrote:
>
> Since the exported function xfrm_policy_byid() can result in deletion
> of socket policy, it's safer to leave this change in. This is can be
> even triggered via xfrm_user since it does not check 'dir' for the
> policy expired message it handles. Any custom module could do similar
> harm.
That's a bug. Socket policies should never be deleted by anyone
other than the socket owner through a setsockopt.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: debugging kernel during packet drops
From: Patrick McHardy @ 2010-03-30 14:12 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Eric Dumazet, Jorrit Kronjee, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.01.1003301405490.10802@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Thursday 2010-03-25 11:35, Patrick McHardy wrote:
>
>> This clashes with some recent cleanups in nf-next-2.6.git. I'm
>> also expecting a patch from Jan to remove the old v0 revision
>> very soon (probably today). Please rediff once I've pushed that out.
>
> One 12-series request has been sitting there for a while. Was there
> something not in order with it?
No, I'm currently a bit backlogged due to getting sick. I'm running
your series for testing though, I'll probably push it out tommorrow.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-30 14:12 UTC (permalink / raw)
To: Edgar E. Iglesias
Cc: Andi Kleen, Templin, Fred L, Eric Dumazet, Rick Jones,
Glen Turner, netdev@vger.kernel.org
In-Reply-To: <20100330082013.GA18300@edde.se.axis.com>
> Where does the application controllable per socket MTU come into the
> picture?
To set the minimum path MTU so that there is a guarantee that IPv6 routers
(which are unable to fragment themselves) will never drop it.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 14:01 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <4BB1E8B1.4030604@iki.fi>
Timo Teräs wrote:
> Herbert Xu wrote:
>> On Tue, Mar 30, 2010 at 07:55:07AM +0300, Timo Teräs wrote:
>>> Herbert Xu wrote:
>>>> On Mon, Mar 29, 2010 at 05:12:38PM +0300, Timo Teras wrote:
>>>>> @@ -1132,7 +1119,7 @@ int xfrm_sk_policy_insert(struct sock *sk,
>>>>> int dir, struct xfrm_policy *pol)
>>>>> __xfrm_policy_link(pol, XFRM_POLICY_MAX+dir);
>>>>> }
>>>>> if (old_pol)
>>>>> - __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>>>> + old_pol = __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
>>>>> write_unlock_bh(&xfrm_policy_lock);
>>>>> if (old_pol) {
>>>> So when can this actually fail?
>>> Considering that the socket reference is received from the
>>> sk->sk_policy,
>>> and the hash bucket we use is "XFRM_POLICY_MAX+dir", it's non-obvious if
>>> it can fail or not.
>>>
>>> It would look like the timer can kill a policy and unlink it, but it
>>> would still be found from sk_policy.
>>
>> Socket policies cannot expire.
>
> Was not aware of that. The above is not needed then.
Since the exported function xfrm_policy_byid() can result in deletion
of socket policy, it's safer to leave this change in. This is can be
even triggered via xfrm_user since it does not check 'dir' for the
policy expired message it handles. Any custom module could do similar
harm.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2010-03-30 13:51 UTC (permalink / raw)
To: John W. Linville
Cc: David Miller, netdev, linux-next, linux-kernel, Shanyu Zhao,
Zhu Yi, Reinette Chatre, Johannes Berg
In-Reply-To: <20100330131220.GA13120@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
Hi John,
On Tue, 30 Mar 2010 09:12:21 -0400 "John W. Linville" <linville@tuxdriver.com> wrote:
>
> Yes, that looks correct to me -- at least, that's what I did in
> wireless-testing. :-)
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 13:33 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330124815.GA6378@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 03:41:02PM +0300, Timo Teräs wrote:
>> So it'd make more sense to nuke the hashes entirely for
>> per-socket policies?
>
> Absolutely.
I checked now the xfrm_user, and mostly it seems to prevent
modification to per-socket policies.
The only exception is XFRM_MSG_POLEXPIRE handler
xfrm_add_pol_expire(). It calls xfrm_policy_byid() without
verifying the direction, and can thus complete successfully on
a per-socket policy. This can actually result in per-socket
policy deletion via netlink.
I guess the proper thing is to add the direction check there.
It also seems that the by-index hash is also used when
generating new index. It's to double check that the index
is unique. So deleting the by-index hash from per-socket
policies seems tricky.
Removing bydst hashing should be trivial.
^ permalink raw reply
* Re: XT_ALIGN changed to use ALIGN breaks iproute2
From: Alexey Dobriyan @ 2010-03-30 13:15 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: Patrick McHardy, Stephen Hemminger, jamal, netdev
In-Reply-To: <20100330092829.GA3106@amd64.fatal.se>
On Tue, Mar 30, 2010 at 12:28 PM, Andreas Henriksson <andreas@fatal.se> wrote:
> You updated the kernel header include/linux/netfilter/x_tables.h
> in torvalds/linux-2.6.git commit 42107f5009da223daa800d6da6904d77297ae829
> with the comment "Use ALIGN() macro while I'm at it for same types.".
>
> When this header was synced into iproute2 the build broke because the
> ALIGN macro apparently only is defined in kernel headers.
>
> (For iproute2 the problem was introduced in
> 8ecdcce08319d0e39b0d32c1d17db3f69d85a35c and found by Stephen
> and worked around in 609ceb807deba8e23 and edaaa11e5a3cf2c9c1a39)
>
> I'm guessing the problem in the iproute2 header sync is just a heads
> up for what's going to happen when distributions updates their
> system headers to match linux 2.6.33.
>
>
> Could someone who knows how the userspace version of the kernel
> headers are generated please find a suitable solution?
We can export ALIGN to userspace, but the name is so generic,
so it's not clear what breakage more risky.
XT_ALIGN is a macro so breakage will appear only when it's used,
not when header is included directly or indirectly.
We have tc, iptables, both carry their own copy of headers, what else?
Right now, I'd say, do nothing, and iptables will carry fixlet as in tc,
eventually.
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the wireless-current tree
From: John W. Linville @ 2010-03-30 13:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Shanyu Zhao,
Zhu Yi, Reinette Chatre, Johannes Berg
In-Reply-To: <20100330133745.27295ee0.sfr@canb.auug.org.au>
On Tue, Mar 30, 2010 at 01:37:45PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/wireless/iwlwifi/iwl-agn.c between commit
> d4dca4e53fde2953d74198a2c445db1d36ed9fd2 ("iwlwifi: clear unattended
> interrupts in tasklet") from the wireless-current tree and commit
> a4c8b2a692601de0a7bcb032b69f806050944dff ("iwlwifi: move ICT data to agn
> part of union") from the net tree.
>
> I fixed it up (see below) and can carry the fix for a while.
Yes, that looks correct to me -- at least, that's what I did in
wireless-testing. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] skb_put: remove not needed check for skb linearity
From: Paulius Zaleckas @ 2010-03-30 13:01 UTC (permalink / raw)
To: davem; +Cc: netdev
It is safe to call skb_put() on packets containing fragments.
Actually I have a case where I allocate packet header with some
extra headroom and then I dynamically add data as frag_list. After
adding frags I have to add more data to header and skb_put()
just BUG's on me :)
And we will save couple instructions for CPU.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
---
include/linux/skbuff.h | 1 -
net/core/skbuff.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 124f90c..194e9fa 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1108,7 +1108,6 @@ extern unsigned char *skb_put(struct sk_buff *skb, unsigned int len);
static inline unsigned char *__skb_put(struct sk_buff *skb, unsigned int len)
{
unsigned char *tmp = skb_tail_pointer(skb);
- SKB_LINEAR_ASSERT(skb);
skb->tail += len;
skb->len += len;
return tmp;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 93c4e06..ea1ca61 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1011,7 +1011,6 @@ EXPORT_SYMBOL(skb_pad);
unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
{
unsigned char *tmp = skb_tail_pointer(skb);
- SKB_LINEAR_ASSERT(skb);
skb->tail += len;
skb->len += len;
if (unlikely(skb->tail > skb->end))
^ permalink raw reply related
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-30 12:48 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB1F15E.3030402@iki.fi>
On Tue, Mar 30, 2010 at 03:41:02PM +0300, Timo Teräs wrote:
>
> So it'd make more sense to nuke the hashes entirely for
> per-socket policies?
Absolutely.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/7] flow: delayed deletion of flow cache entries
From: Timo Teräs @ 2010-03-30 12:43 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330123612.GB6174@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 03:32:58PM +0300, Timo Teräs wrote:
>> If flow cache regeneration or shrinking is triggered in lookup,
>> it would previously free it in place. Now that is deferred. But
>> yes, it's more useful after the next patches that call the
>> virtual destructor. Should have explained this better.
>
> Any chance you can refactor them so that this comes after the
> virtual get/put patch?
>
> That way can evaluate this on its own merit rather than being
> a prerequisite for the more important stuff.
I thought it's not good to have possible speed regressions even
temporarily in the tree, so I figured this should go first.
But sure, I'll refactor this to be a later commit for the next
iteration.
^ permalink raw reply
* Re: Network performance - iperf
From: Eric Dumazet @ 2010-03-30 12:41 UTC (permalink / raw)
To: michal.simek
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <4BB1C5A5.5070202@petalogix.com>
Le mardi 30 mars 2010 à 11:34 +0200, Michal Simek a écrit :
> 2233 packets pruned from receive queue because of socket buffer overrun
> TCPRcvCollapsed: 207654
Thats a problem. A big one :(
If I remember, you use LL_TEMAC driver.
This drivers allocates big skbs for RX ring (more than 9000 bytes each
skb). Given your 32 Mbytes kernel size, this seems plain wrong.
You might try to copybreak them before giving skb to network stack,
consuming the minimum space.
This would also help this driver to survive in low memory conditions,
avoiding death if high order pages are not available.
I cannot even compile this driver on my x86 platform, but here is a
preliminar patch to give you the idea :
[PATCH] ll_temac: Fix some memory allocation problems
Driver use high order allocations that might fail after a while.
When receiving a buffer from card, try to copy it to keep a pool of
pre-allocated high order buffers.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Please please please note I did not test this patch.
drivers/net/ll_temac_main.c | 48 +++++++++++++++-------------------
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index a18e348..412b72e 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -155,8 +155,8 @@ static int temac_dma_bd_init(struct net_device *ndev)
lp->rx_bd_v[i].next = lp->rx_bd_p +
sizeof(*lp->rx_bd_v) * ((i + 1) % RX_BD_NUM);
- skb = alloc_skb(XTE_MAX_JUMBO_FRAME_SIZE
- + XTE_ALIGN, GFP_ATOMIC);
+ skb = alloc_skb(XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN,
+ GFP_KERNEL);
if (skb == 0) {
dev_err(&ndev->dev, "alloc_skb error %d\n", i);
return -1;
@@ -625,34 +625,30 @@ static void ll_temac_recv(struct net_device *ndev)
skb = lp->rx_skb[lp->rx_bd_ci];
length = cur_p->app4 & 0x3FFF;
- skb_vaddr = virt_to_bus(skb->data);
+ new_skb = netdev_alloc_skb_ip_align(length);
+ if (new_skb) {
+ skb_copy_to_linear_data(new_skb, skb->data, length);
+ skb_put(new_skb, length);
+ skb_vaddr = virt_to_bus(skb->data);
+ dma_sync_single_for_device(ndev->dev.parent,
+ skb_vaddr,
+ XTE_MAX_JUMBO_FRAME_SIZE,
+ PCI_DMA_FROMDEVICE);
+ new_skb->dev = ndev;
+ new_skb->protocol = eth_type_trans(new_skb, ndev);
+ new_skb->ip_summed = CHECKSUM_NONE;
+
+ netif_rx(new_skb);
+
+ ndev->stats.rx_packets++;
+ ndev->stats.rx_bytes += length;
+ } else
+ ndev->stats.rx_dropped++;
+
dma_unmap_single(ndev->dev.parent, skb_vaddr, length,
DMA_FROM_DEVICE);
- skb_put(skb, length);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
- skb->ip_summed = CHECKSUM_NONE;
-
- netif_rx(skb);
-
- ndev->stats.rx_packets++;
- ndev->stats.rx_bytes += length;
-
- new_skb = alloc_skb(XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN,
- GFP_ATOMIC);
- if (new_skb == 0) {
- dev_err(&ndev->dev, "no memory for new sk_buff\n");
- spin_unlock_irqrestore(&lp->rx_lock, flags);
- return;
- }
-
- skb_reserve(new_skb, BUFFER_ALIGN(new_skb->data));
-
cur_p->app0 = STS_CTRL_APP0_IRQONEND;
- cur_p->phys = dma_map_single(ndev->dev.parent, new_skb->data,
- XTE_MAX_JUMBO_FRAME_SIZE,
- DMA_FROM_DEVICE);
cur_p->len = XTE_MAX_JUMBO_FRAME_SIZE;
lp->rx_skb[lp->rx_bd_ci] = new_skb;
^ permalink raw reply related
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Timo Teräs @ 2010-03-30 12:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100330122301.GG5731@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, Mar 30, 2010 at 03:21:19PM +0300, Timo Teräs wrote:
>> Hmm... is it possible to modify/delete per-socket policies from
>> userland via xfrm_user? That would be also another race why
>> we'd need to check the unlinking result.
>
> How would the user be able to specify the socket?
>
> The answer is no.
I thought it was possible since they can be dumped.
But yes, I now see that the policy direction check does not
allow the per-socket policies to be specified.
So it'd make more sense to nuke the hashes entirely for
per-socket policies?
^ 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