Kok, Auke wrote:
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all of
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it
Joonwoo Park wrote:
2007/11/13, David Miller <[EMAIL PROTECTED]>:
From: Willy Tarreau <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 00:32:57 +0100
At least, being able to disable the feature at module load time
would be acceptable. Many people who often need to sniff on decent
machines wo
Herbert Xu wrote:
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
imply that they wish to see e
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for e1000e as
well?
Patch for e1000 attached.
Does
Rainer Jochem wrote:
Corrected version below.
+ printk(KERN_INFO "Sending class identifier \"%s\"\n",
+ vendor_class_identifier);
Seems like useless noise.
This information is only sent in the case that the option is actually used.
And in th
Kok, Auke wrote:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as
Rainer Jochem wrote:
I don't think its very useful since you can simply get this information
from /proc/cmdline in case something goes wrong, but if you insist at
least give it a meaningful prefix.
Added.
The initialization is unnecessary.
Removed.
Should be >= I think.
Fixed.
Look
Herbert Xu wrote:
BTW, how does the VLAN TX acceleration work at all? It's using
skb->cb to carry the tags but then calls dev_queue_xmit. Once
you do that packet schedulers can scribble all over skb->cb.
Also vlan_skb_recv should be moved out-of-line. It's absolutely
humongous. It'll generate
deletions(-)
Patrick McHardy (3):
[HWRNG]: move status polling loop to data_present callbacks
[HIFN]: Improve PLL initialization
[HIFN]: Add support for using the random number generator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
[HWRNG]: move status polling loop to data_present callbacks
Handle waiting for new random within the drivers themselves, this allows to
use better suited timeouts for the individual rngs.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 5632554998aafc5605635f842bca50d5353cd9d
r external) and its frequency and uses that to calculate the
optimum multiplier to reach the maximal speed. By default it uses
the external clock and assumes a speed of 66MHz, which effectively
halfs the frequency currently used.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]
[HIFN]: Add support for using the random number generator
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 352a65d036f53c1e124bef4205d6fcedb78eac2c
tree 190bb0b4a1795e55096552f743af996df2766070
parent 70467fae3a656562f86adefdfe6d54e3ca20feeb
author Patrick McHardy <[EMAIL
Paul E. McKenney wrote:
Hello!
While reviewing rcu_dereference() uses, I came across a number of cases
where I couldn't see how the rcu_dereference() helped. One class of
cases is where the variable is never subsequently dereferenced, so that
patches like the following one would be appropriate.
Jesper Juhl wrote:
> This patch cleans up duplicate includes in
> net/netfilter/
I've queued this one and the bridge-netfilter patch (27/37), thanks
Jesper.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Athanasius wrote:
I'll compile up a new kernel, likely 2.6.22.6, plus this patch, and
reboot to it tonight. I still don't know *exactly* how to trigger the
bug on demand though, it's not reocurred since I posted the bug report
(but had happened about a week before as well).
Thanks. I'm not
Athanasius wrote:
On Sat, Sep 01, 2007 at 06:38:23PM +0200, Patrick McHardy wrote:
You might be able to trigger it without this patch by running
"while true; do ss -tn; done" while doing ident queries, but
just running the while loop a couple of times in parallel
doesn't see
Herbert Xu wrote:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
Thanks. I'm not sure either, it would require two concurrent requests
to be processed, but AFAICS oidentd only uses a single netlink socket.
Perhaps multiple running instances or something else using the inet_dia
Satyam Sharma wrote:
net/sched/sch_cbq.c: In function 'cbq_enqueue':
net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this
function
has been verified to be a bogus case. So let's shut it up.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]&
Neil Horman wrote:
> Hey all-
> So I've had a deadlock reported to me. I've found that the sequence of
> events goes like this:
>
> 1) process A (modprobe) runs to remove ip_tables.ko
>
> 2) process B (iptables-restore) runs and calls setsockopt on a netfilter
> socket,
> increasing the i
Neil Horman wrote:
> On Thu, Sep 06, 2007 at 02:13:26AM +1000, Rusty Russell wrote:
>
>>On Wed, 2007-09-05 at 17:22 +0200, Patrick McHardy wrote:
>>
>>>But I'm wondering, wouldn't module refcounting alone fix this problem?
>>>If we make nf_sockopt()
Jesper Juhl wrote:
> There is a small problem in
> net/ipv4/netfilter/ipt_recent.c::recent_seq_open().
>
> If the call to seq_open() returns != 0 then the code calls
> kfree(st) but then on the very next line proceeds to
> dereference the pointer - not good.
Applied, thanks Jesper.
-
To unsu
Adrian Bunk wrote:
> nf_ct_ipv6_skip_exthdr() can now become static.
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
82ef0c5 is first bad commit
commit ff09b7493c8f433d3ffd6a31ad58d190f82ef0c5
Author: Yasuyuki Kozakai <[EMAIL PROTECTED]>
Date: Sat Jul 7 22:25:28 2007 -0700
[NETFILTER]: nf_nat: remove unused nf_nat_module_is_loaded
Signed-off-by: Yasuyuki Kozakai <[EMAIL PROTECTED]>
Signed-o
Joe Perches wrote:
diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c
index 74f9b14..bec4279 100644
--- a/net/netfilter/xt_u32.c
+++ b/net/netfilter/xt_u32.c
@@ -36,7 +36,7 @@ static bool u32_match_it(const struct xt_u32 *data,
at = 0;
pos = ct->location
Andy Whitcroft wrote:
> It seems an extraneous trailing ';' has slipped into the skb length
> checks in u32_match_it() triggering an unconditional missmatch.
Thanks, this already fixed in net-2.6 and should hit Linus' tree soon.
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>Al Boldi wrote:
>>
>>>Well, for example to stop any transient packets being forwarded. You
>>>could probably hack around this using mark's, but you can't stop the
>>>implied route lookup, unless
Jan Engelhardt wrote:
> On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>>The netlink based iptables successor I'm currently working on allows to
>>dynamically create tables with user-specified priorities and "built-in"
>>chains. The only built-in tables wil
Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things. Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
>
>
> Well, for example to stop any transient packets
Jan Engelhardt wrote:
> On Oct 12 2007 16:30, Al Boldi wrote:
With the existence of the mangle table, how useful is the filter table?
>>>
>>>A similar discussion was back in March 2007.
>>>http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
>>>http://marc.info/?l=netfilter-devel&m=11
Al Boldi wrote:
Patrick McHardy wrote:
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and "built-in"
chains. The only built-in tables will be those that need extra
processing (mangle/nat).
Andy Whitcroft wrote:
Seems we are getting some kind of bug out of our s390x partition (lnxabat1)
when booting latest mainline releases, specifically since 2.6.23-git3.
Kernel BUG at 0002 Ýverbose debug info unavailable?
illegal operation: 0001 Ý#1?
Modules linked in: dm_mod sit tunn
Dave Johnson wrote:
+/* VLAN rx hw acceleration helper. This acts like netif_{rx,receive_skb}(). */
+static inline int __vlan_hwaccel_rx(struct sk_buff *skb,
+ struct vlan_group *grp,
+ unsigned short vlan_tag, int polling)
+{
.
David Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 05 Nov 2007 19:00:19 +0100
This looks like a rather expensive operation for the unlikely case
that packets will be received by a packet socket. IMO it should only
be reconstructed if actually needed, by af_packet
Krzysztof Halasa wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
I think there is one more case that matters, which is briding
from a device with VLAN stripping for a VLAN not configured
locally. The tag will be stripped and will be lost for forwarded
packets.
I think we should dro
Rainer Jochem wrote:
--- net/ipv4/ipconfig.c.orig2007-11-08 14:54:11.001662860 +0100
+++ net/ipv4/ipconfig.c 2007-11-08 14:54:15.961480524 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_pa
Mikael Pettersson wrote:
> include/net/netfilter/nf_conntrack_compat.h: In function
> 'nf_ct_l3proto_try_module_get':
> include/net/netfilter/nf_conntrack_compat.h:70: error: 'PF_INET' undeclared
> (first use in this function)
> include/net/netfilter/nf_conntrack_compat.h:70: error: (Each undecla
Jan Engelhardt wrote:
> On Jan 14 2007 20:20, David Madore wrote:
>
>>Implement TCPMSS target for IPv6 by shamelessly copying from
>>Marc Boucher's IPv4 implementation.
>>
>>Signed-off-by: David A. Madore <[EMAIL PROTECTED]>
>
>
> Would not it be worthwhile to merge ipt_TCPMSS and
> ip6t_TCPMSS
David Madore wrote:
> On Sun, Jan 14, 2007 at 09:10:45PM +0100, Jan Engelhardt wrote:
>
>>On Jan 14 2007 20:20, David Madore wrote:
>>
>>>Implement TCPMSS target for IPv6 by shamelessly copying from
>>>Marc Boucher's IPv4 implementation.
>>
>>Would not it be worthwhile to merge ipt_TCPMSS and
>>ip
Jan Engelhardt wrote:
> On Jan 15 2007 09:39, Patrick McHardy wrote:
>
>>I'm not sure how well that will work (the IPv4/IPv6-specific stuff
>>is spread over the entire target function), but its worth a try.
>
>
> "Nothing is impossible." Since yo
Martin Josefsson wrote:
> Check the return value of nfct_nat() in device_cmp(), we might very well
> have non NAT conntrack entries as well.
>
> Signed-off-by: Martin Josefsson <[EMAIL PROTECTED]>
Applied, thanks Martin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Chuck Ebbert wrote:
> Chuck Ebbert wrote:
>
>>I was testing a 2.6.20 kernel and got a soft
>>lockup on shutdown:
>>
>>_raw_write_lock+0x5a
>>nf_ct_iterate_cleanup+0x3e
>>kill_l3proto+0x0
>>nf_conntrack_l3proto_unregister+0x85
>>nf_conntrack_l3proto_ipv4_fini+0x1e
>>sys_delete_module+0x18a
>>remove
Peter Zijlstra wrote:
> Emergency skbs should never touch user-space, however NF_QUEUE is fully user
> configurable. Notify the user of his mistake and try to continue.
>
> --- linux-2.6-git.orig/net/netfilter/core.c 2007-02-14 12:09:07.0
> +0100
> +++ linux-2.6-git/net/netfilter/core.c
Peter Zijlstra wrote:
> On Sat, 2007-02-24 at 16:27 +0100, Patrick McHardy wrote:
>
>>> } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
>>>+if (unlikely((*pskb)->emergency)) {
>>>+printk(KER
Peter Zijlstra wrote:
> On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote:
>
>
>>I don't really see why
>>queueing is special though, dropping the packets in the ruleset
>>will break things just as well, as will routing them to a blackhole.
>>I guess
ize_net() prior to walking the conntrack hash.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 08ace206d2703e377efebe1852539177458593ff
tree 1d27d4759a77db062d48c4420459c810e7fec14a
parent 9654640d0af8f2de40ff3807d3695109d3463f54
author Patrick McHardy <[EMAIL PROTECTED]>
Martin Josefsson wrote:
> What about this case:
>
> 1. Conntrack entry is created and placed on the unconfirmed list
> 2. The event cache bumps the refcount of the conntrack entry
> 3. module removal of ip_conntrack unregisters all hooks
> 4. packet is dropped by an iptables rule
> 5. packet is fr
() prior to walking the conntrack hash.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 7934f9001e23be06a1a5cbce1b68e2a64cf31a6e
tree fe74c1500d086d67071d323e84ce95d3e2faf650
parent 8d1117a9f5d302d8d460fbe7ef322b382e45c9ce
author Patrick McHardy <[EMAIL PROTECTED]> Mon,
Jan-Bernd Themann wrote:
> This patch provides a functionality that allows parallel
> RX processing on multiple RX queues by using dummy netdevices.
>
>
> +static inline int ehea_hash_skb(struct sk_buff *skb, int num_qps)
> +{
> + u32 tmp;
> + if ((skb->nh.iph->protocol == IPPROTO_TCP)
Chuck Ebbert wrote:
> Patrick McHardy wrote:
>
>>This patch is against current stable-2.6.20, it applies
>>cleanly to 2.6.20 as well.
>
>
> Everything works OK, but I get:
>
> BUG: warning: (!list_empty(&unconfirmed)) at
> net/netfilte
Micha³ Miros³aw wrote:
> get_*() don't need access to seq_file - iter_state is enough for them.
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
Micha³ Miros³aw wrote:
> Eliminate possible NULL pointer dereference in nfulnl_recv_config().
>
> Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
>
> --- linux-2.6.20/net/netfilter/nfnetlink_log.c.10 2007-02-12
> 17:05:14.0 +0100
> +++ linux-2.6.20/net/netfilter/nfnetlink_log.c
Micha³ Miros³aw wrote:
> Fix reference counting (memory leak) problem in __nfulnl_send() and callers
> related to packet queueing.
>
> Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
>
> --- linux-2.6.20/net/netfilter/nfnetlink_log.c.11 2007-02-12
> 17:35:50.0 +0100
> +++ linux-2.
n't enough to support IPV6=m,
NF_CONNTRACK_H323=y. For now I think Adrian's patch is the
best solution (IPV6=m isn't that useful anyway since it will
normally get loaded automatically when the first program
attempts to open an AF_INET6 socket and can't be unloaded),
but I'
Adrian Bunk wrote:
> This patch removes ip{,6}_queue that were scheduled for removal
> in mid-2005.
Thanks for the reminder, I forgot to remove the feature-removal-schedule
entry last time you asked.
We really can't remove ip_queue. Many users use this, there is no binary
compatible interface and
Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make the following needlessly global functions static:
> - net/netfilter/nf_conntrack_core.c: nf_conntrack_register_cache()
> - net/netfilter/nf_conntrack_core.c: nf_conntrack_unregister_cache()
> - net/netfilter/nf
Jan Engelhardt wrote:
> Reusing code is a good idea, and I would like to do so from my
> match modules. netfilter already provides a xt_request_find_target() but
> an xt_request_find_match() does not yet exist. This patch adds it.
Why does your match module needs to lookup other matches?
-
To u
Jan Engelhardt wrote:
> On Dec 19 2006 12:51, Patrick McHardy wrote:
>
>>>Reusing code is a good idea, and I would like to do so from my
>>>match modules. netfilter already provides a xt_request_find_target() but
>>>an xt_request_find_match() does not yet ex
Jan Engelhardt wrote:
> [...]
>
> Ok, but let's say I wanted to use a bigger match module (layer7, anyone?)
> Then it's just not if(protocol == IPPROTO_TCP). What's the preferred solution
> then?
Make sure the user specifies the match on the command line before
your match. Look at the TCPMSS or RE
Jan Engelhardt wrote:
>>Make sure the user specifies the match on the command line before
>>your match. Look at the TCPMSS or REJECT targets for examples for
>>this.
>
>
> That would mean I'd have to
>
> -p tcp -m multiport --dport 1,2,3,4 -m time --time sundays -m
> lotsofothers -j TARGET
>
Santiago Garcia Mantinan wrote:
> Hi!
>
> When trying to upgrade a machine from 2.6.18 to 2.6.19.1 I found that it
> crashed when loading the ebtables rules on startup.
>
> This is an example of the crash I get:
>
> BUG: unable to handle kernel paging request at virtual address e081e004
>
n struct
nf_conntrack_expect, which is then copied from the expectation to
the conntrack entry.
Peter, do you have locally generated netbios ns queries on the machine
running nf_conntrack? If so, please try this patch. Otherwise, are
there any other conntrack helpers that are actually used?
[NETFILTER]: nf_
g splits up a defragmented packet into
its original fragments, the packets are taken from a list and are
passed to the network stack with skb->next still set. This causes
dev_hard_start_xmit to treat them as GSO fragments, resulting in
a use after free when connection track
Bernhard Schmidt wrote:
> Patrick McHardy wrote:
>
>>> I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is
>>> reproducible, as soon as I load nf_conntrack_ipv6 and try to send
>>> something large (scp or so) inside an OpenVPN tunnel on my cl
Linus Torvalds wrote:
>
> On Tue, 9 Jan 2007, Tomasz Kvarsin wrote:
>
>>During boot into 2.6.20-rc4 iptables says
>>iptables-restore: line 15 failed.
>>And works fine with my default kernel: 2.6.18.x
>
>
> I bet you enabled the new transport-agnostic netfilter, and didn't enable
> some of the
Mikael Starvik wrote:
> I have a kernel with
>
> CONFIG_IP_NF_TABLES=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_LOG=y
>
> all other NF options are off.
Which iptables/kernel versions are you using?
> During kernel startup I get
> iptables: loop hook 1 pos 0022
>
> when filter tries to
Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
>
>
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
>
> same kernelconfig works on ARM. So I have to dig some...
On which architecture did the error occur? It could be related
to 32 bit compat i
Mikael Starvik wrote:
> Ok, this is what happens:
>
> iptable_filter sets up initial_table.
> The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" }
> initializes a xt_entry_target struct. target_size gets the value
> 0x24 and name "".
> This is copied to loc_cpu_entry in i
Faidon Liambotis wrote:
> H.323 connection tracking code calls ip_ct_refresh_acct() when
> processing RCFs and URQs but passes NULL as the skb.
> When CONFIG_IP_NF_CT_ACCT is enabled, the connection tracking core tries
> to derefence the skb, which results in an obvious panic.
> A similar fix was a
Krzysztof Halasa wrote:
> Hi,
>
> The following commit breaks ipt_REJECT on my machine. Tested with latest
> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
> All details available on request, of course.
>
> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are you abo
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>How sure are you about this? I can see nothing wrong with that
>>commit and can't reproduce the slab corruption. Please post
>>the rule that triggers this.
>
>
> 99% sure
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>It might be the case that your network device has a
>>hard_header_len > LL_MAX_HEADER, which could trigger
>>a corruption.
>
>
> Hmm... GRE tunnels add 24 bytes... I just
Jan Engelhardt wrote:
> On Jun 24 2007 15:08, Kyle Moffett wrote:
>
>>Do you really need that many IP addresses? When somebody finally gets
>>around to implementing REDIRECT support for ip6tables then you could
>>just redirect them all to the same port on the local system.
>
>
> The way I see i
Vasily Averin wrote:
> +static int early_drop(const struct nf_conntrack_tuple *orig)
> +{
> + unsigned int i, hash, cnt;
> + int ret = 0;
> +
> + hash = hash_conntrack(orig);
> + cnt = NF_CT_PER_BUCKET;
> +
> + for (i = 0;
> + !ret && cnt && i < nf_conntrack_htable_s
Oliver Neukum wrote:
> with 2.6.22-rc4-git2 I am getting errors when setting IP for ethernet
> interfaces:
>
> ioctl(4, SIOCSIFADDR, 0x7fff94931600) = -1 ENOBUFS (No buffer space
> available)
>
> The error is independant of the interface. It happens to all interfaces.
> There's nothing in the
Jan Engelhardt wrote:
> On Jun 12 2007 16:13, Oliver Neukum wrote:
>
>>>On Jun 12 2007 14:41, Oliver Neukum wrote:
>>>
with 2.6.22-rc4-git2 I am getting errors when setting IP for ethernet
interfaces:
ioctl(4, SIOCSIFADDR, 0x7fff94931600) = -1 ENOBUFS (No buffer space
avail
Oliver Neukum wrote:
> Am Dienstag, 12. Juni 2007 schrieb Patrick McHardy:
>
>>Oliver Neukum wrote:
>>
>>>with 2.6.22-rc4-git2 I am getting errors when setting IP for ethernet
>>>interfaces:
>>>
>>>ioctl(4, SIOCSIFADDR, 0x7fff94931600) =
Oliver Neukum wrote:
> Am Mittwoch, 13. Juni 2007 schrieb Patrick McHardy:
>>>>
>>>>This can happen if the initial inetdev allocation when the netdevice is
>>>>registered fails. I think it would make sense to try to allocate again
>>>>when addin
I get this oops with current -git:
[ 3437.018862] PGD 9acab067 PUD 9acaa067 PMD 0
[ 3437.018870] CPU 1
[ 3437.018872] Modules linked in: nfsd exportfs ppdev lp nfs lockd
nfs_acl sunrpc deflate zlib_deflate zlib_inflate twofish twofish_common
camellia serpent blowfish des cbc ecb blkcipher aes xcbc
Adam Osuchowski wrote:
> Stephen Hemminger wrote:
>
>>It would be better to account for the tag in the length check.
>>Something like
>> if (skb->protocol == htons(ETH_P_IP) &&
>> skb->len > skb->dev->mtu - (IS_VLAN_IP(skb) ? VLAN_HLEN : 0) &&
>> !skb_is_gso(skb))
>>
Ingo Oeser wrote:
> On Saturday 26 May 2007, Patrick McHardy wrote:
>
>>net/8021q ignores the VLAN header overhead, so we should probably do the
>>same here for consistency. Using IS_VLAN_IP (and IS_PPPOE_IP for current
>>-rc) looks fine, additionally we should probably al
rae l wrote:
> merge dst_discard in & out into one, this removed a duplicate function.
Your patch is whitespace damaged, please fix your mailer and resend
*once*.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Stephen Hemminger wrote:
>>>Index: linux-2.6.22-rc-mm/net/sched/sch_generic.c
>>>===
>>>--- linux-2.6.22-rc-mm.orig/net/sched/sch_generic.c 2007-05-24
>>>11:16:03.0 -0700
>>>+++ linux-2.6.22-rc-mm/net/sched/sch_generic.c
Venki Pallipadi wrote:
> On Wed, May 30, 2007 at 08:42:32PM +0200, Patrick McHardy wrote:
>
>>
>>It seems wasteful to add per-packet overhead for tx timeouts, which
>>should be an exception. Do drivers really care about the exact
>>timeout value? Compared to
Jens Axboe wrote:
>>>On 07/13/2007 09:40 AM, Patrick McHardy wrote:
>>>
>>>>I get this oops with current -git:
>>>>
>>>>[ 3437.018923] Pid: 4432, comm: nfsd Not tainted 2.6.22 #5
>>>>[ 3437.018926] RIP: 0010:[] []
>>>>p
Gabriel C wrote:
> cls_rsvp6 only works with IPV6 enabled kernels and IMO it should depends
> on IPV6.
I can't see any functional dependency on IPv6, what exactly are you
refering to? People might want to use it on a bridge for example
without having IPv6 running locally.
-
To unsubscribe from
Alasdair G Kergon wrote:
> From: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>
> bio_alloc_bioset() will return NULL if 'num_vecs' is too large.
> Use bio_get_nr_vecs() to get estimation of maximum number.
>
> Signed-off-by: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
> Signed-off-by: Alasdair G Kergon <[EMA
Adrian Bunk wrote:
> ipt_iprange.h must #include since it uses __be32.
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ a
Cornelia Huck wrote:
> With NF_CONNTRACK=n, NETFILTER_XT_MATCH_CONNLIMIT=m I get the
> following errors on current git:
>
> CC [M] net/netfilter/xt_connlimit.o
> In file included from net/netfilter/xt_connlimit.c:27:
> include/net/netfilter/nf_conntrack.h:100: error: field 'ct_general' has
Jun'ichi Nomura wrote:
>>>From: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>>>
>>>bio_alloc_bioset() will return NULL if 'num_vecs' is too large.
>>>Use bio_get_nr_vecs() to get estimation of maximum number.
>>>
>>>Signed-off-by: "Jun'ichi Nomura" <[EMAIL PROTECTED]>
>>>Signed-off-by: Alasdair G Kergon
rae l wrote:
> All in one word, I don't think the single file dev_mcast.c is needed
> anymore.
Agreed. But dev.c is growing larger and larger, maybe dev_addr.c?
Or dev_config.c, with some of the other device configuration functions?
-
To unsubscribe from this list: send the line "unsubscribe linu
Jun'ichi Nomura wrote:
> Patrick McHardy wrote:
>
>>Jun'ichi Nomura wrote:
>>
>>>Are you using other dm modules such as dm-multipath, dm-mirror
>>>or dm-snapshot?
>>>If so, can you take the output of 'dmsetup table' and 'dmse
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Wed, 18 Jul 2007 12:01:38 +0200
>
>
>>rae l wrote:
>>
>>>All in one word, I don't think the single file dev_mcast.c is needed
>>>anymore.
>>
>>Agree
This could be done in the patch moving it .. anyways,
Denis Cheng wrote:
> +#ifdef CONFIG_PROC_FS
> +static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos)
If you're interested in doing more work, it would be nice to
generalize the seq-file functions for unicast and multicast
address
andrei radulescu-banu wrote:
> [...]
>
> In conclusion, here is the buglist:
> 1). If set promiscuous, the e1000 should disable any vlan rx filtering, so
> that it can receive vlan frames of other vlan id's. Other ethernet drivers
> probably need fixed as well.
> 2). The packet layer should
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Put another way, once you enable VLAN header stripping, you
>> won't see the headers for *any* VLAN, not only for those you're
>> actually running locally. This is also a problem for devices
>> like macvlan,
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Its actually more a problem on the RX path. VLAN acceleration
>> works (at least with some drivers) by enabling HW header striping
>> and using the VLAN ID for an immediate lookup in the VLAN devices
>> configured on
'true'
net/ipv4/inetpeer.c: In function 'inet_getpeer':
net/ipv4/inetpeer.c:409: warning: the address of 'stack' will always evaluate
as 'true'
net/ipv4/inetpeer.c:409: warning: the address of 'stack' will always evaluate
as 'true'
&quo
Stephen Hemminger wrote:
> On Thu, 19 Jul 2007 15:28:46 +0200
> Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
>
>>>Your suggestion of disabling VLAN acceleration in promiscous
>>>mode sounds like a reasonable solution until then ..
>>
>>From a user perspective:
>>
>>I'm not sure promiscous mode is r
andrei radulescu-banu wrote:
> The consensus seems to be that skb's need to carry vlan accelerated tags in
> their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices qd
k to
the timeout function, which fixes both problems.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 50d2ab6c1353c32b994e6171b231fc771d0a2b73
tree 9b2cd5659dad0b452e59fff4869f7d9db780fd02
parent 6b99a1744ab187073bca84a9fd3ccbf091865ca6
author Patrick McHardy <[EMAIL PROTECTED]
101 - 200 of 275 matches
Mail list logo
