* Re: [PKT_SCHED]: Add stateless NAT
From: Evgeniy Polyakov @ 2007-09-27 10:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev, Alexey Kuznetsov, jamal
In-Reply-To: <20070927093358.GA15357@gondor.apana.org.au>
On Thu, Sep 27, 2007 at 05:33:58PM +0800, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> > > +config NET_ACT_NAT
> > > + tristate "Stateless NAT"
> > > + depends on NET_CLS_ACT
> > > + select NETFILTER
> >
> > Argh... People usually do not understand such jokes :)
> > What about not using netfilter helpers and just move them to the
> > accessible header so that no additional slow path would ever be enabled?
>
> Sure. However, as it is it's just including the netfilter core
> which does not mean the inclusion of connection trakcing. It's
> only connection tracking that *may* (so don't flame me for this :)
> pose a scalability problem.
It forces all inpuit/pre/post/forward hooks to be enbled not as a direct
function call, but as additional lookups. And unability to remove
netfilter from config. And just because of couple of checksum helpers...
> > > +++ b/net/sched/act_nat.c
> > ...
> > > +#define NAT_TAB_MASK 15
> >
> > This really wants to be configurable at least via module parameter.
> >
> > > +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,
> > > +};
> >
> > When I read this I swear I heard 'I want to be RCU'.
> > But that is another task.
>
> Yes there are a lot of clean-up's that can be done for all
> actions. You're most welcome to send patches in this area.
>
> > > + tcph = (void *)(skb_network_header(skb) + ihl);
> >
> > Were you too lazy to write struct tcphdr here and in other places? :)
>
> Unfortunately it doesn't work. For prerouting, we've not
> entered the IP stack yet so the transport header isn't set.
I meant instead of dereferencing to void * it should be struct tcphdr *.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PKT_SCHED]: Add stateless NAT
From: Herbert Xu @ 2007-09-27 9:33 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, netdev, Alexey Kuznetsov, jamal
In-Reply-To: <20070927092512.GD29329@2ka.mipt.ru>
On Thu, Sep 27, 2007 at 01:25:12PM +0400, Evgeniy Polyakov wrote:
>
> Couple of comments below.
Thanks Evgeniey :)
> > --- 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
>
> Argh... People usually do not understand such jokes :)
> What about not using netfilter helpers and just move them to the
> accessible header so that no additional slow path would ever be enabled?
Sure. However, as it is it's just including the netfilter core
which does not mean the inclusion of connection trakcing. It's
only connection tracking that *may* (so don't flame me for this :)
pose a scalability problem.
> > + ---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.
> > +
>
> Modile will be called 'nat' I believe.
Good catch, now you know where I copied it from :)
> > +++ b/net/sched/act_nat.c
> ...
> > +#define NAT_TAB_MASK 15
>
> This really wants to be configurable at least via module parameter.
>
> > +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,
> > +};
>
> When I read this I swear I heard 'I want to be RCU'.
> But that is another task.
Yes there are a lot of clean-up's that can be done for all
actions. You're most welcome to send patches in this area.
> > + tcph = (void *)(skb_network_header(skb) + ihl);
>
> Were you too lazy to write struct tcphdr here and in other places? :)
Unfortunately it doesn't work. For prerouting, we've not
entered the IP stack yet so the transport header isn't set.
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: [PKT_SCHED]: Add stateless NAT
From: Evgeniy Polyakov @ 2007-09-27 9:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev, Alexey Kuznetsov, jamal
In-Reply-To: <20070927073446.GA14643@gondor.apana.org.au>
Hi Herbert.
On Thu, Sep 27, 2007 at 03:34:47PM +0800, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> 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.
Couple of comments below.
> --- 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
Argh... People usually do not understand such jokes :)
What about not using netfilter helpers and just move them to the
accessible header so that no additional slow path would ever be enabled?
> + ---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.
> +
Modile will be called 'nat' I believe.
> +++ b/net/sched/act_nat.c
...
> +#define NAT_TAB_MASK 15
This really wants to be configurable at least via module parameter.
> +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,
> +};
When I read this I swear I heard 'I want to be RCU'.
But that is another task.
> +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);
Were you too lazy to write struct tcphdr here and in other places? :)
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] sky2: sky2 FE+ receive status workaround
From: Jochen Voß @ 2007-09-27 8:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, netdev
In-Reply-To: <20070926175847.706025d0@freepuppy.rosehill>
Hi Stephen,
On 27 Sep 2007, at 01:58, Stephen Hemminger wrote:
> + /* This chip has hardware problems that generates bogus status.
> + * So do only marginal checking and expect higher level protocols
> + * to handle crap frames.
> + */
> + if (sky2->hw->chip_id == CHIP_ID_YUKON_FE_P &&
> + sky2->hw->chip_rev == CHIP_REV_YU_FE2_A0 &&
> + length != count)
> + goto okay;
Shouldn't the condition be "length == count"?
I hope this helps,
Jochen
--
http://seehuhn.de/
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: Cedric Le Goater @ 2007-09-27 8:51 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: David Miller, Linux Containers, netdev
In-Reply-To: <m1tzphrnq5.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> 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>
> ---
> include/linux/sched.h | 1 +
> include/net/net_namespace.h | 18 ++++++++++++++++++
> kernel/fork.c | 3 ++-
> kernel/nsproxy.c | 15 +++++++++++++--
> net/Kconfig | 8 ++++++++
> net/core/net_namespace.c | 43 +++++++++++++++++++++++++++++++++++++++++--
> 6 files changed, 83 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index a01ac6d..e10a0a8 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -27,6 +27,7 @@
> #define CLONE_NEWUTS 0x04000000 /* New utsname group? */
> #define CLONE_NEWIPC 0x08000000 /* New ipcs */
> #define CLONE_NEWUSER 0x10000000 /* New user namespace */
> +#define CLONE_NEWNET 0x20000000 /* New network namespace */
This new flag is going to conflict with the pid namespace flag
CLONE_NEWPID in -mm. It might be worth changing it to:
#define CLONE_NEWNET 0x40000000
The changes in nxproxy.c and fork.c will also conflict but I don't
think we can do much about it for now.
C.
> /*
> * Scheduling policies
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index ac8f830..3ea4194 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -38,11 +38,23 @@ extern struct net init_net;
>
> extern struct list_head net_namespace_list;
>
> +#ifdef CONFIG_NET
> +extern struct net *copy_net_ns(unsigned long flags, struct net *net_ns);
> +#else
> +static inline struct net *copy_net_ns(unsigned long flags, struct net *net_ns)
> +{
> + /* There is nothing to copy so this is a noop */
> + return net_ns;
> +}
> +#endif
> +
> extern void __put_net(struct net *net);
>
> static inline struct net *get_net(struct net *net)
> {
> +#ifdef CONFIG_NET
> atomic_inc(&net->count);
> +#endif
> return net;
> }
>
> @@ -60,19 +72,25 @@ static inline struct net *maybe_get_net(struct net *net)
>
> static inline void put_net(struct net *net)
> {
> +#ifdef CONFIG_NET
> if (atomic_dec_and_test(&net->count))
> __put_net(net);
> +#endif
> }
>
> static inline struct net *hold_net(struct net *net)
> {
> +#ifdef CONFIG_NET
> atomic_inc(&net->use_count);
> +#endif
> return net;
> }
>
> static inline void release_net(struct net *net)
> {
> +#ifdef CONFIG_NET
> atomic_dec(&net->use_count);
> +#endif
> }
>
> extern void net_lock(void);
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 33f12f4..5e67f90 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1608,7 +1608,8 @@ asmlinkage long sys_unshare(unsigned long unshare_flags)
> err = -EINVAL;
> if (unshare_flags & ~(CLONE_THREAD|CLONE_FS|CLONE_NEWNS|CLONE_SIGHAND|
> CLONE_VM|CLONE_FILES|CLONE_SYSVSEM|
> - CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWUSER))
> + CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWUSER|
> + CLONE_NEWNET))
> goto bad_unshare_out;
>
> if ((err = unshare_thread(unshare_flags)))
> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index a4fb7d4..f1decd2 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -20,6 +20,7 @@
> #include <linux/mnt_namespace.h>
> #include <linux/utsname.h>
> #include <linux/pid_namespace.h>
> +#include <net/net_namespace.h>
>
> static struct kmem_cache *nsproxy_cachep;
>
> @@ -98,8 +99,17 @@ static struct nsproxy *create_new_namespaces(unsigned long flags,
> goto out_user;
> }
>
> + new_nsp->net_ns = copy_net_ns(flags, tsk->nsproxy->net_ns);
> + if (IS_ERR(new_nsp->net_ns)) {
> + err = PTR_ERR(new_nsp->net_ns);
> + goto out_net;
> + }
> +
> return new_nsp;
>
> +out_net:
> + if (new_nsp->user_ns)
> + put_user_ns(new_nsp->user_ns);
> out_user:
> if (new_nsp->pid_ns)
> put_pid_ns(new_nsp->pid_ns);
> @@ -132,7 +142,7 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk)
>
> get_nsproxy(old_ns);
>
> - if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER)))
> + if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWNET)))
> return 0;
>
> if (!capable(CAP_SYS_ADMIN)) {
> @@ -164,6 +174,7 @@ void free_nsproxy(struct nsproxy *ns)
> put_pid_ns(ns->pid_ns);
> if (ns->user_ns)
> put_user_ns(ns->user_ns);
> + put_net(ns->net_ns);
> kmem_cache_free(nsproxy_cachep, ns);
> }
>
> @@ -177,7 +188,7 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
> int err = 0;
>
> if (!(unshare_flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC |
> - CLONE_NEWUSER)))
> + CLONE_NEWUSER | CLONE_NEWNET)))
> return 0;
>
> if (!capable(CAP_SYS_ADMIN))
> diff --git a/net/Kconfig b/net/Kconfig
> index cdba08c..ab4e6da 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -27,6 +27,14 @@ if NET
>
> menu "Networking options"
>
> +config NET_NS
> + bool "Network namespace support"
> + default n
> + depends on EXPERIMENTAL && !SYSFS
> + help
> + Allow user space to create what appear to be multiple instances
> + of the network stack.
> +
> source "net/packet/Kconfig"
> source "net/unix/Kconfig"
> source "net/xfrm/Kconfig"
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 0e6cb02..e478e35 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -4,6 +4,7 @@
> #include <linux/slab.h>
> #include <linux/list.h>
> #include <linux/delay.h>
> +#include <linux/sched.h>
> #include <net/net_namespace.h>
>
> /*
> @@ -32,12 +33,10 @@ void net_unlock(void)
> mutex_unlock(&net_list_mutex);
> }
>
> -#if 0
> static struct net *net_alloc(void)
> {
> return kmem_cache_alloc(net_cachep, GFP_KERNEL);
> }
> -#endif
>
> static void net_free(struct net *net)
> {
> @@ -128,6 +127,46 @@ out_undo:
> goto out;
> }
>
> +struct net *copy_net_ns(unsigned long flags, struct net *old_net)
> +{
> + struct net *new_net = NULL;
> + int err;
> +
> + get_net(old_net);
> +
> + if (!(flags & CLONE_NEWNET))
> + return old_net;
> +
> +#ifndef CONFIG_NET_NS
> + return ERR_PTR(-EINVAL);
> +#endif
> +
> + err = -ENOMEM;
> + new_net = net_alloc();
> + if (!new_net)
> + goto out;
> +
> + mutex_lock(&net_mutex);
> + err = setup_net(new_net);
> + if (err)
> + goto out_unlock;
> +
> + net_lock();
> + list_add_tail(&new_net->list, &net_namespace_list);
> + net_unlock();
> +
> +
> +out_unlock:
> + mutex_unlock(&net_mutex);
> +out:
> + put_net(old_net);
> + if (err) {
> + net_free(new_net);
> + new_net = ERR_PTR(err);
> + }
> + return new_net;
> +}
> +
> static int __init net_ns_init(void)
> {
> int err;
^ permalink raw reply
* Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
From: FUJITA Tomonori @ 2007-09-27 8:46 UTC (permalink / raw)
To: jeff
Cc: benh, tomof, hare, open-iscsi, hch, davem, mchristi, netdev,
anilgv, talm, lusinsky, uri, fujita.tomonori, jens.axboe,
James.Bottomley, linux-scsi
In-Reply-To: <46FB6837.7040308@garzik.org>
CC'ed Jens, James, and linux-scsi again.
On Thu, 27 Sep 2007 04:22:15 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> 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).
As I said in another mail, the block layer and scsi-ml work properly,
I think. So there is no need to split sg lists for no-iommu platforms.
We need to fix only iommu code merge sglists (already done) for the
segment size restriction but we need to fix all iommu code and swiotlb
for the segment boundary restriction. Splitting sg list might be
useful for the case that iommu can't find a proper boundary memory
area. But I think that it rarely happens (and there are few llds has
the boundary restriction).
^ permalink raw reply
* 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
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