* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Jeff Garzik @ 2007-09-27 8:23 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: hare, open-iscsi, hch, davem, mchristi, netdev, anilgv, talm,
lusinsky, uri, fujita.tomonori, benh, jens.axboe, James.Bottomley,
linux-scsi
In-Reply-To: <20070926075800T.tomof@acm.org>
FUJITA Tomonori wrote:
> CC'ed Jens, James, and linux-scsi.
>
> On Thu, 27 Sep 2007 03:31:55 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> FUJITA Tomonori wrote:
>>> Yeah, we could nicely handle lld's restrictions (especially with
>>> stacking devices). But iommu code needs only max_segment_size and
>>> seg_boundary_mask, right? If so, the first simple approach to add two
>>> values to device structure is not so bad, I think.
>> (replying to slightly older email in the thread)
>> (added benh, since we've discussed this issue in the past)
>>
>> dumb question, what happened to seg_boundary_mask?
>
> I'll work on it too after finishing max_seg_size.
>
>
>> If you look at drivers/ata/libata-core.c:ata_fill_sg(), you will note
>> that we split s/g segments after DMA-mapping. Looking at libata LLDD's,
>> you will also note judicious use of ATA_DMA_BOUNDARY (0xffff).
>
> I know the workaround since I fixed libata's sg chaining patch.
>
>
>> It was drilled into my head by James and benh that I cannot rely on the
>> DMA boundary + block/scsi + dma_map_sg() to ensure that my S/G segments
>> never cross a 64K boundary, a legacy IDE requirement. Thus the
>> additional code in ata_fill_sg() to split S/G segments straddling 64K,
>> in addition to setting dma boundary to 0xffff.
>
> I think that the block layer can handle both max_segment_size and
> seg_boundary_mask properly (and SCSI-ml just uses the block layer). So
> if we fix iommu, then we can remove a workaround to fix sg lists in
> llds.
>
>
>> A key problem I was hoping would be solved with your work here was the
>> elimination of that post dma_map_sg() split.
>
> Yeah, that's my goal too.
Great :) Well, I'm generally happy with your max-seg-size stuff (sans
the minor nits I pointed out in another email).
Thanks for pursuing this,
Jeff
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Jeff Garzik @ 2007-09-27 8:22 UTC (permalink / raw)
To: benh
Cc: FUJITA Tomonori, hare, open-iscsi, hch, davem, mchristi, netdev,
anilgv, talm, lusinsky, uri, fujita.tomonori
In-Reply-To: <1190880779.6158.0.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
>>>> A key problem I was hoping would be solved with your work here was
>>>> the
>>>> elimination of that post dma_map_sg() split.
>>>>
>>>> If I understood James and Ben correctly, one of the key problems was
>>>> always in communicating libata's segment boundary needs to the IOMMU
>>>> layers?
>>> Yup. If we can put some constraint in struct device that the dma mapping
>>> code can then look at ... we also need to ensure that what's passed in
>>> for DMA'ing already matches those constraints as well since no-iommu
>>> platforms will basically just keep the dma table as-is.
>> That's a good point... no-iommu platforms would need to be updated to
>> do the split for me. I suppose we can steal that code from swiotlb or
>> somewhere.
>
> Doing the split means being able to grow the sglist... which the dma_*
> calls can't do at least not in their current form.
IMO one straightforward approach is for the struct scatterlist owner to
provide a table large enough to accomodate the possible splits (perhaps
along with communicate that table's max size to the IOMMU/dma layers).
Jeff
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Benjamin Herrenschmidt @ 2007-09-27 8:12 UTC (permalink / raw)
To: Jeff Garzik
Cc: FUJITA Tomonori, hare, open-iscsi, hch, davem, mchristi, netdev,
anilgv, talm, lusinsky, uri, fujita.tomonori
In-Reply-To: <46FB6087.10306@garzik.org>
On Thu, 2007-09-27 at 03:49 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
> >> A key problem I was hoping would be solved with your work here was
> >> the
> >> elimination of that post dma_map_sg() split.
> >>
> >> If I understood James and Ben correctly, one of the key problems was
> >> always in communicating libata's segment boundary needs to the IOMMU
> >> layers?
> >
> > Yup. If we can put some constraint in struct device that the dma mapping
> > code can then look at ... we also need to ensure that what's passed in
> > for DMA'ing already matches those constraints as well since no-iommu
> > platforms will basically just keep the dma table as-is.
>
> That's a good point... no-iommu platforms would need to be updated to
> do the split for me. I suppose we can steal that code from swiotlb or
> somewhere.
Doing the split means being able to grow the sglist... which the dma_*
calls can't do at least not in their current form.
Ben.
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: FUJITA Tomonori @ 2007-09-27 8:06 UTC (permalink / raw)
To: jeff
Cc: tomof, hare, open-iscsi, hch, davem, mchristi, netdev, anilgv,
talm, lusinsky, uri, fujita.tomonori, benh, jens.axboe,
James.Bottomley, linux-scsi
In-Reply-To: <46FB5C6B.3020506@garzik.org>
CC'ed Jens, James, and linux-scsi.
On Thu, 27 Sep 2007 03:31:55 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> FUJITA Tomonori wrote:
> > Yeah, we could nicely handle lld's restrictions (especially with
> > stacking devices). But iommu code needs only max_segment_size and
> > seg_boundary_mask, right? If so, the first simple approach to add two
> > values to device structure is not so bad, I think.
>
> (replying to slightly older email in the thread)
> (added benh, since we've discussed this issue in the past)
>
> dumb question, what happened to seg_boundary_mask?
I'll work on it too after finishing max_seg_size.
> If you look at drivers/ata/libata-core.c:ata_fill_sg(), you will note
> that we split s/g segments after DMA-mapping. Looking at libata LLDD's,
> you will also note judicious use of ATA_DMA_BOUNDARY (0xffff).
I know the workaround since I fixed libata's sg chaining patch.
> It was drilled into my head by James and benh that I cannot rely on the
> DMA boundary + block/scsi + dma_map_sg() to ensure that my S/G segments
> never cross a 64K boundary, a legacy IDE requirement. Thus the
> additional code in ata_fill_sg() to split S/G segments straddling 64K,
> in addition to setting dma boundary to 0xffff.
I think that the block layer can handle both max_segment_size and
seg_boundary_mask properly (and SCSI-ml just uses the block layer). So
if we fix iommu, then we can remove a workaround to fix sg lists in
llds.
> A key problem I was hoping would be solved with your work here was the
> elimination of that post dma_map_sg() split.
Yeah, that's my goal too.
> If I understood James and Ben correctly, one of the key problems was
> always in communicating libata's segment boundary needs to the IOMMU layers?
>
> Jeff
>
^ permalink raw reply
* Re: Linux networking implementation and packet capture
From: Mohammad M Molla @ 2007-09-27 8:05 UTC (permalink / raw)
To: Gaurav Aggarwal, kernelnewbies, linux-net, netdev
In-Reply-To: <1a41e0840709262347m1fc5d99dge9aeb172b7fc610e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
There are two good books that you might find useful -
1. Understanding Linux Network Internals - Christian Benvenuti
2. The Linux TCP/IP stack - Networking for Embedded Systems - Thomas F. Herbert
- Meraj
Gaurav Aggarwal <grv.aggarwal@gmail.com> wrote: Hi,
I am trying to understand the implementation of linux 2.4 and linux 2.6's networking (IPV4) . Can anyone give me some idea/pointers about some of the good resources/whitepapers available in the market to understand the same. If there is any document that mention the changes between the implementation of networking in 2.4 & 2.6
I am also trying to write a simple program(preferably a userspace application) which captures all the incoming and outgoing packets of a particular machine (preferably at PREROUTING stage), then according to the SRC/DST addresses, changes the IP address of some of the packets and then reinject it back into the local IP stack. I am able to do that in 2.4 kernel by using libipq and ip_tables but that prog is not running in 2.6 kernel. (It hits at ip_route_BUG). Any idea or code snippet will be really appreciated.
--
Regards,
Gaurav Aggarwal
---------------------------------
Need a vacation? Get great deals to amazing places on Yahoo! Travel.
[-- Attachment #2: Type: text/html, Size: 1602 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Jeff Garzik @ 2007-09-27 7:49 UTC (permalink / raw)
To: benh
Cc: FUJITA Tomonori, hare, open-iscsi, hch, davem, mchristi, netdev,
anilgv, talm, lusinsky, uri, fujita.tomonori
In-Reply-To: <1190878682.30275.9.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
>> A key problem I was hoping would be solved with your work here was
>> the
>> elimination of that post dma_map_sg() split.
>>
>> If I understood James and Ben correctly, one of the key problems was
>> always in communicating libata's segment boundary needs to the IOMMU
>> layers?
>
> Yup. If we can put some constraint in struct device that the dma mapping
> code can then look at ... we also need to ensure that what's passed in
> for DMA'ing already matches those constraints as well since no-iommu
> platforms will basically just keep the dma table as-is.
That's a good point... no-iommu platforms would need to be updated to
do the split for me. I suppose we can steal that code from swiotlb or
somewhere.
Jeff
^ permalink raw reply
* Re: [PATCH 1/4] net: Dynamically allocate the per cpu counters for the loopback device.
From: Eric W. Biederman @ 2007-09-27 7:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, containers
In-Reply-To: <20070926.220901.51682476.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Wed, 26 Sep 2007 17:53:40 -0600
>
>>
>> This patch add support for dynamically allocating the statistics counters
>> for the loopback device and adds appropriate device methods for allocating
>> and freeing the loopback device.
>>
>> This completes support for creating multiple instances of the loopback
>> device, in preparation for creating per network namespace instances.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> Applied to net-2.6.24, thanks.
>
>> @@ -155,7 +154,8 @@ static int loopback_xmit(struct sk_buff *skb, struct
> net_device *dev)
>> dev->last_rx = jiffies;
>>
>> /* it's OK to use __get_cpu_var() because BHs are off */
>> - lb_stats = &__get_cpu_var(pcpu_lstats);
>> + pcpu_lstats = netdev_priv(dev);
>> + lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
>> lb_stats->bytes += skb->len;
>> lb_stats->packets++;
>>
>
> I'm going to add a followon change that gets rid of that
> comment about __get_cpu_var() since it is no longer
> relevant.
Good point.
I'm not doing get_cpu/put_cpu so does the comment make sense
in relationship to per_cpu_ptr?
Eric
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Benjamin Herrenschmidt @ 2007-09-27 7:38 UTC (permalink / raw)
To: Jeff Garzik
Cc: FUJITA Tomonori, hare, open-iscsi, hch, davem, mchristi, netdev,
anilgv, talm, lusinsky, uri, fujita.tomonori
In-Reply-To: <46FB5C6B.3020506@garzik.org>
On Thu, 2007-09-27 at 03:31 -0400, Jeff Garzik wrote:
> A key problem I was hoping would be solved with your work here was
> the
> elimination of that post dma_map_sg() split.
>
> If I understood James and Ben correctly, one of the key problems was
> always in communicating libata's segment boundary needs to the IOMMU
> layers?
Yup. If we can put some constraint in struct device that the dma mapping
code can then look at ... we also need to ensure that what's passed in
for DMA'ing already matches those constraints as well since no-iommu
platforms will basically just keep the dma table as-is.
Ben.
^ permalink raw reply
* [PKT_SCHED]: Add stateless NAT
From: Herbert Xu @ 2007-09-27 7:34 UTC (permalink / raw)
To: David S. Miller, netdev, Alexey Kuznetsov, jamal
Hi:
[PKT_SCHED]: Add stateless NAT
Stateless NAT is useful in controlled environments where restrictions are
placed on through traffic such that we don't need connection tracking to
correctly NAT protocol-specific data.
In particular, this is of interest when the number of flows or the number
of addresses being NATed is large, or if connection tracking information
has to be replicated and where it is not practical to do so.
Previously we had stateless NAT functionality which was integrated into
the IPv4 routing subsystem. This was a great solution as long as the NAT
worked on a subnet to subnet basis such that the number of NAT rules was
relatively small. The reason is that for SNAT the routing based system
had to perform a linear scan through the rules.
If the number of rules is large then major renovations would have take
place in the routing subsystem to make this practical.
For the time being, the least intrusive way of achieving this is to use
the u32 classifier written by Alexey Kuznetsov along with the actions
infrastructure implemented by Jamal Hadi Salim.
The following patch is an attempt at this problem by creating a new nat
action that can be invoked from u32 hash tables which would allow large
number of stateless NAT rules that can be used/updated in constant time.
The actual NAT code is mostly based on the previous stateless NAT code
written by Alexey. In future we might be able to utilise the protocol
NAT code from netfilter to improve support for other protocols.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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
--
diff --git a/include/linux/tc_act/tc_nat.h b/include/linux/tc_act/tc_nat.h
new file mode 100644
index 0000000..9280c6f
--- /dev/null
+++ b/include/linux/tc_act/tc_nat.h
@@ -0,0 +1,29 @@
+#ifndef __LINUX_TC_NAT_H
+#define __LINUX_TC_NAT_H
+
+#include <linux/pkt_cls.h>
+#include <linux/types.h>
+
+#define TCA_ACT_NAT 9
+
+enum
+{
+ TCA_NAT_UNSPEC,
+ TCA_NAT_PARMS,
+ TCA_NAT_TM,
+ __TCA_NAT_MAX
+};
+#define TCA_NAT_MAX (__TCA_NAT_MAX - 1)
+
+#define TCA_NAT_FLAG_EGRESS 1
+
+struct tc_nat
+{
+ tc_gen;
+ __be32 old_addr;
+ __be32 new_addr;
+ __be32 mask;
+ __u32 flags;
+};
+
+#endif
diff --git a/include/net/tc_act/tc_nat.h b/include/net/tc_act/tc_nat.h
new file mode 100644
index 0000000..4a691f3
--- /dev/null
+++ b/include/net/tc_act/tc_nat.h
@@ -0,0 +1,21 @@
+#ifndef __NET_TC_NAT_H
+#define __NET_TC_NAT_H
+
+#include <linux/types.h>
+#include <net/act_api.h>
+
+struct tcf_nat {
+ struct tcf_common common;
+
+ __be32 old_addr;
+ __be32 new_addr;
+ __be32 mask;
+ u32 flags;
+};
+
+static inline struct tcf_nat *to_tcf_nat(struct tcf_common *pc)
+{
+ return container_of(pc, struct tcf_nat, common);
+}
+
+#endif /* __NET_TC_NAT_H */
diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index 8a74cac..22b34f2 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -447,6 +447,17 @@ config NET_ACT_IPT
To compile this code as a module, choose M here: the
module will be called ipt.
+config NET_ACT_NAT
+ tristate "Stateless NAT"
+ depends on NET_CLS_ACT
+ select NETFILTER
+ ---help---
+ Say Y here to do stateless NAT on IPv4 packets. You should use
+ netfilter for NAT unless you know what you are doing.
+
+ To compile this code as a module, choose M here: the
+ module will be called ipt.
+
config NET_ACT_PEDIT
tristate "Packet Editing"
depends on NET_CLS_ACT
diff --git a/net/sched/Makefile b/net/sched/Makefile
index b67c36f..81ecbe8 100644
--- a/net/sched/Makefile
+++ b/net/sched/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_NET_ACT_POLICE) += act_police.o
obj-$(CONFIG_NET_ACT_GACT) += act_gact.o
obj-$(CONFIG_NET_ACT_MIRRED) += act_mirred.o
obj-$(CONFIG_NET_ACT_IPT) += act_ipt.o
+obj-$(CONFIG_NET_ACT_NAT) += act_nat.o
obj-$(CONFIG_NET_ACT_PEDIT) += act_pedit.o
obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o
obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o
diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
new file mode 100644
index 0000000..efd6d7d
--- /dev/null
+++ b/net/sched/act_nat.c
@@ -0,0 +1,313 @@
+/*
+ * Stateless NAT actions
+ *
+ * Copyright (c) 2007 Herbert Xu <herbert@gondor.apana.org.au>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/netfilter.h>
+#include <linux/rtnetlink.h>
+#include <linux/skbuff.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/string.h>
+#include <linux/tc_act/tc_nat.h>
+#include <net/act_api.h>
+#include <net/icmp.h>
+#include <net/ip.h>
+#include <net/netlink.h>
+#include <net/tc_act/tc_nat.h>
+#include <net/tcp.h>
+#include <net/udp.h>
+
+
+#define NAT_TAB_MASK 15
+static struct tcf_common *tcf_nat_ht[NAT_TAB_MASK + 1];
+static u32 nat_idx_gen;
+static DEFINE_RWLOCK(nat_lock);
+
+static struct tcf_hashinfo nat_hash_info = {
+ .htab = tcf_nat_ht,
+ .hmask = NAT_TAB_MASK,
+ .lock = &nat_lock,
+};
+
+static int tcf_nat_init(struct rtattr *rta, struct rtattr *est,
+ struct tc_action *a, int ovr, int bind)
+{
+ struct rtattr *tb[TCA_NAT_MAX];
+ struct tc_nat *parm;
+ int ret = 0;
+ struct tcf_nat *p;
+ struct tcf_common *pc;
+
+ if (rta == NULL || rtattr_parse_nested(tb, TCA_NAT_MAX, rta) < 0)
+ return -EINVAL;
+
+ if (tb[TCA_NAT_PARMS - 1] == NULL ||
+ RTA_PAYLOAD(tb[TCA_NAT_PARMS - 1]) < sizeof(*parm))
+ return -EINVAL;
+ parm = RTA_DATA(tb[TCA_NAT_PARMS - 1]);
+
+ pc = tcf_hash_check(parm->index, a, bind, &nat_hash_info);
+ if (!pc) {
+ pc = tcf_hash_create(parm->index, est, a, sizeof(*p), bind,
+ &nat_idx_gen, &nat_hash_info);
+ if (unlikely(!pc))
+ return -ENOMEM;
+ p = to_tcf_nat(pc);
+ ret = ACT_P_CREATED;
+ } else {
+ p = to_tcf_nat(pc);
+ if (!ovr) {
+ tcf_hash_release(pc, bind, &nat_hash_info);
+ return -EEXIST;
+ }
+ }
+
+ spin_lock_bh(&p->tcf_lock);
+ p->old_addr = parm->old_addr;
+ p->new_addr = parm->new_addr;
+ p->mask = parm->mask;
+ p->flags = parm->flags;
+
+ p->tcf_action = parm->action;
+ spin_unlock_bh(&p->tcf_lock);
+
+ if (ret == ACT_P_CREATED)
+ tcf_hash_insert(pc, &nat_hash_info);
+
+ return ret;
+}
+
+static int tcf_nat_cleanup(struct tc_action *a, int bind)
+{
+ struct tcf_nat *p = a->priv;
+
+ return tcf_hash_release(&p->common, bind, &nat_hash_info);
+}
+
+static int tcf_nat(struct sk_buff *skb, struct tc_action *a,
+ struct tcf_result *res)
+{
+ struct tcf_nat *p = a->priv;
+ struct iphdr *iph;
+ __be32 old_addr;
+ __be32 new_addr;
+ __be32 mask;
+ __be32 addr;
+ int egress;
+ int action;
+ int ihl;
+
+ spin_lock(&p->tcf_lock);
+
+ p->tcf_tm.lastuse = jiffies;
+ old_addr = p->old_addr;
+ new_addr = p->new_addr;
+ mask = p->mask;
+ egress = p->flags & TCA_NAT_FLAG_EGRESS;
+ action = p->tcf_action;
+
+ p->tcf_bstats.bytes += skb->len;
+ p->tcf_bstats.packets++;
+
+ spin_unlock(&p->tcf_lock);
+
+ if (!pskb_may_pull(skb, sizeof(*iph)))
+ return TC_ACT_SHOT;
+
+ iph = ip_hdr(skb);
+
+ if (egress)
+ addr = iph->saddr;
+ else
+ addr = iph->daddr;
+
+ if (!((old_addr ^ addr) & mask)) {
+ if (skb_cloned(skb) &&
+ !skb_clone_writable(skb, sizeof(*iph)) &&
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ return TC_ACT_SHOT;
+
+ new_addr &= mask;
+ new_addr |= addr & ~mask;
+
+ /* Rewrite IP header */
+ iph = ip_hdr(skb);
+ if (egress)
+ iph->saddr = new_addr;
+ else
+ iph->daddr = new_addr;
+
+ nf_csum_replace4(&iph->check, addr, new_addr);
+ }
+
+ ihl = iph->ihl * 4;
+
+ /* It would be nice to share code with stateful NAT. */
+ switch (iph->frag_off & htons(IP_OFFSET) ? 0 : iph->protocol) {
+ case IPPROTO_TCP:
+ {
+ struct tcphdr *tcph;
+
+ if (!pskb_may_pull(skb, ihl + sizeof(*tcph)) ||
+ (skb_cloned(skb) &&
+ !skb_clone_writable(skb, ihl + sizeof(*tcph)) &&
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC)))
+ return TC_ACT_SHOT;
+
+ tcph = (void *)(skb_network_header(skb) + ihl);
+ nf_proto_csum_replace4(&tcph->check, skb, addr, new_addr, 1);
+ break;
+ }
+ case IPPROTO_UDP:
+ {
+ struct udphdr *udph;
+
+ if (!pskb_may_pull(skb, ihl + sizeof(*udph)) ||
+ (skb_cloned(skb) &&
+ !skb_clone_writable(skb, ihl + sizeof(*udph)) &&
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC)))
+ return TC_ACT_SHOT;
+
+ udph = (void *)(skb_network_header(skb) + ihl);
+ if (udph->check || skb->ip_summed == CHECKSUM_PARTIAL) {
+ nf_proto_csum_replace4(&udph->check, skb, addr,
+ new_addr, 1);
+ if (!udph->check)
+ udph->check = CSUM_MANGLED_0;
+ }
+ break;
+ }
+ case IPPROTO_ICMP:
+ {
+ struct icmphdr *icmph;
+
+ if (!pskb_may_pull(skb, ihl + sizeof(*icmph) + sizeof(*iph)))
+ return TC_ACT_SHOT;
+
+ icmph = (void *)(skb_network_header(skb) + ihl);
+
+ if ((icmph->type != ICMP_DEST_UNREACH) &&
+ (icmph->type != ICMP_TIME_EXCEEDED) &&
+ (icmph->type != ICMP_PARAMETERPROB))
+ break;
+
+ iph = (void *)(icmph + 1);
+ if (egress)
+ addr = iph->daddr;
+ else
+ addr = iph->saddr;
+
+ if ((old_addr ^ addr) & mask)
+ break;
+
+ if (skb_cloned(skb) &&
+ !skb_clone_writable(skb,
+ ihl + sizeof(*icmph) + sizeof(*iph)) &&
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ return TC_ACT_SHOT;
+
+ icmph = (void *)(skb_network_header(skb) + ihl);
+ iph = (void *)(icmph + 1);
+
+ new_addr &= mask;
+ new_addr |= addr & ~mask;
+
+ /* XXX Fix up the inner checksums. */
+ if (egress)
+ iph->daddr = new_addr;
+ else
+ iph->saddr = new_addr;
+
+ nf_proto_csum_replace4(&icmph->checksum, skb, addr, new_addr,
+ 1);
+ break;
+ }
+ default:
+ break;
+ }
+
+ return action;
+}
+
+static int tcf_nat_dump(struct sk_buff *skb, struct tc_action *a,
+ int bind, int ref)
+{
+ unsigned char *b = skb_tail_pointer(skb);
+ struct tcf_nat *p = a->priv;
+ struct tc_nat *opt;
+ struct tcf_t t;
+ int s;
+
+ s = sizeof(*opt);
+
+ /* netlink spinlocks held above us - must use ATOMIC */
+ opt = kzalloc(s, GFP_ATOMIC);
+ if (unlikely(!opt))
+ return -ENOBUFS;
+
+ opt->old_addr = p->old_addr;
+ opt->new_addr = p->new_addr;
+ opt->mask = p->mask;
+ opt->flags = p->flags;
+
+ opt->index = p->tcf_index;
+ opt->action = p->tcf_action;
+ opt->refcnt = p->tcf_refcnt - ref;
+ opt->bindcnt = p->tcf_bindcnt - bind;
+
+ RTA_PUT(skb, TCA_NAT_PARMS, s, opt);
+ t.install = jiffies_to_clock_t(jiffies - p->tcf_tm.install);
+ t.lastuse = jiffies_to_clock_t(jiffies - p->tcf_tm.lastuse);
+ t.expires = jiffies_to_clock_t(p->tcf_tm.expires);
+ RTA_PUT(skb, TCA_NAT_TM, sizeof(t), &t);
+
+ kfree(opt);
+
+ return skb->len;
+
+rtattr_failure:
+ nlmsg_trim(skb, b);
+ kfree(opt);
+ return -1;
+}
+
+static struct tc_action_ops act_nat_ops = {
+ .kind = "nat",
+ .hinfo = &nat_hash_info,
+ .type = TCA_ACT_NAT,
+ .capab = TCA_CAP_NONE,
+ .owner = THIS_MODULE,
+ .act = tcf_nat,
+ .dump = tcf_nat_dump,
+ .cleanup = tcf_nat_cleanup,
+ .lookup = tcf_hash_search,
+ .init = tcf_nat_init,
+ .walk = tcf_generic_walker
+};
+
+MODULE_DESCRIPTION("Stateless NAT actions");
+MODULE_LICENSE("GPL");
+
+static int __init nat_init_module(void)
+{
+ return tcf_register_action(&act_nat_ops);
+}
+
+static void __exit nat_cleanup_module(void)
+{
+ tcf_unregister_action(&act_nat_ops);
+}
+
+module_init(nat_init_module);
+module_exit(nat_cleanup_module);
^ permalink raw reply related
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: Jeff Garzik @ 2007-09-27 7:31 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: hare, open-iscsi, hch, davem, mchristi, netdev, anilgv, talm,
lusinsky, uri, fujita.tomonori, Benjamin Herrenschmidt
In-Reply-To: <20070925133624H.tomof@acm.org>
FUJITA Tomonori wrote:
> Yeah, we could nicely handle lld's restrictions (especially with
> stacking devices). But iommu code needs only max_segment_size and
> seg_boundary_mask, right? If so, the first simple approach to add two
> values to device structure is not so bad, I think.
(replying to slightly older email in the thread)
(added benh, since we've discussed this issue in the past)
dumb question, what happened to seg_boundary_mask?
If you look at drivers/ata/libata-core.c:ata_fill_sg(), you will note
that we split s/g segments after DMA-mapping. Looking at libata LLDD's,
you will also note judicious use of ATA_DMA_BOUNDARY (0xffff).
It was drilled into my head by James and benh that I cannot rely on the
DMA boundary + block/scsi + dma_map_sg() to ensure that my S/G segments
never cross a 64K boundary, a legacy IDE requirement. Thus the
additional code in ata_fill_sg() to split S/G segments straddling 64K,
in addition to setting dma boundary to 0xffff.
A key problem I was hoping would be solved with your work here was the
elimination of that post dma_map_sg() split.
If I understood James and Ben correctly, one of the key problems was
always in communicating libata's segment boundary needs to the IOMMU layers?
Jeff
^ permalink raw reply
* Re: e100 problems in .23rc8 ?
From: Herbert Xu @ 2007-09-27 6:58 UTC (permalink / raw)
To: Kok, Auke; +Cc: davej, netdev
In-Reply-To: <46FAA083.9020604@intel.com>
Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> Dave Jones wrote:
>> Last night, I hit this bug during boot up..
>> http://www.codemonkey.org.uk/junk/e100-2.jpg
>>
>> This morning, I got a mail from a Fedora user of the same
>> .23-rc8 based kernel that has seen a different trace
>> also implicating e100..
>>
>> http://www.codemonkey.org.uk/junk/e100.jpg
>>
>> It may be that the two problems are unrelated, and it's
>> just coincidence that both reports happen to be on an e100,
>> but the timing is odd. Have there been other reports
>> of similar problems recently ?
>
> there hasn't been a change to e100 in two months now - perhaps something slipped
> into the stack that broke it? If this reproduces, could you bisect?
Well this looks exactly like the e1000 race that we fixed around
the time of the last kernel release. That fix never made it into
e100 so it's no surprise that we get a similar crash here.
The problem is that if a spurious interrupt comes in between
request_irq and netif_poll_enable then you'll get a crash at
the next netif_rx_complete.
It'd be good if this were reproducible as it would allow us
to identify the source of the spurious interrupt, which may
well be caused by an unrelated bug somewhere else.
In any case, e100 should be prepared to deal with spurious
interrupts as e1000 has been fixed to do.
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
* Linux networking implementation and packet capture
From: Gaurav Aggarwal @ 2007-09-27 6:47 UTC (permalink / raw)
To: kernelnewbies, linux-net, netdev
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Hi,
I am trying to understand the implementation of linux 2.4 and linux 2.6's
networking (IPV4) . Can anyone give me some idea/pointers about some of the
good resources/whitepapers available in the market to understand the same.
If there is any document that mention the changes between the implementation
of networking in 2.4 & 2.6
I am also trying to write a simple program(preferably a userspace
application) which captures all the incoming and outgoing packets of a
particular machine (preferably at PREROUTING stage), then according to the
SRC/DST addresses, changes the IP address of some of the packets and then
reinject it back into the local IP stack. I am able to do that in 2.4 kernel
by using libipq and ip_tables but that prog is not running in 2.6 kernel.
(It hits at ip_route_BUG). Any idea or code snippet will be really
appreciated.
--
Regards,
Gaurav Aggarwal
[-- Attachment #2: Type: text/html, Size: 924 bytes --]
^ permalink raw reply
* Re: [patch 10/11] net: use numa_node in net_device->dev instead of parent
From: Jeff Garzik @ 2007-09-27 5:50 UTC (permalink / raw)
To: David Miller; +Cc: akpm, Yinghai.Lu, Andi Kleen, Al Viro, netdev
In-Reply-To: <20070926.223831.44964319.davem@davemloft.net>
(warning, adjusted CC's and added netdev mailing list)
David Miller wrote:
> From: akpm@linux-foundation.org
> Date: Wed, 26 Sep 2007 18:14:42 -0700
>
>> From: Yinghai Lu <Yinghai.Lu@Sun.COM>
>>
>> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>> Cc: Christoph Lameter <clameter@sgi.com>
>> Cc: Andy Whitcroft <apw@shadowen.org>
>> Cc: Jeff Garzik <jeff@garzik.org>
>> Cc: Andi Kleen <ak@suse.de>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> I'm not applying this, I'm still not convinced it is right.
>
> The device of netdev->dev is a network subsystem pseudo device and
> it's not a real I/O device at all. It's there for creating the
> class/net/name info under sysfs for the network device.
>
> So pulling the NUMA node information out of there is completely
Agreed.
> illogical even if you do add some ugly hack to propagate the NUMA
> information from the I/O device parent into the device struct the
> netdev has embedded in it.
I don't think it's an ugly hack at all. The following is the standard
way to tell the net device your parent:
#define SET_NETDEV_DEV(net, pdev) ((net)->dev.parent = (pdev))
so therefore reading the parent is the standard (only?) way to retrieve
that same information.
Using IETF RFC language: Every net driver SHOULD have an associated
struct device via SET_NETDEV_DEV(), even if it's another pseudo-device
in the case where the net_device is not associated with real hardware.
However, that said, the overall /system/ employed here is a hack,
because SET_NETDEV_DEV() does not actually adjust any reference counts
or anything, for the associated net_device or associated struct device.
Al Viro pointed out problems related to this, ISTR, when someone tried
to convert net drivers over to using the new devres stuff. That's why I
haven't been merging the devres net driver conversions -- they
exacerbate existing object lifetime-related problems.
Jeff
^ permalink raw reply
* Re: [PATCH] netns: Simplify the network namespace list locking rules.
From: David Miller @ 2007-09-27 5:40 UTC (permalink / raw)
To: ebiederm; +Cc: dlezcano, benjamin.thery, dev, den, containers, netdev
In-Reply-To: <m1r6kkrce0.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 21:54:47 -0600
>
> Denis V. Lunev <den@sw.ru> noticed that the locking rules
> for the network namespace list are over complicated and broken.
>
> In particular the current register_netdev_notifier currently
> does not take any lock making the for_each_net iteration racy
> with network namespace creation and destruction. Oops.
>
> The fact that we need to use for_each_net in rtnl_unlock() when
> the rtnetlink support becomes per network namespace makes designing
> the proper locking tricky. In addition we need to be able to call
> rtnl_lock() and rtnl_unlock() when we have the net_mutex held.
>
> After thinking about it and looking at the alternatives carefully
> it looks like the simplest and most maintainable solution is
> to remove net_list_mutex altogether, and to use the rtnl_mutex instead.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] netns: Simplify the network namespace list locking rules.
From: Denis V. Lunev @ 2007-09-27 5:21 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Daniel Lezcano, Benjamin Thery, Kirill Korotaev,
Linux Containers, netdev
In-Reply-To: <m1r6kkrce0.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Denis V. Lunev <den@sw.ru> noticed that the locking rules
> for the network namespace list are over complicated and broken.
>
> In particular the current register_netdev_notifier currently
> does not take any lock making the for_each_net iteration racy
> with network namespace creation and destruction. Oops.
>
> The fact that we need to use for_each_net in rtnl_unlock() when
> the rtnetlink support becomes per network namespace makes designing
> the proper locking tricky. In addition we need to be able to call
> rtnl_lock() and rtnl_unlock() when we have the net_mutex held.
>
> After thinking about it and looking at the alternatives carefully
> it looks like the simplest and most maintainable solution is
> to remove net_list_mutex altogether, and to use the rtnl_mutex instead.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Denis V. Lunev <den@openvz.org>
^ permalink raw reply
* Re: [PATCH 3/3] net-2.6.24: move hardware header operations out of netdevice
From: David Miller @ 2007-09-27 5:20 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20070926172246.0425e232@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 26 Sep 2007 17:22:46 -0700
> Since hardware header operations are part of the protocol class
> not the device instance, make them into a separate object and
> save memory.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
I applied this by hand since there were conflicts with Eric B.'s
round of network namespace patches from today which I applied
first.
Also:
> --- a/drivers/net/hamradio/6pack.c 2007-09-26 15:07:23.000000000 -0700
> +++ b/drivers/net/hamradio/6pack.c 2007-09-26 16:41:09.000000000 -0700
> @@ -3,7 +3,7 @@
> * devices like TTY. It interfaces between a raw TTY and the
> * kernel's AX.25 protocol layers.
> *
> - * Authors: Andreas Könsgen <ajk@iehk.rwth-aachen.de>
> + * Authors: Andreas Könsgen <ajk@iehk.rwth-aachen.de>
> * Ralf Baechle DL5RB <ralf@linux-mips.org>
> *
> * Quite a lot of stuff "stolen" by Joerg Reuter from slip.c, written by
This hunk rejected and I therefore left it out.
Whatever editor you used aparently tried to change the character set
encoding or something silly like that.
^ permalink raw reply
* Re: [PATCH 2/3] net-2.6.24: wrap hard_header_parse
From: David Miller @ 2007-09-27 5:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20070926172137.5c77baeb@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 26 Sep 2007 17:21:37 -0700
> Wrap the hard_header_parse function to simplify next step
> of header_ops conversion.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] net-2.6.24: wrap netdevice hardware header creation
From: David Miller @ 2007-09-27 5:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20070926172129.5550a636@freepuppy.rosehill>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 26 Sep 2007 17:21:29 -0700
>
> Add inline for common usage of hardware header creation, and
> fix bug in IPV6 mcast where the assumption about negative return is
> an errno. Negative return from hard_header means not enough space
> was available,(ie -N bytes).
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/4] net: Make the loopback device per network namespace
From: David Miller @ 2007-09-27 5:11 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m17imdrn8r.fsf_-_@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 18:00:20 -0600
>
> This patch makes loopback_dev per network namespace. Adding
> code to create a different loopback device for each network
> namespace and adding the code to free a loopback device
> when a network namespace exits.
>
> This patch modifies all users the loopback_dev so they
> access it as init_net.loopback_dev, keeping all of the
> code compiling and working. A later pass will be needed to
> update the users to use something other than the initial network
> namespace.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied to net-2.6.24, thanks Eric.
^ permalink raw reply
* Re: [PATCH 3/4] net ipv4: When possible test for IFF_LOOPBACK and not dev == loopback_dev
From: David Miller @ 2007-09-27 5:10 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1bqbprnc2.fsf_-_@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:58:21 -0600
>
> Now that multiple loopback devices are becoming possible it makes
> the code a little cleaner and more maintainable to test if a deivice
> is th a loopback device by testing dev->flags & IFF_LOOPBACK instead
> of dev == loopback_dev.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] net ipv4: Remove unnecessary test for the loopback device from inetdev_destroy
From: David Miller @ 2007-09-27 5:09 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1ir5xrngu.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:55:29 -0600
>
> Currently we never call unregister_netdev for the loopback device so
> it is impossible for us to reach inetdev_destroy with the loopback
> device. So the test in inetdev_destroy is unnecessary.
>
> Further when testing with my network namespace patches removing
> unregistering the loopback device and calling inetdev_destroy works
> fine so there appears to be no reason for avoiding unregistering the
> loopback device.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Fair enough, applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH 1/4] net: Dynamically allocate the per cpu counters for the loopback device.
From: David Miller @ 2007-09-27 5:09 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1ps05rnjv.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:53:40 -0600
>
> This patch add support for dynamically allocating the statistics counters
> for the loopback device and adds appropriate device methods for allocating
> and freeing the loopback device.
>
> This completes support for creating multiple instances of the loopback
> device, in preparation for creating per network namespace instances.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied to net-2.6.24, thanks.
> @@ -155,7 +154,8 @@ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
> dev->last_rx = jiffies;
>
> /* it's OK to use __get_cpu_var() because BHs are off */
> - lb_stats = &__get_cpu_var(pcpu_lstats);
> + pcpu_lstats = netdev_priv(dev);
> + lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
> lb_stats->bytes += skb->len;
> lb_stats->packets++;
>
I'm going to add a followon change that gets rid of that
comment about __get_cpu_var() since it is no longer
relevant.
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: David Miller @ 2007-09-27 5:04 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1tzphrnq5.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:49:54 -0600
>
> This patch allows you to create a new network namespace
> using sys_clone, or sys_unshare.
>
> As the network namespace is still experimental and under development
> clone and unshare support is only made available when CONFIG_NET_NS is
> selected at compile time.
>
> As this patch introduces network namespace support into code paths
> that exist when the CONFIG_NET is not selected there are a few
> additions made to net_namespace.h to allow a few more functions
> to be used when the networking stack is not compiled in.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied to net-2.6.24, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: Fix running without sysfs
From: David Miller @ 2007-09-27 5:03 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1zlz9rnt1.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:48:10 -0600
>
> When sysfs support is compiled out the kernel still keeps and maintains
> the kobject tree. So it is not safe to skip our kobject reference counting or
> to avoid becoming members of the kobject tree. It is safe to not add
> the networking specific sysfs attributes.
>
> This patch removes the sysfs special cases from net/core/dev.c
> renames functions from netdev_sysfs_xxxx to netdev_kobject_xxxx
> and always compiles in net-sysfs.c
>
> net-sysfs.c is modified with a CONFIG_SYSFS guard around the parts
> that are actually sysfs specific.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH] [TCP] MIB: Fine-tune reordered ACK's SACK block counting more
From: David Miller @ 2007-09-27 5:01 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0709261653110.5141@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 26 Sep 2007 17:07:04 +0300 (EEST)
> Hmm, thought a bit more about it... How about this then? No additional
> counter. Compile tested. Not that I see a large benefit from it, in theory
> could help logging in some malicious attempt cases; we safely discarded in
> such case anyway... ...of course if somebody is paranoid enough one might
> rejoice in it more than I do... :-) Buggy cases will very likely show up
> regardless this reordering corner-case.
I don't think this is worthwile, passing extra parameters around,
etc. for not much gain.
I'll therefore not apply this one, thanks!
^ 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