On 06.03, Nicholas Krause wrote:
> This adds the proper snprintf and break statement for formatting
> the vlan_net structure pointer, vn's name using snprintf for if
> the switch case, VLAN_NAME_TYPE_PLUS_VID occurs for this particular
> switch statement inside the function, register_vlan_device.
On 06.03, Nicholas Krause wrote:
> This adds the proper snprintf and break statement for formatting
> the vlan_net structure pointer, vn's name using snprintf for if
> the switch case, VLAN_NAME_TYPE_PLUS_VID occurs for this particular
> switch statement inside the function, register_vlan_device.
On 30.01, Lucas Tanure wrote:
> As suggested by checkpatch.pl:
> CHECK: Prefer kernel type 'uX' over 'uintX_t'
You might have noticed we have literally hundreds of them spread over 100
files in the netfilter code. We'll gradually change them when the code is
touched anyways.
>
On 30.01, Lucas Tanure wrote:
> As suggested by checkpatch.pl:
> CHECK: Prefer kernel type 'uX' over 'uintX_t'
You might have noticed we have literally hundreds of them spread over 100
files in the netfilter code. We'll gradually change them when the code is
touched anyways.
>
On 30.06, Li Zhijian wrote:
> |ping...
>
> and i have another question:
> can i add a new |||nf_ct_ext_id simply without touching the exiting kernel
> code?|
No, the kernel needs to know the highest extension ID in order to
allocate space for the offsets.
> in order to support COLO-Proxy, i
On 30.06, Li Zhijian wrote:
|ping...
and i have another question:
can i add a new |||nf_ct_ext_id simply without touching the exiting kernel
code?|
No, the kernel needs to know the highest extension ID in order to
allocate space for the offsets.
in order to support COLO-Proxy, i need a
On 14.04, Honggang Li wrote:
> Signed-off-by: Honggang Li
> ---
> drivers/net/macvlan.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index b227a13..1e59f39 100644
> --- a/drivers/net/macvlan.c
> +++
On 14.04, Honggang LI wrote:
> On Tue, Apr 14, 2015 at 04:26:27PM +0100, Patrick McHardy wrote:
> >
> > That is completely useless. vlan (=netdev_priv) can not be NULL as
> > netdev_priv() never returns NULL and vlan->lowerdev is always valid
> > because a ma
On 14.04, Honggang LI wrote:
On Tue, Apr 14, 2015 at 04:26:27PM +0100, Patrick McHardy wrote:
That is completely useless. vlan (=netdev_priv) can not be NULL as
netdev_priv() never returns NULL and vlan-lowerdev is always valid
because a macvlan wouldn't make much sense otherwise.
OK
On 14.04, Honggang Li wrote:
Signed-off-by: Honggang Li ho...@redhat.com
---
drivers/net/macvlan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index b227a13..1e59f39 100644
--- a/drivers/net/macvlan.c
+++
On 02.03, Joe Stringer wrote:
> From: Andy Zhou
>
> Currently, ip_defrag() does not keep track of the maximum fragmentation
> size for each fragmented packet. This information is not necessary since
> current Linux IP fragmentation always fragments a packet based on output
> devices' MTU.
It
On 02.03, Joe Stringer wrote:
From: Andy Zhou az...@nicira.com
Currently, ip_defrag() does not keep track of the maximum fragmentation
size for each fragmented packet. This information is not necessary since
current Linux IP fragmentation always fragments a packet based on output
devices'
On 02.01, Thomas Graf wrote:
> Hash the key inside of rhashtable_lookup_compare() like
> rhashtable_lookup() does. This allows to simplify the hashing
> functions and keep them private.
One more question:
> diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c
> index 1e316ce..614ee09
On 02.01, Thomas Graf wrote:
Hash the key inside of rhashtable_lookup_compare() like
rhashtable_lookup() does. This allows to simplify the hashing
functions and keep them private.
One more question:
diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c
index 1e316ce..614ee09
On 12.01, Patrick Schaaf wrote:
> On Monday 12 January 2015 08:51:54 Eric Dumazet wrote:
> > On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote:
> > >
> > > Not to comment on the ifalias thing, which I think is unneccessary,
> > > too, but matching on interface names instead of only ifindex,
On 12.01, Patrick Schaaf wrote:
On Monday 12 January 2015 08:51:54 Eric Dumazet wrote:
On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote:
Not to comment on the ifalias thing, which I think is unneccessary,
too, but matching on interface names instead of only ifindex, is
On 1. August 2014 15:51:45 GMT+01:00, Thomas Graf wrote:
>On 08/01/14 at 03:12pm, Patrick McHardy wrote:
>> On 1. August 2014 14:49:01 GMT+01:00, Thomas Graf
>wrote:
>> >On 08/01/14 at 02:21pm, Nikolay Aleksandrov wrote:
>> >> Sorry for the late response but I
On 1. August 2014 14:49:01 GMT+01:00, Thomas Graf wrote:
>On 08/01/14 at 02:21pm, Nikolay Aleksandrov wrote:
>> Sorry for the late response but I just got around to check the 3rd
>patch now,
>> so my question about this fragment is: before nft_hash_remove() would
>free the
>> element after
On 1. August 2014 11:39:01 GMT+01:00, Thomas Graf wrote:
>On 08/01/14 at 11:17am, Patrick McHardy wrote:
>> On 1. August 2014 09:52:00 GMT+01:00, Thomas Graf
>wrote:
>> >If the set size is known in advance, the table is sized accordingly,
>> >otherwise the
n iterations.
That's assuming a sufficient number of entries will be added. I think there
will be many cases in nftables where the number will be lower. Since
expansion is not very expansive this number was chosen very deliberately
and I'd prefer to keep it.
Other than that:
Acked-by: Pat
er by Josh Triplett, Paul E. McKenney
> + * and Jonathan Walpole:
> + * https://www.usenix.org/legacy/event/atc11/tech/final_files/Triplett.pdf
> + *
> + * Code partially derived from nft_hash:
> + * Copyright (c) 2008-2014 Patrick McHardy
Minor request: german copyright law as an a
E. McKenney
+ * and Jonathan Walpole:
+ * https://www.usenix.org/legacy/event/atc11/tech/final_files/Triplett.pdf
+ *
+ * Code partially derived from nft_hash:
+ * Copyright (c) 2008-2014 Patrick McHardy ka...@trash.net
Minor request: german copyright law as an assumption of authorship
iterations.
That's assuming a sufficient number of entries will be added. I think there
will be many cases in nftables where the number will be lower. Since
expansion is not very expansive this number was chosen very deliberately
and I'd prefer to keep it.
Other than that:
Acked-by: Patrick McHardy
On 1. August 2014 11:39:01 GMT+01:00, Thomas Graf tg...@suug.ch wrote:
On 08/01/14 at 11:17am, Patrick McHardy wrote:
On 1. August 2014 09:52:00 GMT+01:00, Thomas Graf tg...@suug.ch
wrote:
If the set size is known in advance, the table is sized accordingly,
otherwise the table size will default
On 1. August 2014 14:49:01 GMT+01:00, Thomas Graf tg...@suug.ch wrote:
On 08/01/14 at 02:21pm, Nikolay Aleksandrov wrote:
Sorry for the late response but I just got around to check the 3rd
patch now,
so my question about this fragment is: before nft_hash_remove() would
free the
element after
On 1. August 2014 15:51:45 GMT+01:00, Thomas Graf tg...@suug.ch wrote:
On 08/01/14 at 03:12pm, Patrick McHardy wrote:
On 1. August 2014 14:49:01 GMT+01:00, Thomas Graf tg...@suug.ch
wrote:
On 08/01/14 at 02:21pm, Nikolay Aleksandrov wrote:
Sorry for the late response but I just got around
On Tue, Apr 01, 2014 at 12:43:36AM +0900, Masanari Iida wrote:
> Fix format string mismatch in mangle_connect_len()
All these patches seem like pointless noise to me. In none of these
cases can the value legitimately be negative. If anything, you should
fix the types to be unsigned.
>
>
On Tue, Apr 01, 2014 at 12:43:36AM +0900, Masanari Iida wrote:
Fix format string mismatch in mangle_connect_len()
All these patches seem like pointless noise to me. In none of these
cases can the value legitimately be negative. If anything, you should
fix the types to be unsigned.
On Thu, Mar 27, 2014 at 04:50:33PM +0100, Florian Westphal wrote:
> Andrey Vagin wrote:
> > "len" contains sizeof(nf_ct_ext) and size of extensions. In a worst
> > case it can contain all extensions. Bellow you can find sizes for all
> > types of extensions. Their sum is definitely bigger than
t; I have seen "len" up to 280 and my host has crashes w/o this patch.
Very nice catch. I suppose we also need to either increase the size of
offset[] or rearrange the extension so 4 (ECACHE) comes last.
>
> Cc: Pablo Neira Ayuso
> Cc: Patrick McHardy
> Cc: Jozsef
also need to either increase the size of
offset[] or rearrange the extension so 4 (ECACHE) comes last.
Cc: Pablo Neira Ayuso pa...@netfilter.org
Cc: Patrick McHardy ka...@trash.net
Cc: Jozsef Kadlecsik kad...@blackhole.kfki.hu
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Andrey Vagin
On Thu, Mar 27, 2014 at 04:50:33PM +0100, Florian Westphal wrote:
Andrey Vagin ava...@openvz.org wrote:
len contains sizeof(nf_ct_ext) and size of extensions. In a worst
case it can contain all extensions. Bellow you can find sizes for all
types of extensions. Their sum is definitely bigger
On Tue, Mar 25, 2014 at 08:50:56AM -0400, Richard Guy Briggs wrote:
> + if (nlk->netlink_bind && nladdr->nl_groups) {
> + int i;
> +
> + for (i = 0; i < nlk->ngroups; i++)
> + if (test_bit(i, (long unsigned int
> *)>nl_groups)) {
> +
On Tue, Mar 25, 2014 at 08:50:56AM -0400, Richard Guy Briggs wrote:
+ if (nlk-netlink_bind nladdr-nl_groups) {
+ int i;
+
+ for (i = 0; i nlk-ngroups; i++)
+ if (test_bit(i, (long unsigned int
*)nladdr-nl_groups)) {
+
On Thu, Feb 13, 2014 at 10:32:45AM -0800, Cong Wang wrote:
> On Thu, Feb 13, 2014 at 2:30 AM, Jozsef Kadlecsik
> wrote:
> > On Thu, 13 Feb 2014, Ilia Mirkin wrote:
> >> messages in my dmesg. This might be because of some local
> >> configuration changes I've made, or perhaps a kernel upgrade.
On Thu, Feb 13, 2014 at 10:32:45AM -0800, Cong Wang wrote:
On Thu, Feb 13, 2014 at 2:30 AM, Jozsef Kadlecsik
kad...@blackhole.kfki.hu wrote:
On Thu, 13 Feb 2014, Ilia Mirkin wrote:
messages in my dmesg. This might be because of some local
configuration changes I've made, or perhaps a
Commit b1a1442a2 (HID: core: fix reporting of raw events) introduced a
regression that causes lockups for bluetooth trackpads.
This was already discussed in this thread in September:
http://www.kernelhub.org/?p=2=329823
but it seems nothing has been fixed so far, I still get the lockups
in
Commit b1a1442a2 (HID: core: fix reporting of raw events) introduced a
regression that causes lockups for bluetooth trackpads.
This was already discussed in this thread in September:
http://www.kernelhub.org/?p=2msg=329823
but it seems nothing has been fixed so far, I still get the lockups
in
On Thu, May 02, 2013 at 04:16:25AM -0400, David Miller wrote:
> From: Patrick McHardy
> Date: Thu, 2 May 2013 09:03:37 +0200
>
> > I'll also have a look at this.
>
> By the mere existence of /sys/devices/${DEV_PATH}/net/${netdev_name}/flags
> we have to preserve the b
On Thu, May 02, 2013 at 02:45:52AM -0400, David Miller wrote:
> From: Linus Torvalds
> Date: Wed, 1 May 2013 21:55:38 -0700
>
> > I think the positions of those bits matter, and adding
> > NETIF_F_HW_VLAN_STAG_*_BIT randomly in the middle broke things. That's
> > backed up by the fact that we
On Thu, May 02, 2013 at 02:45:52AM -0400, David Miller wrote:
From: Linus Torvalds torva...@linux-foundation.org
Date: Wed, 1 May 2013 21:55:38 -0700
I think the positions of those bits matter, and adding
NETIF_F_HW_VLAN_STAG_*_BIT randomly in the middle broke things. That's
backed up by
On Thu, May 02, 2013 at 04:16:25AM -0400, David Miller wrote:
From: Patrick McHardy ka...@trash.net
Date: Thu, 2 May 2013 09:03:37 +0200
I'll also have a look at this.
By the mere existence of /sys/devices/${DEV_PATH}/net/${netdev_name}/flags
we have to preserve the bit layout.
So
On Thu, Feb 07, 2013 at 12:58:01PM +0100, Stefan Priebe - Profihost AG wrote:
> Hi Patrick,
>
> thanks for your fast response.
>
> > So please describe the entire GVRP message exchange that's going
> > on.
> I've attached two small pcap files.
>
> has_bridge.pcap: is where eth1 has a bridge and
On Thu, Feb 07, 2013 at 11:56:38AM +0100, Stefan Priebe - Profihost AG wrote:
> Hello list,
>
> this was tested using vanilla 3.7.6 kernel.
>
> When i add a vlan to an ethernet device supporting gvrp everything is
> fine until this ethernet device also had a bridge.
>
> This works fine as long
On Thu, Feb 07, 2013 at 11:56:38AM +0100, Stefan Priebe - Profihost AG wrote:
Hello list,
this was tested using vanilla 3.7.6 kernel.
When i add a vlan to an ethernet device supporting gvrp everything is
fine until this ethernet device also had a bridge.
This works fine as long as eth1
On Thu, Feb 07, 2013 at 12:58:01PM +0100, Stefan Priebe - Profihost AG wrote:
Hi Patrick,
thanks for your fast response.
So please describe the entire GVRP message exchange that's going
on.
I've attached two small pcap files.
has_bridge.pcap: is where eth1 has a bridge and the
Martin Michlmayr wrote:
With 2.6.25-rc3 and a config file with
CONFIG_CRYPTO_DEV_HIFN_795X=m
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
I get the following build error on at least ARM and MIPS:
Building modules, stage 2.
MODPOST 759 modules
ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko]
Martin Michlmayr wrote:
With 2.6.25-rc3 and a config file with
CONFIG_CRYPTO_DEV_HIFN_795X=m
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
I get the following build error on at least ARM and MIPS:
Building modules, stage 2.
MODPOST 759 modules
ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined!
Jan Engelhardt wrote:
I have released “Xtables” 1.5.1, which is a package of my ongoing
iptables development¹ that I did lately. Patrick McHardy was not
available last week to merge patches due to higher powers, so I
branched off the iptables subversion trunk into git since quilting on
top
Stephen Hemminger wrote:
On Thu, 21 Feb 2008 12:28:50 +0100
Patrick McHardy <[EMAIL PROTECTED]> wrote:
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 327e847..b77eb56 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/net
736b33102292be0d75be1e950ca9bcd5361db7dd
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu Feb 21 12:26:01 2008 +0100
[NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code
warning
Since we're using RCU for the conntrack hash now, we need to avoid
g
?
commit 736b33102292be0d75be1e950ca9bcd5361db7dd
Author: Patrick McHardy [EMAIL PROTECTED]
Date: Thu Feb 21 12:26:01 2008 +0100
[NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code
warning
Since we're using RCU for the conntrack hash now, we need to avoid
Stephen Hemminger wrote:
On Thu, 21 Feb 2008 12:28:50 +0100
Patrick McHardy [EMAIL PROTECTED] wrote:
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 327e847..b77eb56 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter
Jan Engelhardt wrote:
I have released “Xtables” 1.5.1, which is a package of my ongoing
iptables development¹ that I did lately. Patrick McHardy was not
available last week to merge patches due to higher powers, so I
branched off the iptables subversion trunk into git since quilting on
top
Tilman Schmidt wrote:
Still, X came up fine, I could log in (Gnome feeling subjectively
a bit sluggish), call up a web page from the Internet in Firefox,
and start perusing the logs, when the whole system froze: neither
mouse nor keyboard would react anymore, and only the Wind^Wreset
button
Jan Engelhardt wrote:
On Feb 20 2008 15:47, Ilpo Järvinen wrote:
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
-static inline struct sk_buff *dev_alloc_skb(unsigned int length)
-{
- return __dev_alloc_skb(length, GFP_ATOMIC);
-}
+extern struct sk_buff
Ilpo Järvinen wrote:
~500 files changed
...
kernel/uninlined.c:
skb_put | +104
1 function changed, 104 bytes added, diff: +104
vmlinux.o:
869 functions changed, 198 bytes added, 111003 bytes removed, diff: -110805
This change is INCOMPLETE, I think that the call to
Ilpo Järvinen wrote:
~500 files changed
...
kernel/uninlined.c:
skb_put | +104
1 function changed, 104 bytes added, diff: +104
vmlinux.o:
869 functions changed, 198 bytes added, 111003 bytes removed, diff: -110805
This change is INCOMPLETE, I think that the call to
Jan Engelhardt wrote:
On Feb 20 2008 15:47, Ilpo Järvinen wrote:
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
-static inline struct sk_buff *dev_alloc_skb(unsigned int length)
-{
- return __dev_alloc_skb(length, GFP_ATOMIC);
-}
+extern struct sk_buff
Tilman Schmidt wrote:
Still, X came up fine, I could log in (Gnome feeling subjectively
a bit sluggish), call up a web page from the Internet in Firefox,
and start perusing the logs, when the whole system froze: neither
mouse nor keyboard would react anymore, and only the Wind^Wreset
button
Adrian Bunk wrote:
This patch removes the no longer used include/linux/netfilter_ipv4/ipt_SAME.h
We kept it around because old iptables binaries need it to build.
The kernel no longer supports it, but people might still wish to
use a distributor-built iptables binary with old kernels. It will
Adrian Bunk wrote:
This patch removes the no longer used include/linux/netfilter_ipv4/ipt_SAME.h
We kept it around because old iptables binaries need it to build.
The kernel no longer supports it, but people might still wish to
use a distributor-built iptables binary with old kernels. It will
David Miller wrote:
From: Jozsef Kadlecsik <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
Please note the lastest git commit is missing one part (which was in Jozsef's
original patch).
Sorry everyone, that's my fault: the patch I
David Miller wrote:
From: Jozsef Kadlecsik [EMAIL PROTECTED]
Date: Thu, 14 Feb 2008 16:02:29 +0100 (CET)
Hi,
On Sun, 10 Feb 2008, Jeff Chua wrote:
Please note the lastest git commit is missing one part (which was in Jozsef's
original patch).
Sorry everyone, that's my fault: the patch I sent
David Miller wrote:
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET)
I have been unable to reach the netfilter and net maintainers the past
week regarding inclusion of patches, but most importantly a group of
fixes at [0]-[3]. I am kind of at a loss here
David Miller wrote:
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET)
I have been unable to reach the netfilter and net maintainers the past
week regarding inclusion of patches, but most importantly a group of
fixes at [0]-[3]. I am kind of at a loss here but
Jozsef Kadlecsik wrote:
On Tue, 5 Feb 2008, Jeff Chua wrote:
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator of
the active close should not be taken into account. So could you give a try
to the patch
Jozsef Kadlecsik wrote:
On Tue, 5 Feb 2008, Jeff Chua wrote:
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik [EMAIL PROTECTED] wrote:
Actively closed connections are not handled properly, i.e. the initiator of
the active close should not be taken into account. So could you give a try
to the patch
Jiri Moravec wrote:
Function iprange_mt4 belong to IPv4 family - AF_INET. Right?
.name = "iprange",
.revision = 1,
.family= AF_INET6, <-- Typo?
.match = iprange_mt4,
Fixed, thanks Jiri.
--
To unsubscribe from this list: send the line
Jiri Moravec wrote:
Function iprange_mt4 belong to IPv4 family - AF_INET. Right?
.name = iprange,
.revision = 1,
.family= AF_INET6, -- Typo?
.match = iprange_mt4,
Fixed, thanks Jiri.
--
To unsubscribe from this list: send the line
, thanks Ingo. Attached patch should fix it.
commit 28383868d7999539f35ae0c2dfbde103a1d3
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri Feb 1 16:50:44 2008 +0100
[NET_SCHED]: cls_flow: fix build error with CONFIG_NET_EMATCH=n
Reported by Ingo Molnar:
net
, thanks Ingo. Attached patch should fix it.
commit 28383868d7999539f35ae0c2dfbde103a1d3
Author: Patrick McHardy [EMAIL PROTECTED]
Date: Fri Feb 1 16:50:44 2008 +0100
[NET_SCHED]: cls_flow: fix build error with CONFIG_NET_EMATCH=n
Reported by Ingo Molnar:
net/sched
David Newall wrote:
I'm not debating that checksums are wrong. The question was how and
where? It's not as if there are any unreliable communication paths in a
loopback interface, so it's surprising that they could be wrong. How? Where?
As I said, loopback doesn't perform full checksum
Jozsef Kadlecsik wrote:
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
On the bad run, I got the following message ...
boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843
Jozsef Kadlecsik wrote:
Hi Jeff,
On Thu, 31 Jan 2008, Jeff Chua wrote:
On the bad run, I got the following message ...
boston kernel: nf_ct_tcp: invalid packed ignored IN= OUT=
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=8162
DF PROTO=TCP SPT=1016 DPT=515 SEQ=3834958843
David Newall wrote:
I'm not debating that checksums are wrong. The question was how and
where? It's not as if there are any unreliable communication paths in a
loopback interface, so it's surprising that they could be wrong. How? Where?
As I said, loopback doesn't perform full checksum
Jeff Chua wrote:
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Thanks. In the dump we can see that connections reusing ports
always have their first SYN dropped and retransmissted three
seconds later. I'm not sure whats causing this yet, do you have
any firewall
Jeff Chua wrote:
On Jan 31, 2008 10:23 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
Again, using latest linux, one with
17311393f969090ab060540bd9dbe7dc885a76d5 reverted, and the other
without.
Sorry, here's the attached output files.
Thanks. In the dump we can see that connections
Adrian Bunk wrote:
This patch makes the needlessly global nf_ct_path[] static.
I already have this queued.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Annotate rcu_read_lock/rcu_read_unlock for sparse.
[RCU]: preemptible RCU: sparse annotations
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/include/linux/rcupreempt.h b/include/linux/rcupreempt.h
index ece8eb3..60c2a03 100644
--- a/include/linux/rcupreempt.h
+++ b/i
Ingo Molnar wrote:
randconfig testing found the following build failure on latest -git:
net/built-in.o: In function `ip_queue_init':
ip_queue.c:(.init.text+0x322c): undefined reference to `net_ipv4_ctl_path'
config attached.
Thanks, the reason is CONFIG_SYSCTL=n. I've queued this patch
Jeff Chua wrote:
On Jan 29, 2008 6:53 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
As the problem can be reproduced so easily, could you capture a full TCP
session and send the pcap file? Thus it could be analyzed, replayed, etc.
and found the reason why the patch above slows down the
Jeff Chua wrote:
On Jan 29, 2008 6:53 PM, Jozsef Kadlecsik [EMAIL PROTECTED] wrote:
As the problem can be reproduced so easily, could you capture a full TCP
session and send the pcap file? Thus it could be analyzed, replayed, etc.
and found the reason why the patch above slows down the
Ingo Molnar wrote:
randconfig testing found the following build failure on latest -git:
net/built-in.o: In function `ip_queue_init':
ip_queue.c:(.init.text+0x322c): undefined reference to `net_ipv4_ctl_path'
config attached.
Thanks, the reason is CONFIG_SYSCTL=n. I've queued this patch
Adrian Bunk wrote:
This patch makes the needlessly global nf_ct_path[] static.
I already have this queued.
--
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
Jeff Chua wrote:
On Jan 31, 2008 10:23 AM, Jeff Chua [EMAIL PROTECTED] wrote:
Again, using latest linux, one with
17311393f969090ab060540bd9dbe7dc885a76d5 reverted, and the other
without.
Sorry, here's the attached output files.
Thanks. In the dump we can see that connections
Jeff Chua wrote:
On Jan 31, 2008 10:41 AM, Patrick McHardy [EMAIL PROTECTED] wrote:
Thanks. In the dump we can see that connections reusing ports
always have their first SYN dropped and retransmissted three
seconds later. I'm not sure whats causing this yet, do you have
any firewall rules
won't work
Submitter : Kristoffer Malmström <[EMAIL PROTECTED]>
Date: 2007-12-28
References : http://bugzilla.kernel.org/show_bug.cgi?id=9657
Handled-By : Patrick McHardy <[EMAIL PROTECTED]>
The reporter has disappeared, so I guess this wasn't a regre
won't work
Submitter : Kristoffer Malmström [EMAIL PROTECTED]
Date: 2007-12-28
References : http://bugzilla.kernel.org/show_bug.cgi?id=9657
Handled-By : Patrick McHardy [EMAIL PROTECTED]
The reporter has disappeared, so I guess this wasn't a regression
caused
Herbert Xu wrote:
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hook only gets called from within the IP stack), I think REJECT would
also do the wrong thing if the packet had IP options. So perhaps we
Herbert Xu wrote:
Patrick, please have a look at the former. In fact it's not just
that ihl may be bogus (which might be harmless as long as the REJECT
hook only gets called from within the IP stack), I think REJECT would
also do the wrong thing if the packet had IP options. So perhaps we
Denys Vlasenko wrote:
On Monday 31 December 2007 17:00, Patrick McHardy wrote:
Denys Vlasenko wrote:
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Some people also consider the ruleset
Denys Vlasenko wrote:
On Monday 31 December 2007 17:00, Patrick McHardy wrote:
Denys Vlasenko wrote:
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Some people also consider the ruleset
Denys Vlasenko wrote:
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Some people also consider the ruleset replacement path performance
critical, but overall I agree with your patch. I'm
Denys Vlasenko wrote:
ip[6]_tables.c seem to abuse inline.
This patch removes inlines except those which are used
by packet matching code and thus are performance-critical.
Some people also consider the ruleset replacement path performance
critical, but overall I agree with your patch. I'm
Denys Vlasenko wrote:
On Monday 17 December 2007 14:47, Patrick McHardy wrote:
This clashes with my pending patches, which I'll push upstream
today. I also spent some time resyncing ip_tables and ip6_tables
so a diff of both (with some sed'ing) shows only the actual
differences, so please
Denys Vlasenko wrote:
On Monday 17 December 2007 14:47, Patrick McHardy wrote:
This clashes with my pending patches, which I'll push upstream
today. I also spent some time resyncing ip_tables and ip6_tables
so a diff of both (with some sed'ing) shows only the actual
differences, so please
Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2007-12-18 00:51
Chris Friesen wrote:
Patrick McHardy wrote:
From a kernel perspective there are only complete dumps, the
filtering is done by iproute. So the fact that it shows them
when querying specifically implies there is
Chris Friesen wrote:
Patrick McHardy wrote:
From a kernel perspective there are only complete dumps, the
filtering is done by iproute. So the fact that it shows them
when querying specifically implies there is a bug in the
iproute neighbour filter. Does it work if you omit "all"
f
Joe Perches wrote:
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
net/netfilter/nf_conntrack_sip.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Both your netfilter patches conflict with some pending patches
of mine (which also fix those spelling errors). So for now I'm
1 - 100 of 545 matches
Mail list logo
