Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()

Hi, Chunhui He wrote: > Hi, > > On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov > wrote: >> >> Hello, >> >> On Thu, 21 Jul 2016, Chunhui He wrote: >> >>> If neigh entry was CONNECTED and address is not changed, and if new state is >>> STALE, entry state will not

Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()

Hi, Chunhui He wrote: > Hi, > > On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov > wrote: >> >> Hello, >> >> On Thu, 21 Jul 2016, Chunhui He wrote: >> >>> If neigh entry was CONNECTED and address is not changed, and if new state is >>> STALE, entry state will not change.

Re: [PATCH] ipv6: Fixed source specific default route handling.

Matthias Schiffer wrote: > On 06/22/2015 07:58 AM, Steven Barth wrote: >> On 22.06.2015 00:35, Matthias Schiffer wrote: >>> Could you explain in detail what you mean with "If you want specific SA, >>> add same route with higher metric and/or (more) specific src match."? >>> Routes aren't bound to

Re: [PATCH] ipv6: Fixed source specific default route handling.

Matthias Schiffer wrote: On 06/22/2015 07:58 AM, Steven Barth wrote: On 22.06.2015 00:35, Matthias Schiffer wrote: Could you explain in detail what you mean with If you want specific SA, add same route with higher metric and/or (more) specific src match.? Routes aren't bound to specific

Re: [PATCH] neighbour: Convert if statment in the function, neigh_add_timer to a WARN_ON

Nicholas Krause wrote: > This converts the if statement for dumping the stack into a > WARN_ON in order to make this function's debugging check > simpler and have a cleaner output when this condition > occurs inside this function for when bugs related to > adding a duplicate neighbour table timer

Re: [PATCH] neighbour: Convert if statment in the function, neigh_add_timer to a WARN_ON

Nicholas Krause wrote: This converts the if statement for dumping the stack into a WARN_ON in order to make this function's debugging check simpler and have a cleaner output when this condition occurs inside this function for when bugs related to adding a duplicate neighbour table timer

Re: [PATCH 2/2] net: Export IGMP/MLD message validation code

