Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
extention headers twice a packet.
It will probably
Hello.
In article [EMAIL PROTECTED] (at Mon, 21 Nov 2005 17:31:41 +0900), Kazunori
Miyazawa [EMAIL PROTECTED] says:
Your ip_xfrm_transport_hook is a good idea, I think.
We could call ip6_rcv_finish if the netfilter changed the addresses
or otherwise we can continue the loop to avoid the
Hi,
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 21 Nov 2005 07:52:36 +0100
I don't see why it is confusing. Plain text packets are visible before
encapsulation (and they have to be because we don't necessarily know
if packets will be encapsulated at the time the hooks are called in
Herbert Xu wrote:
On Sun, Nov 20, 2005 at 04:35:46PM +0100, Richard Knutsson wrote:
-#ifdef CONFIG_EISA
- cardcount = eisa_driver_register(dgrs_eisa_driver);
+ cardcount = dgrs_register_eisa();
if (cardcount 0)
return cardcount;
-#endif
- cardcount
Trent Jaeger wrote:
On Nov 17, 2005, at 8:42 PM, Chris Wright wrote:
Little heavy on KERN_DEBUG printk's. Could you drop them (or perhaps
use pr_debug instead)?
You are right. Are there guidelines for when to use KERN_DEBUGs that
I should be aware of?
Never. Just use pr_debug().
...
But there's a change in 2.6.15-rc1 that makes this issue much worse:
It is no longer user-visible.
tristate's select'ing bool's that do not change parts of the (modular)
driver but compile additional code into the kernel are simply wrong.
The patch below (should apply against
Hi All,
I am posting a UNM NIC driver patch for a review. It's a large patch
file, so we have uploaded it to
http://www.linsyssoft.com/unm/unm_nic-2.6.15-rc2.patch, instead of
sending it inline. (http://www.linsyssoft.com/unm.html for more info)
Any comments would be highly appreciated.
Thanks.
On Mon, Nov 21, 2005 at 08:08:32AM -0800, Amit S. Kale wrote:
Hi All,
I am posting a UNM NIC driver patch for a review. It's a large patch
file, so we have uploaded it to
http://www.linsyssoft.com/unm/unm_nic-2.6.15-rc2.patch, instead of
sending it inline.
Kazunori Miyazawa wrote:
Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
extention headers
Yasuyuki KOZAKAI wrote:
I don't see why it is confusing. Plain text packets are visible before
encapsulation (and they have to be because we don't necessarily know
if packets will be encapsulated at the time the hooks are called in
case the policy lookup after NAT returns a policy), plain text
Adrian Bunk wrote:
2.6.15-rc changes NET_CLS to being automatically select'ed when needed.
This patch confuses users since NET_CLS is a bool, and compiling an
additional module that select's NET_CLS causes unresolved symbols since
it's not user-visible that adding a module changes the kernel
David S. Miller wrote:
I've read over Patrick's two most recent postings of these patches
and I think they are generally sane and I cannot find any holes in
them. Herbert brought up the legitimate concern about defragmentation,
but I think that's a detail and does not take away from the
On Sun, Nov 20, 2005 at 09:14:04PM -0800, David S. Miller wrote:
This DEFINE_RWLOCK() quoted on the last line of the second hunk here
is a straight static rwlock_t ... in my tree.
sorry, I'll resolve this and resubmit.
--
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/
On 11/18/05, Martin Josefsson [EMAIL PROTECTED] wrote:
Currently the e1000 driver only supplies the active link speed / duplex
when a link-beat is present to ethtool. This patch adds support for
supplying the configured speed / duplex when auto-negotiation is
disabled and no link-beat is
On Mon, Nov 21, 2005 at 12:29:04AM +0100, Adrian Bunk wrote:
EXPORT_SYMBOL's do nowadays belong to the files where the actual
functions are.
Moving the module_init/module_exit to the file with the actual functions
has the advantage of saving a few bytes due to the removal of two
When using netlink, should nlmsg_pid be set to pid (current-tgid) or
tid (current-pid)?
Chris
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Friesen, Christopher [CAR:VC21:EXCH] wrote:
When using netlink, should nlmsg_pid be set to pid (current-tgid) or
tid (current-pid)?
The reason I ask is that with 2.6.10 we had to set it to tid, which
really doesn't make much sense given than sockets are shared across all
threads in a
On Mon, Nov 21, 2005 at 01:52:49PM +0100, Richard Knutsson wrote:
What do you think about this patch? Will you sign it? It is no longer an
error-warning-fix but a bug-fix (and some cleanup).
I took you implementation of dgrs_(un)register_eisa(), especially
since eisa needed to be
Christopher Friesen [EMAIL PROTECTED] wrote:
When using netlink, should nlmsg_pid be set to pid (current-tgid) or
tid (current-pid)?
I tend to agree with you here that tgid makes more sense. Dave, what
do you think?
However, you should never assume whatever value the kernel uses since
it
Hello!
I tend to agree with you here that tgid makes more sense.
I agree, apparently netlink_autobind was missed when sed'ing pid-tgid.
Of course, it does not matter, but tgid is nicer choice from user's viewpoint.
Alexey
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
Herbert Xu wrote:
On Mon, Nov 21, 2005 at 01:52:49PM +0100, Richard Knutsson wrote:
This patch requirer the
net-fix-compiler-error-on-dgrsc-when-config_pci.patch (added to the
-mm tree after 2.6.15-rc1-mm2):
---
devel/drivers/net/dgrs.c~net-fix-compiler-error-on-dgrsc-when-config_pci
Alexey Kuznetsov wrote:
Hello!
I tend to agree with you here that tgid makes more sense.
I agree, apparently netlink_autobind was missed when sed'ing pid-tgid.
Of course, it does not matter, but tgid is nicer choice from user's viewpoint.
I'm glad you agree, but I'm not sure what you
When the bridge topology allows a single skb to traverse more than one
bridge we end up leaking skb-nf_bridge each time the skb enters the
second or higher bridge. The leak occurs when bridge netfilter is
enabled on 2.4 (with bridge netfilter patch) and 2.6 git head,
proposed 2.4 fix below.
On Mon, 21 Nov 2005 22:42:29 +0100
Aritz Bastida [EMAIL PROTECTED] wrote:
I have just subscribed to netdev. I used to write in the linux-net
mailing list, but there is little activity in there.
What I need is to turn off and on the polling done to a network device
which works with
Richard Knutsson [EMAIL PROTECTED] wrote:
We need it even if pci_register_driver() and pci_register_driver() is
empty shells. And instead of removing #endif CONFIG_PCI for
I don't think so. Please see my previous patch where pci_register_driver
is not called at all if CONFIG_PCI is not
Alexey Kuznetsov [EMAIL PROTECTED] wrote:
I agree, apparently netlink_autobind was missed when sed'ing pid-tgid.
Of course, it does not matter, but tgid is nicer choice from user's viewpoint.
Great, here is the patch to do just that.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Thanks,
--
On 11/21/05, Martin Josefsson [EMAIL PROTECTED] wrote:
snip
Why do you need this? Basically this was a design decision in our
driver to not report link when we haven't had a chance to initialize
it (when the interface is brought up)
If I configure an interface to disable autonegotiation
Well, the answer to that is quite long, and it's precisely the purpose
of my research. But, in short, what i need is to capture network
packets as fast as possible, and turn off the incoming packet feeding
when too many packets arrive. Don't now yet if you think the solution
I proposed in my
On Mon, 21 Nov 2005 23:53:27 +0100
Aritz Bastida [EMAIL PROTECTED] wrote:
Well, the answer to that is quite long, and it's precisely the purpose
of my research. But, in short, what i need is to capture network
packets as fast as possible, and turn off the incoming packet feeding
when too many
On Mon, 21 Nov 2005 22:58:10 +0100
Aritz Bastida [EMAIL PROTECTED] wrote:
Hello everybody
I need to turn off and on the polling done to a network device
which works with NAPI. I'll explain: whenever it arrives a
packet-receive interrupt the network driver issues
netif_rx_schedule(), to
Herbert Xu wrote:
As I said before, you should not rely on getpid() to work.
You should always use getsockaddr(2) to get your local address.
Should that be getsockname(2)? Anyways, I now understand the issues.
As it turns out, we were actually already calling getsockname() a bit
earlier
On Tue, Nov 22, 2005 at 12:20:30AM +0100, Richard Knutsson wrote:
Am thinking of removing the #ifdef CONFIG_PCI's in other files, to
clean up the code, but that would introduce this problem again, don't
you think it is more readable to make an empty struct when !CONFIG_PCI,
then making
Patrick McHardy wrote:
Kazunori Miyazawa wrote:
Hello Patrick,
I have a comment about the patch on the IPv6 input process.
The kernel applied your patch will always call ip6_rcv_finish
when enabling netfilter and receiving a esp packet so that
it will always look up the routing table and parse
Kazunori Miyazawa wrote:
Patrick McHardy wrote:
The problem is that netfilter hooks take ownership of the skb, so the
caller can't touch it afterwards. It would be possible, but it would
become very ugly. Can I assume that you would also be satisfied if
the double-parsing of extension headers
Patrick McHardy wrote:
jamal wrote:
Dave,
This is a bug fix. So not sure if it is fitting for 2.6.15 or not.
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..495bf22 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -283,18 +289,32 @@ static void
On Tue, 2005-22-11 at 03:18 +0100, Patrick McHardy wrote:
it still has a different race, IN_DEV_PROMOTE_SECONDARIES can change
between the first and the second check, just checking for
promote != NULL is enough and prevents that race.
Are you suggesting not to check for
jamal wrote:
On Tue, 2005-22-11 at 03:18 +0100, Patrick McHardy wrote:
it still has a different race, IN_DEV_PROMOTE_SECONDARIES can change
between the first and the second check, just checking for
promote != NULL is enough and prevents that race.
Are you suggesting not to check for
Stephen Hemminger [EMAIL PROTECTED] wrote:
Patrick McHardy
* Fix ip command shortcuts
Is there a good reason to remove ip address command alias for ip
addr? IMHO this is nonsense and will break scripts. Again IMHO this
should be explicit listed in the changelog in the place of that poor
jamal wrote:
On Tue, 2005-22-11 at 03:56 +0100, Patrick McHardy wrote:
Yes. promote can only be non-NULL if it was set at the time the first
check was performed. If you check twice and it is changed in between
the secondaries will get neither removed nor promoted. In fact,
the first check
On Tue, 2005-22-11 at 04:14 +0100, Patrick McHardy wrote:
jamal wrote:
Of course, the underlying assumption is that in fact it could happen.
Could it actually happen? Because if that was the case, a lot of code in
the net area would need to be audited and fixed.
I don't see anything
jamal [EMAIL PROTECTED] wrote:
I would agree. This is a bad idea which has actually already bitten me.
Here it took me some time to figure it out why, after iproute2 upgrade
and a reboot, my ethernet adapters didn't get their addresses as usual.
Only after a diff between my old iproute2 package
Patrick McHardy [EMAIL PROTECTED] wrote:
It was broken in a CVS version, not sure if it ever was released. No one
wants to remove it.
Alright but... it was removed! See:
[EMAIL PROTECTED]:~# ip -V
ip utility, iproute2-ss051107
[EMAIL PROTECTED]:~# ip -4 address
Antonio Dias wrote:
Patrick McHardy [EMAIL PROTECTED] wrote:
It was broken in a CVS version, not sure if it ever was released. No one
wants to remove it.
Alright but... it was removed! See:
[EMAIL PROTECTED]:~# ip -V
ip utility, iproute2-ss051107
[EMAIL PROTECTED]:~# ip
On Tue, 2005-22-11 at 04:45 +0100, Patrick McHardy wrote:
jamal wrote:
yes, RTNL is one but most of the ones i just inspected are protected
under dev_base_lock; so this should be sufficient, no?
You mean other sysctls? I guess it depends on which ones you're
talking about, but if they
jamal wrote:
On Tue, 2005-22-11 at 04:45 +0100, Patrick McHardy wrote:
jamal wrote:
My point is: it clearly a bigger issue in a lot of places in the net
code - almost all ipv4 syctls suffer from this issue then.
Well, you have to check the code that uses them to see if it is
a problem. In
Patrick McHardy [EMAIL PROTECTED] wrote:
Indeed, it seems quite a few commands got lost. This patch restores
them.
Index: ip/ip.c
===
RCS file: /repos/iproute2/ip/ip.c,v
retrieving revision 1.10
diff -u -r1.10 ip.c
---
Antonio Dias wrote:
Patrick McHardy [EMAIL PROTECTED] wrote:
Indeed, it seems quite a few commands got lost. This patch restores
them.
Index: ip/ip.c
===
RCS file: /repos/iproute2/ip/ip.c,v
retrieving revision 1.10
diff -u
On Sun, Nov 20, 2005 at 04:31:34PM +, Patrick McHardy wrote:
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index ae0779d..b93e7cd 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -78,6 +79,34 @@ int ip_route_me_harder(struct sk_buff **
}
On Tue, 2005-22-11 at 05:20 +0100, Patrick McHardy wrote:
jamal wrote:
My point is: it clearly a bigger issue in a lot of places in the net
code - almost all ipv4 syctls suffer from this issue then.
Well, you have to check the code that uses them to see if it is
a problem. In this case
Patrick McHardy wrote:
Herbert Xu wrote:
On Sun, Nov 20, 2005 at 04:31:34PM +, Patrick McHardy wrote:
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index ae0779d..b93e7cd 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -78,6 +79,34 @@ int
Are there netlink socket
netlink_unicast () and netlink_broadcast () interrupt safe?
If not, where is the problem and the
direction to make them safe?
If it is not easy, what could be a workaroud?
Thank you in advance.
Robert
On Thu, Nov 17, 2005 at 03:28:24AM +0100, Patrick McHardy wrote:
- CLASSIFY fragments differently
- MARK fragments differently
- DSCP/ECN/TOS mark fragments differently
- Change TTLs of fragments to differently values
[...]
I've CCed Harald for his opinion in case I missed something.
I
52 matches
Mail list logo
