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
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
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
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
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
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
'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
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
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,
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
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
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
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
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:
>>>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
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
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
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
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
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
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
[please send networking patches to netdev]
Philippe De Muyter wrote:
> Hi all,
>
> Make netlink_seq_ops const
Might make more sense to do a big patch for all occurences of this
in net/:
# grep "^static struct seq_operations" -r net/ | wc -l
76
-
To unsubscribe from this list: send the line "un
Andreas Steinmetz wrote:
> Patrick McHardy wrote:
>
>>- assuming you have ethernet internally, the PMTU from your router
>>to the internal hosts is 1500, so it won't do any clamping.
>>
>
>
> Yep, internal PMTU is 1500, still the incoming packets are cla
Andreas Steinmetz wrote:
> Patrick McHardy wrote:
>
>>Andreas Steinmetz wrote:
>>
>>>[...]
>>>The tcpdump on the client shows that the mss of the incoming syn reply
>>>packet is *NOT* clamped to the ppp interface mtu.
>>
>>
>>You forg
Andreas Steinmetz wrote:
> There seems to be a problem with mss to pmtu clamping for incoming syn
> packets on reply to an outgoing connection on a ppp interface. The mss
> of the outgoing syn packets is always always clamped to the pmtu, I did
> check this with a target host I do have access to. T
Vasily Averin wrote:
> Patrick McHardy wrote:
>
>>+ for (i = 0; i < nf_conntrack_htable_size; i++) {
>>+ hlist_for_each_entry(h, n, &nf_conntrack_hash[hash], hnode) {
>>+ tmp = nf_ct_tuplehash_to_ctrack(h);
>>+
Vasily Averin wrote:
> Patrick McHardy wrote:
>
> it is incorrect again: when cnt=0 you should break both cycles.
Indeed, thanks. Fixed now. Also changed it to leave the loop
if we found an entry within a chain (we want the last one of
the chain, so we still walk it entirely) and repla
Vasily Averin wrote:
> Patrick McHardy wrote:
>
>>+ for (i = 0; i < NF_CT_EVICTION_RANGE; i++) {
>>+ hlist_for_each_entry(h, n, &nf_conntrack_hash[hash], hnode) {
>>+ tmp = nf_ct_tuplehash_to_ctrack(h);
>>+
Patrick McHardy wrote:
> Vasily Averin wrote:
>
>>When the number of conntracks is reached nf_conntrack_max limit, early_drop()
>>tries to free one of already used conntracks. If it does not find any
>>conntracks
>>that may be freed, it leads to transmission error
Vasily Averin wrote:
> When the number of conntracks is reached nf_conntrack_max limit, early_drop()
> tries to free one of already used conntracks. If it does not find any
> conntracks
> that may be freed, it leads to transmission errors.
> In current implementation the conntracks are searched in
Vasily Averin wrote:
Patrick McHardy wrote:
I don't like the NF_CT_PER_BUCKET constant. First of all, each
conntrack is hashed twice, so its really only 1/2 of the average
conntracks per bucket. Secondly, its only a default and many
people use nf_conntrack_max = nf_conntrack_htable_size /
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
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
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
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) =
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:
> 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
ing qdisc destruction.
Reported-and-tested-by: Strobl Anton <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit ea1601c50bf23af25094511e2a9ce1b755ab9669
tree a4b8b9f3675606ff935d2422e26b24adf6c1ad3c
parent 1df4e603136d09c0aee78102a05fb960be3764bb
author Pa
atm destroy their filters twice when destroying inner classes
during qdisc destruction.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit a2b6772f1b9524b8d3c67bee3b92956d44555b22
tree a4b8b9f3675606ff935d2422e26b24adf6c1ad3c
parent 1df4e603136d09c0aee78102a05fb960be3764bb
author Patrick Mc
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
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
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
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
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))
>>
_SCHED]: sch_htb: fix event cache time calculation
The event cache time must be an absolute value, when no event exists it is
incorrectly set to 1s instead of 1s in the future.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 49d1023ea0ea8377e740123d5954e88a00f78b7c
tree 031
Linus Torvalds wrote:
> There appear to be other obvious problems in the recent "cleanups" in this
> area..
>
> Look at
>
> psched_tdiff_bounded(psched_time_t tv1, psched_time_t tv2,
> psched_time_t bound)
> {
> return min(tv1 - tv2, bound);
> }
>
> and compare
Herbert Xu wrote:
> On Wed, May 23, 2007 at 12:56:04PM +0200, Patrick McHardy wrote:
>
>>Looking at the recent changes to __qdisc_run, this indeed seems
>>to be the case, when the qdisc is throttled and has packets queued
>>we return a value != 0, causing __qdisc_run to
Ingo Molnar wrote:
> if you feel inclined to try the git-bisection then by all means please
> do it (it will certainly be helpful and educative), but it's optional: i
> dont think you should 'need' to go through extra debugging chores, my
> analysis based on the excellent trace you provided stil
Anant Nitya wrote:
>>Patrick McHardy wrote:
>>
>>I think I already found the bug, please try if this patch helps.
>
>
> Sorry, but this patch is not helping here. I recompiled the kernel with this
> patch but same load pattern still make system to crawl.
>
&g
Patrick McHardy wrote:
> Ingo Molnar wrote:
>
>>* Anant Nitya <[EMAIL PROTECTED]> wrote:
>>
>>>I am posting links to the information you asked for. One more thing,
>>>after digging a bit more I found its QoS shaping that is making the
>>>box cr
Ingo Molnar wrote:
> * Anant Nitya <[EMAIL PROTECTED]> wrote:
>
>
>>I am posting links to the information you asked for. One more thing,
>>after digging a bit more I found its QoS shaping that is making the
>>box crawl. Once I disabled the traffic shaping everything comes back
>>to smooth and
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]
Andrew Morton wrote:
> Whatever happens, that printk should be toned down, shouldn't it? We
> prefer to not let unprivileged apps spam the logs.
Only priviledged apps can send these packets. I've never seen it in
practice except for one case that was a bug in the network stack, so
I'd prefer to
Marcel Holtmann wrote:
> it seems this could be easily exploited and is at least a local DoS. It
> should be a candidate for the -stable kernel.
The bug got introduced in 2.6.21-git, so -stable is not affected.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Robert P. J. Day wrote:
> again, this list contains some CONFIG_ variables that aren't
> technically dead, but *really* should be renamed to not be confused
> with Kconfig variables. there are, however, legitimately dead ones in
> the following in places:
Please post to netdev for networking re
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 10:50:42AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
>
>>>I thought that with releasing a socket, which will have a callback
>>>attached only results in a leak of the callback? In that case we can
>>>
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 10:26:31AM +0200, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
>
>>>Out of curiosity, why not to fix a netlink_dump_start() to remove
>>>callback in error path, since in 'no-error' path it removes it in
>&
Evgeniy Polyakov wrote:
> On Wed, Apr 18, 2007 at 12:16:18PM +0400, Pavel Emelianov ([EMAIL PROTECTED])
> wrote:
>
>>Sorry, I forgot to put netdev and David in Cc when I first sent it.
>>
>>There is a race between netlink_dump_start() and netlink_release()
>>that can lead to the situation when a
Pavel Emelianov wrote:
> Patrick McHardy wrote:
>
>>>There is a race between netlink_dump_start() and netlink_release()
>>>that can lead to the situation when a netlink socket with non-zero
>>>callback is freed.
>>
>>
>>Can you describe
Pavel Emelianov wrote:
> From: Denis Lunev <[EMAIL PROTECTED]>
>
> There is a race between netlink_dump_start() and netlink_release()
> that can lead to the situation when a netlink socket with non-zero
> callback is freed.
Can you describe the race in more detail please?
-
To unsubscribe from
Bartek wrote:
> 2007/4/14, David Miller <[EMAIL PROTECTED]>:
>
>> From: Patrick McHardy <[EMAIL PROTECTED]>
>> Date: Thu, 12 Apr 2007 07:43:39 +0200
>>
>> > It seems we fail to reserve enough headroom for the case
>> > buf[0] == PPP_ALLSTA
David Miller wrote:
> From: "doctor raid" <[EMAIL PROTECTED]>
> Date: Tue, 10 Apr 2007 16:02:01 -0700
>
>
>>[1] kernel errors reporting unaligned access of memory
>>[2] The following two lines iterate twice a piece, about once every 2
>>minutes:
>>
>> Kernel unaligned access at TPC[79c344]
David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Sun, 15 Apr 2007 02:49:28 +1000
>
>
>>I didn't see the patch (the message that this is a reply to is the
>>first one that I have seen in this thread), so I can't comment on it.
>
>
> Here is Patrick McHardy's patch:
>
> [..
Waskiewicz Jr, Peter P wrote:
>>Still leaks the device
>
>
> I explained this in a previous response, and you seemed to be ok with
> the explanation. Can you elaborate if this is still an issue?
I'm OK with allocating subqueues even for single queue devices, not
with leaking memory on error.
Peter P Waskiewicz Jr wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 219a57f..3ce449e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1471,6 +1471,8 @@ gso:
> q = dev->qdisc;
> if (q->enqueue) {
> rc = q->enqueue(skb, q);
>
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protoco
Waskiewicz Jr, Peter P wrote:
>>Packets will only be dequeued from a band if the associated
>>subqueue is active, which moves the decision from prio to the
>>driver, no?
>>What policy does e1000 use for scheduling its internal queues?
>>
>
>
> E1000 is handed the skb's from PRIO to whichever qu
Waskiewicz Jr, Peter P wrote:
>>This leaks the device. You treat every single-queue device as
>>having a single subqueue. If it doesn't get too ugly it would
>>be nice to avoid this and only allocate the subqueue states
>>for real multiqueue devices.
>
>
> We went back and forth on this. The
Peter P Waskiewicz Jr wrote:
> + /* To retrieve statistics per subqueue - FOR FUTURE USE */
> + struct net_device_stats* (*get_subqueue_stats)(struct net_device *dev,
> + int queue_index);
Please no future use stuff, just add it when you
Waskiewicz Jr, Peter P wrote:
> Thanks Pat for the initial feedback. I can post a set of patches to
> e1000 using the new API; I'll try to get them out asap (need to apply to
> this kernel tree).
Thanks.
> However, the PRIO qdisc still uses the priority in
> the bands for dequeueing priority, a
Peter P Waskiewicz Jr wrote:
> From: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
>
> Update: Fixed a typecast in free_netdev() for the egress_subqueue list.
>
> Added an API and associated supporting routines for multiqueue network
> devices.
> This allows network devices supporting multiple TX qu
Vasily Averin wrote:
> No, I've not investigated this scenario. It looks like you are right and my
> patch can leads to a long delays.
>
> In my experiments I've decreased ip_conntrack_max lower than number of hash
> buckets and got the "table full, dropping packet" errors in logs. I've looked
>
leon zadorin wrote:
> 2) for kernels which do have the aforementioned option enabled: how
> does this affect the "tc" (traffic control) utility and the Token
> Bucket Filter (tbf) queueing discipline (traffic-smoothing)
> behhaviour?
>
> For example, the TBF doco suggests that due to the whole fix
Herbert Xu wrote:
> Indeed. That patch was buggy. Sorry for not catching this earlier.
>
> This should fix the problem.
Works fine, thanks Herbert.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> --
> From: J. Bruce Fields <[EMAIL PROTECTED]>
>
> [CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlist
This patch seems to cause some problems, I get reproducabl
.text+0x29de2): référence indéfinie vers «
nf_nat_setup_info »
make: *** [.tmp_vmlinux1] Erreur 1
Reported by Kevin Baradon <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 9b8ea8f4f4091c6e4424b46e8d56bb0366dfd3ee
tree 70c237a3e129df7366ac4a52f6efa142aa0a7d98
pa
Stephen Hemminger wrote:
> On Wed, 14 Mar 2007 13:32:28 +0100
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>>RTA_* attributes aren't used for routing rules anymore inside
>>the kernel.
>
>
> But we need to keep them in iproute2 for back compatibilit
Arkadiusz Miskiewicz wrote:
> Hm, why no RTA_FWMASK in HEAD rtnetlink.h
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/rtnetlink.h;h=4a629ea70cc4ca60a6f486f8653974af68dbe8cd;hb=HEAD
>
> and 2.6.19
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds
Arkadiusz Miskiewicz wrote:
> This patch
>
> http://www.mail-archive.com/netdev@vger.kernel.org/msg27506.html
>
> didn't make into upstream linux kernel it seems.
As mentioned in the changelog, its in 2.6.19.
> The question is - are patches adding some functionality that's not in
> upstream
>
L PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 3ed110cfb9e71fa5f6c44720f20a8e705e9bad0c
tree 607c19476244b034aaf8c0da12f04349cd48bf90
parent 43ff9c5b97da4d085ddf5e37a12a25ed74c14d5a
author Michal Miroslaw <[EMAIL PROTECTED]> Tue, 13 Mar 2007 16:41:58 +0100
co
Jan Engelhardt wrote:
>>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>>>+/* Equivalent to:
>>>+ * -A chaos -m statistic --mode random --probability \
>>>+ * $reject_percentage -j REJECT --reject-with host-unreach;
>>>+ * -A chaos -m statistic --mode random --probability
Jan Engelhardt wrote:
> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> ===
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> @@ -0,0 +1,184 @@
> +
> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
> +
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
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)
() 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,
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
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]>
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
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:
> 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
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
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.
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:
> 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
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'
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
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 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
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
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
101 - 200 of 275 matches
Mail list logo
