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
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 Iakoba
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 ip_route_me_harder(stru
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 ip_route_me_harder(struct sk_buff **
}
EXPORT_SY
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> >No, the change you quoted at the beginning of this thread fixed
> >shortcuts, which means instead of address you can also use
> >"a", "ad", "add", and so on. Actually the ordering of this list
> >also matters to keep full compatibility, I need to rechec
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 thi
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 **
> }
> EXPORT_SYMBOL
Patrick McHardy wrote:
Antonio Dias wrote:
Hum... to me seens like your patch will restore those lost objects but
will discard shortcuts "addr", "maddr" and "neigh" and I think this will
cause problems too.
No, the change you quoted at the beginning of this thread fixed
shortcuts, which mean
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 -r
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
> -
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
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, bu
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
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 addre
jamal wrote:
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 a
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 packag
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 anyt
Antonio Dias wrote:
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 changel
On Tue, 2005-22-11 at 00:01 -0300, Antonio Dias wrote:
> 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
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 insid
On Tue, 2005-22-11 at 03:56 +0100, Patrick McHardy wrote:
> jamal wrote:
>
> > Are you suggesting not to check for IN_DEV_PROMOTE_SECONDARIES the
> > second time?
>
> 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 chan
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 th
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 IN_DE
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 IN_DEV_PROMOTE_SE
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 inet_del_ifa(stru
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 inet_del_ifa(struct in_devic
*/
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
Dave,
This is a bug fix. So not sure if it is fitting for 2.6.15 or not.
Much thanks to Brian Pomerantz for thorough testing over the weekend and
today.
cheers,
jamal
This patch fixes the problem with promoting aliases when:
a) a single primary and > 1 secondary addresses
b) multiple primary
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
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 ta
On Mon, Nov 21, 2005 at 04:51:03PM -0600, Christopher Friesen wrote:
>
> Should that be getsockname(2)? Anyways, I now understand the issues.
Yes that's what I meant.
> As it turns out, we were actually already calling getsockname() a bit
> earlier in the code path, so we can just use the "pid
On Tue, Nov 22, 2005 at 01:49:13AM +0300, Alexey Kuznetsov wrote:
>
> Actually, I remember one discussion. Herbert, wait a minute...
> That's it: February 2005, Subject: [PATCH] Add audit uid to netlink
> credentials
> We decided (or not?) that binding to anything but tgid and pid
> must be prohi
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 mak
Herbert Xu wrote:
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 a
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
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 previo
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
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(),
Hello!
> TIPC wants the user to fill in the pid to use in the nlmsghdr portion of
> a particular message.
It is wrong. netlink_pid used not to be associated with process pids.
Kernel used pid just as a seed to calculate a random value to bind,
when user did not bind explicitly. It is equal to cu
On 11/21/05, Martin Josefsson <[EMAIL PROTECTED]> wrote:
> > 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 autonegotiat
David Kimdon <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.4.x/net/core/skbuff.c
> +++ linux-2.4.x/net/core/skbuff.c
> @@ -216,6 +216,9 @@
>atomic_set(&(skb_shinfo(skb)->dataref), 1);
>skb_shinfo(skb)->nr_frags = 0;
>skb_shinfo(skb)->frag_list = NULL;
> +#if defined(CONFIG_BRI
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
Christopher Friesen <[EMAIL PROTECTED]> wrote:
>
> When an NPTL child thread uses getpid() to specify the pid, it never
> receives a response to this request. Running the same code on the
> parent works, and running the same code under Linuxthreads works.
As I said before, you should not rely
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.
Leak
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
> > > whi
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 mea
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
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
On Mon, 21 Nov 2005 21:56:32 +0100
Aritz Bastida <[EMAIL PROTECTED]> wrote
The network developers don't always read lkml, please move this
thread to netdev@vger.kernel.org
> Hello everybody.
>
> What I need is to turn off and on the polling done to a network device
> which works with NAPI. I'll
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 si
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 unre
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 pr
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
On Mon, 2005-11-21 at 10:12 -0800, Jesse Brandeburg wrote:
> Hi, thanks for the input. I have a couple of questions.
Hi Jesse
> 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 b
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 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://netfilt
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
> fun
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 structur
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 pa
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 he
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. (http://www.linsyssoft.com/un
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 i
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.
-
>...
> 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 2.6.
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_deb
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
- cardcoun
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 i
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
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
70 matches
Mail list logo