Linus Lüssing wrote: > On Fri, Apr 10, 2015 at 07:46:39PM +0200, Linus Lüssing wrote: >> diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c >> new file mode 100644 >> index 000..95b34c0 >> --- /dev/null >> +++ b/net/ipv6/mcast_snoop.c >> @@ -0,0 +1,198 @@ >> +/* Copyright (C) 2015:

Re: [PATCH 2/2] net: Export IGMP/MLD message validation code

Linus Lüssing wrote: On Fri, Apr 10, 2015 at 07:46:39PM +0200, Linus Lüssing wrote: diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c new file mode 100644 index 000..95b34c0 --- /dev/null +++ b/net/ipv6/mcast_snoop.c @@ -0,0 +1,198 @@ +/* Copyright (C) 2015: Linus Lüssing

Re: [PATCH] Add IPv6 support to TCP SYN cookies

In article <[EMAIL PROTECTED]> (at Thu, 07 Feb 2008 10:40:19 +0100), Eric Dumazet <[EMAIL PROTECTED]> says: > [NET] IPV4: lower stack usage in cookie_hash() function > > 400 bytes allocated on stack might be a litle bit too much. Using a > per_cpu var is more friendly. > > Signed-off-by: Eric

Re: [PATCH] Add IPv6 support to TCP SYN cookies

In article [EMAIL PROTECTED] (at Thu, 07 Feb 2008 10:40:19 +0100), Eric Dumazet [EMAIL PROTECTED] says: [NET] IPV4: lower stack usage in cookie_hash() function 400 bytes allocated on stack might be a litle bit too much. Using a per_cpu var is more friendly. Signed-off-by: Eric Dumazet

Re: [PATCH] Add IPv6 support to TCP SYN cookies

In article <[EMAIL PROTECTED]> (at Thu, 7 Feb 2008 21:49:26 -0800), Glenn Griffin <[EMAIL PROTECTED]> says: > Updated to incorporate Eric's suggestion of using a per cpu buffer > rather than allocating on the stack. Just a two line change, but will > resend in it's entirety. > >

Re: [PATCH] Add IPv6 support to TCP SYN cookies

In article [EMAIL PROTECTED] (at Thu, 7 Feb 2008 21:49:26 -0800), Glenn Griffin [EMAIL PROTECTED] says: Updated to incorporate Eric's suggestion of using a per cpu buffer rather than allocating on the stack. Just a two line change, but will resend in it's entirety. Signed-off-by: Glenn

Re: [PATCH] IPV4: fix compile error building without CONFIG_FS_PROC

In article <[EMAIL PROTECTED]> (at Mon, 04 Feb 2008 08:47:29 +0800), Li Zefan <[EMAIL PROTECTED]> says: > compile error building without CONFIG_FS_PROC. : > The exit method should have no return values... Have you really tested this with CONFIG_FS_PROC? --yoshfuji -- To unsubscribe from this

Re: [PATCH] IPV4: fix compile error building without CONFIG_FS_PROC

In article [EMAIL PROTECTED] (at Mon, 04 Feb 2008 08:47:29 +0800), Li Zefan [EMAIL PROTECTED] says: compile error building without CONFIG_FS_PROC. : The exit method should have no return values... Have you really tested this with CONFIG_FS_PROC? --yoshfuji -- To unsubscribe from this list:

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Sat, 19 Jan 2008 14:44:13 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001 > From: Jan Engelhardt <[EMAIL PROTECTED]> > Date: Fri, 18 Jan 2008 02:10:44 +0100 > Subject: [PATCH] IPv4:

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Sat, 19 Jan 2008 14:44:13 +0100 (CET)), Jan Engelhardt [EMAIL PROTECTED] says: From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001 From: Jan Engelhardt [EMAIL PROTECTED] Date: Fri, 18 Jan 2008 02:10:44 +0100 Subject: [PATCH] IPv4: enable

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 11:13:19 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says: > Assuming IN_BADCLASS() is still there, we should not reuse the name > of "ipv6_is_badclass" because the their meanings are different. Agai

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:52:08 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > > On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote: > >> -#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > >>

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:13:52 +0100 (CET)), Jan Engelhardt <[EMAIL PROTECTED]> says: > diff --git a/include/linux/in.h b/include/linux/in.h > index 27d8a5a..b01bf75 100644 > --- a/include/linux/in.h > +++ b/include/linux/in.h > @@ -216,9 +216,6 @@ struct

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Fri, 18 Jan 2008 02:13:52 +0100 (CET)), Jan Engelhardt [EMAIL PROTECTED] says: diff --git a/include/linux/in.h b/include/linux/in.h index 27d8a5a..b01bf75 100644 --- a/include/linux/in.h +++ b/include/linux/in.h @@ -216,9 +216,6 @@ struct sockaddr_in {

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Fri, 18 Jan 2008 02:52:08 +0100 (CET)), Jan Engelhardt [EMAIL PROTECTED] says: On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote: -#define IN_EXPERIMENTAL(a) long int) (a)) 0xf000) == 0xf000) -#define IN_BADCLASS

Re: [PATCH] IPv4: Enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Fri, 18 Jan 2008 11:13:19 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] says: Assuming IN_BADCLASS() is still there, we should not reuse the name of ipv6_is_badclass because the their meanings are different. Again, ipv4_is_badclass() My hands

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

Hello. In article <[EMAIL PROTECTED]> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <[EMAIL PROTECTED]> says: > #define IN_MULTICAST_NET 0xF000 > > +#define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000) > +#define IN_CLASSE_NET 0xff00 >

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > > > There is no positive consesus on this

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen <[EMAIL PROTECTED]> says: > Vince Fuller <[EMAIL PROTECTED]> writes: > > > from Vince Fuller <[EMAIL PROTECTED]> > > > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > > (aka "class-E")

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen [EMAIL PROTECTED] says: Vince Fuller [EMAIL PROTECTED] writes: from Vince Fuller [EMAIL PROTECTED] This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka class-E) address space as

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

In article [EMAIL PROTECTED] (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller [EMAIL PROTECTED] says: From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) There is no positive consesus on this draft at the intarea meeting in Vancouver

Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.

In article <[EMAIL PROTECTED]> (at Thu, 27 Dec 2007 08:08:53 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > On Wed, 26 Dec 2007, H. Peter Anvin wrote: > > > Ray Lee wrote: > > > On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote: > > > > - if (jiffies -

Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.

In article [EMAIL PROTECTED] (at Thu, 27 Dec 2007 08:08:53 +0100 (CET)), Julia Lawall [EMAIL PROTECTED] says: On Wed, 26 Dec 2007, H. Peter Anvin wrote: Ray Lee wrote: On Dec 26, 2007 7:21 AM, Julia Lawall [EMAIL PROTECTED] wrote: - if (jiffies - ent-last_usage

Re: [PATCH 20/38] drivers/net: Use time_before, time_before_eq, etc.

In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:40:06 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/drivers/net/cassini.c b/drivers/net/cassini.c > --- a/drivers/net/cassini.c 2007-10-22 11:25:14.0 +0200 > +++ b/drivers/net/cassini.c 2007-12-23

Re: [PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.

In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:28:42 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c > b/drivers/infiniband/hw/ipath/ipath_mad.c > --- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22 11:25:09.0

Re: [PATCH 3/38] arch/ia64/sn: Use time_before, time_before_eq, etc.

In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:18:56 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > diff -r -u -p a/arch/ia64/sn/kernel/xpc_main.c > b/arch/ia64/sn/kernel/xpc_main.c > --- a/arch/ia64/sn/kernel/xpc_main.c 2007-11-12 10:35:56.0 +0100 > +++

Re: [PATCH 31/38] net/decnet: Use time_before, time_before_eq, etc.

In article <[EMAIL PROTECTED]> (at Mon, 24 Dec 2007 15:47:32 +0100 (CET)), Julia Lawall <[EMAIL PROTECTED]> says: > From: Julia Lawall <[EMAIL PROTECTED]> > > The functions time_before, time_before_eq, time_after, and time_after_eq > are more robust for comparing jiffies against other values.

Re: [PATCH 31/38] net/decnet: Use time_before, time_before_eq, etc.

In article [EMAIL PROTECTED] (at Mon, 24 Dec 2007 15:47:32 +0100 (CET)), Julia Lawall [EMAIL PROTECTED] says: From: Julia Lawall [EMAIL PROTECTED] The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. -

Re: [PATCH 3/38] arch/ia64/sn: Use time_before, time_before_eq, etc.

In article [EMAIL PROTECTED] (at Mon, 24 Dec 2007 15:18:56 +0100 (CET)), Julia Lawall [EMAIL PROTECTED] says: diff -r -u -p a/arch/ia64/sn/kernel/xpc_main.c b/arch/ia64/sn/kernel/xpc_main.c --- a/arch/ia64/sn/kernel/xpc_main.c 2007-11-12 10:35:56.0 +0100 +++

Re: [PATCH 15/38] drivers/infiniband: Use time_before, time_before_eq, etc.

In article [EMAIL PROTECTED] (at Mon, 24 Dec 2007 15:28:42 +0100 (CET)), Julia Lawall [EMAIL PROTECTED] says: diff -r -u -p a/drivers/infiniband/hw/ipath/ipath_mad.c b/drivers/infiniband/hw/ipath/ipath_mad.c --- a/drivers/infiniband/hw/ipath/ipath_mad.c 2007-10-22 11:25:09.0 +0200

Re: [PATCH 20/38] drivers/net: Use time_before, time_before_eq, etc.

In article [EMAIL PROTECTED] (at Mon, 24 Dec 2007 15:40:06 +0100 (CET)), Julia Lawall [EMAIL PROTECTED] says: diff -r -u -p a/drivers/net/cassini.c b/drivers/net/cassini.c --- a/drivers/net/cassini.c 2007-10-22 11:25:14.0 +0200 +++ b/drivers/net/cassini.c 2007-12-23

Re: "ip neigh show" not showing arp cache entries?

In article <[EMAIL PROTECTED]> (at Wed, 12 Dec 2007 15:57:08 -0600), "Chris Friesen" <[EMAIL PROTECTED]> says: > > You may try other versions of this command > > > > http://devresources.linux-foundation.org/dev/iproute2/download/ > > They appear to be numbered by kernel version, and the above

Re: ip neigh show not showing arp cache entries?

In article [EMAIL PROTECTED] (at Wed, 12 Dec 2007 15:57:08 -0600), Chris Friesen [EMAIL PROTECTED] says: You may try other versions of this command http://devresources.linux-foundation.org/dev/iproute2/download/ They appear to be numbered by kernel version, and the above version is

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

In article <[EMAIL PROTECTED]> (at Thu, 22 Nov 2007 10:34:03 +0800), Herbert Xu <[EMAIL PROTECTED]> says: > On Wed, Nov 21, 2007 at 07:17:40PM -0500, Jeff Garzik wrote: > > > > For those interested, I am dealing with a UDP app that already does very > > strong checksumming and encryption, so

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

In article <[EMAIL PROTECTED]> (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik <[EMAIL PROTECTED]> says: > > SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, > based on a reading of net/ipv4/udp.c. Disagree. UDP checksum is mandatory in IPv6. --yoshfuji - To

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

In article [EMAIL PROTECTED] (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik [EMAIL PROTECTED] says: SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, based on a reading of net/ipv4/udp.c. Disagree. UDP checksum is mandatory in IPv6. --yoshfuji - To unsubscribe from

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

In article [EMAIL PROTECTED] (at Thu, 22 Nov 2007 10:34:03 +0800), Herbert Xu [EMAIL PROTECTED] says: On Wed, Nov 21, 2007 at 07:17:40PM -0500, Jeff Garzik wrote: For those interested, I am dealing with a UDP app that already does very strong checksumming and encryption, so additional

Re: [TOMOYO #5 11/18] Network access control functions.

Hello. In article <[EMAIL PROTECTED]> (at Sat, 17 Nov 2007 02:34:50 +0900), [EMAIL PROTECTED] says: > + *cp++ = '\0'; > + count = sscanf(cp, > +NIP6_FMT "-" NIP6_FMT, > +[0], [1], [2], [3], > +[4], [5], [6], [7], > +

Re: [TOMOYO #5 11/18] Network access control functions.

Hello. In article [EMAIL PROTECTED] (at Sat, 17 Nov 2007 02:34:50 +0900), [EMAIL PROTECTED] says: + *cp++ = '\0'; + count = sscanf(cp, +NIP6_FMT - NIP6_FMT, +min[0], min[1], min[2], min[3], +min[4], min[5], min[6], min[7],

Re: [PATCH 2/2] add SubmittingPatches to Documentation/ja_JP

Hello. Basically okay, but please refer to the original DCO document. Your mailer is broken. You should include "charset" parameter in your multipart. Maybe it is better to prepare a git repository, or attach it as a binary (application/octet-stream). --yoshfuji In article <[EMAIL

Re: [PATCH 2/2] add SubmittingPatches to Documentation/ja_JP

Hello. Basically okay, but please refer to the original DCO document. Your mailer is broken. You should include charset parameter in your multipart. Maybe it is better to prepare a git repository, or attach it as a binary (application/octet-stream). --yoshfuji In article [EMAIL PROTECTED]

Re: NVIDIA Ethernet & invalid MAC

In article <[EMAIL PROTECTED]> (at Tue, 16 Oct 2007 12:00:45 -0400), Jeff Garzik <[EMAIL PROTECTED]> says: > Alan Cox wrote: > >> See the below for another report of this: > >> > >> http://marc.info/?t=11921571691=1=2 > >> > >> And apparently some motherboard vendors have their own

Re: NVIDIA Ethernet invalid MAC

In article [EMAIL PROTECTED] (at Tue, 16 Oct 2007 12:00:45 -0400), Jeff Garzik [EMAIL PROTECTED] says: Alan Cox wrote: See the below for another report of this: http://marc.info/?t=11921571691r=1w=2 And apparently some motherboard vendors have their own allocations for ethernet

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > Peter Zijlstra wrote: > > Also, how do you avoid referencing dead data with your sll? I haven't > > actually looked at your patches, but the simple scheme you outlined > > didn't handle

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > Well, is there a way to avoid read_lock when reading list? > > Currently, TOMOYO Linux avoids read_lock, on the assumption that > (1) First, ptr->next is initialized with NULL. > (2)

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article <[EMAIL PROTECTED]> (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > It seems that standard kernel list API does not have singly-linked list > manipulation. > I'm considering the following list manipulation API. Tstsuo, please name it "slist", which is

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 20:24:52 +0900), Tetsuo Handa [EMAIL PROTECTED] says: It seems that standard kernel list API does not have singly-linked list manipulation. I'm considering the following list manipulation API. Tstsuo, please name it slist, which is

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 22:04:11 +0900), Tetsuo Handa [EMAIL PROTECTED] says: Well, is there a way to avoid read_lock when reading list? Currently, TOMOYO Linux avoids read_lock, on the assumption that (1) First, ptr-next is initialized with NULL. (2) Later,

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article [EMAIL PROTECTED] (at Wed, 3 Oct 2007 23:26:57 +0900), Tetsuo Handa [EMAIL PROTECTED] says: Peter Zijlstra wrote: Also, how do you avoid referencing dead data with your sll? I haven't actually looked at your patches, but the simple scheme you outlined didn't handle the

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article <[EMAIL PROTECTED]> (at Tue, 2 Oct 2007 21:44:57 +0900), Tetsuo Handa <[EMAIL PROTECTED]> says: > If I use "struct hlist_node" which has two pointers, > it needs more memory than "struct something" which has one pointer. > It is possible to use API defined in include/linux/list.h , >

Re: [TOMOYO 05/15](repost) Domain transition handler functions.

In article [EMAIL PROTECTED] (at Tue, 2 Oct 2007 21:44:57 +0900), Tetsuo Handa [EMAIL PROTECTED] says: If I use struct hlist_node which has two pointers, it needs more memory than struct something which has one pointer. It is possible to use API defined in include/linux/list.h , but to

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: lepton <[EMAIL PROTECTED]> > Date: Tue, 18 Sep 2007 10:16:17 +0800 > > > Hi, > > In some situation, icmp_reply and ip_send_reply will send > > out packet with the wrong

Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in skb to reply packet

In article [EMAIL PROTECTED] (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: From: lepton [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 10:16:17 +0800 Hi, In some situation, icmp_reply and ip_send_reply will send out packet with the wrong source addr,

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: > > > Would you explain why it does not work properly > > for those cases? > > Mo

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. : Well, retrans_time_ms and base_reachable_time_ms

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) > > > I disagree. It is bad to remove existi

Re: [PATCH 3/3] sysctl: Error on bad sysctl tables

Hello. In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 14:09:29 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > After going through the kernels sysctl tables several times it has > become clear that code review and testing is just not effective in > prevent problematic sysctl tables

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

Hello. In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. > > - In neighbour.c reorder the table to put

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

Hello. In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. - In neighbour.c reorder the table to put the

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes: Would you explain why it does not work properly for those cases? Mostly no appropriate strategy routine was setup

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. : Well, retrans_time_ms and base_reachable_time_ms supercedes

Re: [PATCH 3/3] sysctl: Error on bad sysctl tables

Hello. In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 14:09:29 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: After going through the kernels sysctl tables several times it has become clear that code review and testing is just not effective in prevent problematic sysctl tables from

Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.

In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) I disagree. It is bad to remove existing interface. Ditto for other patches. I

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 17:12:03 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > Contrarily, there may be ipv6_addr_type() call sites that really > do want to reject rfc4193 addresses. I do not think we have such users. --yoshfuji - To unsubscribe from this

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

Hello. In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson <[EMAIL PROTECTED]> says: > ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast > Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range. Acked-by: YOSHIFUJI Hideaki <[EMAIL

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"

In article <[EMAIL PROTECTED]> (at Thu, 26 Jul 2007 16:29:55 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > > Yes, it definitely does. Thank you. > > OK, so here it goes again with a changelog: > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Generally, sysdev_shutdown()

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"

Hello. In article <[EMAIL PROTECTED]> (at Thu, 26 Jul 2007 14:12:33 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > On Wednesday, 25 July 2007 17:28, YOSHIFUJI Hideaki / 吉藤英明 wrote: > > Hello. > > > > In article <[EMAIL PROTECTED]> (at

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

In article [EMAIL PROTECTED] (at Wed, 25 Jul 2007 17:12:03 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: Contrarily, there may be ipv6_addr_type() call sites that really do want to reject rfc4193 addresses. I do not think we have such users. --yoshfuji - To unsubscribe from this list:

Re: [PATCH] IPv6: ipv6_addr_type() doesn't know about RFC4193 addresses

Hello. In article [EMAIL PROTECTED] (at Wed, 25 Jul 2007 19:49:09 -0400), Dave Johnson [EMAIL PROTECTED] says: ipv6_addr_type() doesn't check for 'Unique Local IPv6 Unicast Addresses' (RFC4193) and returns IPV6_ADDR_RESERVED for that range. Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] I

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by PM: Introduce pm_power_off_prepare

In article [EMAIL PROTECTED] (at Thu, 26 Jul 2007 16:29:55 +0200), Rafael J. Wysocki [EMAIL PROTECTED] says: Yes, it definitely does. Thank you. OK, so here it goes again with a changelog: --- From: Rafael J. Wysocki [EMAIL PROTECTED] Generally, sysdev_shutdown() should be called

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by PM: Introduce pm_power_off_prepare

Hello. In article [EMAIL PROTECTED] (at Thu, 26 Jul 2007 14:12:33 +0200), Rafael J. Wysocki [EMAIL PROTECTED] says: On Wednesday, 25 July 2007 17:28, YOSHIFUJI Hideaki / 吉藤英明 wrote: Hello. In article [EMAIL PROTECTED] (at Wed, 25 Jul 2007 14:46:55 +0200), Rafael J. Wysocki [EMAIL

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"

Hello. In article <[EMAIL PROTECTED]> (at Wed, 25 Jul 2007 14:46:55 +0200), "Rafael J. Wysocki" <[EMAIL PROTECTED]> says: > On Wednesday, 25 July 2007 00:19, YOSHIFUJI Hideaki / 吉藤英明 wrote: : > > Linux 2.6.23-rc1 fails to power off my ThinkPad T42. > >

Re: [2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by PM: Introduce pm_power_off_prepare

Hello. In article [EMAIL PROTECTED] (at Wed, 25 Jul 2007 14:46:55 +0200), Rafael J. Wysocki [EMAIL PROTECTED] says: On Wednesday, 25 July 2007 00:19, YOSHIFUJI Hideaki / 吉藤英明 wrote: : Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me that the following commit

[2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by "PM: Introduce pm_power_off_prepare"

Hello. Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me that the following commit is to blame, and by reverting that commit, it works appropriately. Regards, --yoshfuji bd804eba1c8597cbb7cd5a5f9fe886aae16a079a is first bad commit commit

[2.6.23-rc1 REGRESSION] ThinkPad T42 poweroff failure by PM: Introduce pm_power_off_prepare

Hello. Linux 2.6.23-rc1 fails to power off my ThinkPad T42. Git-bisect told me that the following commit is to blame, and by reverting that commit, it works appropriately. Regards, --yoshfuji bd804eba1c8597cbb7cd5a5f9fe886aae16a079a is first bad commit commit

Re: [PATCH][RFC] network splice receive v3

Hello. In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 11:19:27 +0200), Jens Axboe <[EMAIL PROTECTED]> says: > @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = { > .recvmsg = sock_common_recvmsg, > .mmap = sock_no_mmap, > .sendpage

Re: [PATCH][RFC] network splice receive v3

Hello. In article [EMAIL PROTECTED] (at Wed, 11 Jul 2007 11:19:27 +0200), Jens Axboe [EMAIL PROTECTED] says: @@ -835,6 +835,7 @@ const struct proto_ops inet_stream_ops = { .recvmsg = sock_common_recvmsg, .mmap = sock_no_mmap, .sendpage =

Re: [PATCH try#5] Blackfin ethernet driver: on chip ethernet MAC controller driver

Hello. In article <[EMAIL PROTECTED]> (at Tue, 17 Jul 2007 00:49:02 +0800), Bryan Wu <[EMAIL PROTECTED]> says: > +static void bf537mac_set_multicast_list(struct net_device *dev) > +{ > + u32 sysctl; > + > + if (dev->flags & IFF_PROMISC) { > + printk(KERN_INFO "%s: set to

Re: [PATCH try#5] Blackfin ethernet driver: on chip ethernet MAC controller driver

Hello. In article [EMAIL PROTECTED] (at Tue, 17 Jul 2007 00:49:02 +0800), Bryan Wu [EMAIL PROTECTED] says: +static void bf537mac_set_multicast_list(struct net_device *dev) +{ + u32 sysctl; + + if (dev-flags IFF_PROMISC) { + printk(KERN_INFO %s: set to promisc mode\n,

Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd

In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:55:29 -0700), Greg KH <[EMAIL PROTECTED]> says: > On Thu, Jul 12, 2007 at 08:50:47AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ > wrote: > > In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:31:43 -0700), Greg > > Kroah-Hartman <[EMAIL

Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd

In article <[EMAIL PROTECTED]> (at Wed, 11 Jul 2007 16:31:43 -0700), Greg Kroah-Hartman <[EMAIL PROTECTED]> says: > Make sysfs_put() ignore NULL sd instead of oopsing. I do not think this is a good idea; it is non-sense (and rather a bug) to call "put" with NULL argument in general. --yoshfuji

Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd

In article [EMAIL PROTECTED] (at Wed, 11 Jul 2007 16:31:43 -0700), Greg Kroah-Hartman [EMAIL PROTECTED] says: Make sysfs_put() ignore NULL sd instead of oopsing. I do not think this is a good idea; it is non-sense (and rather a bug) to call put with NULL argument in general. --yoshfuji - To

Re: [PATCH 24/61] sysfs: make sysfs_put() ignore NULL sd

In article [EMAIL PROTECTED] (at Wed, 11 Jul 2007 16:55:29 -0700), Greg KH [EMAIL PROTECTED] says: On Thu, Jul 12, 2007 at 08:50:47AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: In article [EMAIL PROTECTED] (at Wed, 11 Jul 2007 16:31:43 -0700), Greg Kroah-Hartman [EMAIL PROTECTED]

sysfs: release mutex when kmalloc() failed in sysfs_open_file().

Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> -- diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..1f64ce5 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -283,6 +283,7 @@ static int sysfs_open_file(struct inode *inode, struct file *file) mutex_lock(>i_mutex);

sysfs: release mutex when kmalloc() failed in sysfs_open_file().

Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] -- diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index b502c71..1f64ce5 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -283,6 +283,7 @@ static int sysfs_open_file(struct inode *inode, struct file *file) mutex_lock(inode-i_mutex);

Re: TCP_MD5 and Intel e1000

In article <[EMAIL PROTECTED]> (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet <[EMAIL PROTECTED]> says: > > I have tried to set up quagga with tcp-md5 support from kernel. All seems ok > > with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp > > packets have an invalid md5

Re: TCP_MD5 and Intel e1000

In article [EMAIL PROTECTED] (at Tue, 22 May 2007 10:57:38 +0200), Eric Dumazet [EMAIL PROTECTED] says: I have tried to set up quagga with tcp-md5 support from kernel. All seems ok with a intel e100 NIC, but as i testetd with a intel e1000 NIC the tcp packets have an invalid md5 digest.

Re: linux-2.6.21-gitN - versioning question

In article <[EMAIL PROTECTED]> (at Sat, 12 May 2007 13:19:23 +0200 (MEST)), Jan Engelhardt <[EMAIL PROTECTED]> says: > I notice that people refer to certain git snapshots as e.g. -git16; > kernel.org does so too. Hovering over the link on kernel.org reveals >

Re: linux-2.6.21-gitN - versioning question

In article [EMAIL PROTECTED] (at Sat, 12 May 2007 13:19:23 +0200 (MEST)), Jan Engelhardt [EMAIL PROTECTED] says: I notice that people refer to certain git snapshots as e.g. -git16; kernel.org does so too. Hovering over the link on kernel.org reveals

Re: [PATCH] x86: Fix potential overflow in perfctr reservation

Hello. In article <[EMAIL PROTECTED]> (at Sun, 22 Apr 2007 01:09:17 -0700), Andrew Morton <[EMAIL PROTECTED]> says: > > [PATCH] x86: Fix potential overflow in perfctr reservation : > The created a warning storm: > > > arch/i386/kernel/nmi.c: In function 'avail_to_resrv_perfctr_nmi_bit': >

Re: [PATCH] x86: Fix potential overflow in perfctr reservation

Hello. In article [EMAIL PROTECTED] (at Sun, 22 Apr 2007 01:09:17 -0700), Andrew Morton [EMAIL PROTECTED] says: [PATCH] x86: Fix potential overflow in perfctr reservation : The created a warning storm: arch/i386/kernel/nmi.c: In function 'avail_to_resrv_perfctr_nmi_bit':

Re: IPv6: Connection reset/timeout under heavy load

In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 02:26:24 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > > http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/yoshfuji/linux-2.6-fix.git;a=commit;h=33a79bba0cc2f197b46cc54182f94c31ff6ad334 > > > > I hope this patch will go in

Re: IPv6: Connection reset/timeout under heavy load

In article <[EMAIL PROTECTED]> (at Wed, 28 Mar 2007 10:48:27 +0200), Agoston Horvath <[EMAIL PROTECTED]> says: > YOSHIFUJI Hideaki / 吉藤英明 wrote: > > Would you test with latest kernel, if possible, please? > > For the archive: switching to 2.6.20.4 fixed this problem.

Re: IPv6: Connection reset/timeout under heavy load

In article [EMAIL PROTECTED] (at Wed, 28 Mar 2007 10:48:27 +0200), Agoston Horvath [EMAIL PROTECTED] says: YOSHIFUJI Hideaki / 吉藤英明 wrote: Would you test with latest kernel, if possible, please? For the archive: switching to 2.6.20.4 fixed this problem. Thank you for your report. I guess

  1   2   >