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

[YOSHIFUJI Hideaki/吉藤英明]

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. Because DELAY is not in CONNECTED, it's
>>> possible to change state from DELAY to STALE.
>>>
>>> That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state
>>> is referenced to send packets, so goes to DELAY state. If the entry is not
>>> confirmed by upper layer, it goes to PROBE state, and sends ARP request.
>>> The neigh host sends ARP reply, then the entry goes to REACHABLE state.
>>> But the entry state may be reseted to STALE by broadcast ARP packets, before
>>> the entry goes to PROBE state. So it's possible that the entry will never go
>>> to REACHABLE state, without external confirmation.
>>>
>>> In my case, the gateway refuses to send unicast packets to me, before it 
>>> sees
>>> my ARP request. So it's critical to enter REACHABLE state by sending ARP
>>> request, but not by external confirmation.
>>>
>>> This fixes neigh_update() not to change to STALE if old state is CONNECTED 
>>> or
>>> DELAY.
>>>
>>> Signed-off-by: Chunhui He 
>>> ---
>>>  net/core/neighbour.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>>> index 510cd62..29429eb 100644
>>> --- a/net/core/neighbour.c
>>> +++ b/net/core/neighbour.c
>>> @@ -1152,7 +1152,7 @@ int neigh_update(struct neighbour *neigh, const u8 
>>> *lladdr, u8 new,
>>> } else {
>>> if (lladdr == neigh->ha && new == NUD_STALE &&
>>> ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
>>> -(old & NUD_CONNECTED))
>>> +(old & (NUD_CONNECTED | NUD_DELAY)))
>>> )
>>> new = old;
>>> }
>>
>>  You change looks correct to me. But this place
>> has more problems. There is no good reason to set NUD_STALE
>> for any state that is NUD_VALID if address is not changed.
>> This matches perfectly the comment above this code:
>> NUD_STALE should change a NUD_VALID state only when
>> address changes. It also means that IPv6 does not need
>> to provide NEIGH_UPDATE_F_WEAK_OVERRIDE anymore when
>> NEIGH_UPDATE_F_OVERRIDE is also present.
>>
> 
> The NEIGH_UPDATE_F_WEAK_OVERRIDE is confusing to me, so I choose not to deal
> with the flag.

IPv6 depends on WEAK_OVERRIDE.  Please do not change.

> 
>>  By this way the state machine can continue with
>> the resolving: NUD_STALE -> NUD_DELAY (traffic) ->
>> NUD_PROBE (retries) -> NUD_REACHABLE (unicast reply)
>> while the address is not changed. Your change covers only
>> NUD_DELAY, not NUD_PROBE, so it is better to allow more
>> retries to send. We should not give up until success (NUD_REACHABLE).
>>
> 
> I have thought about this.
> The origin code allows NUD_DELAY -> NUD_STALE and NUD_PROBE -> NUD_STALE.
> This part was imported to kernel since v2.1.79, I don't know clearly why it
> allows that.
> 
> My analysis:
> (1) As shown in my previous mail, NUD_DELAY -> NUD_STALE may cause "dead 
> loop",
> so it should be fixed.
> 
> (2) But NUD_PROBE -> NUD_STALE is acceptable, because in NUD_PROBE, ARP 
> request
> has been sent, it is sufficient to break the "dead loop".
> More attempts are accomplished by the following sequence:
> NUD_STALE --> NUD_DELAY -(sent req)-> NUD_PROBE -(reset by neigh_update())->
> NUD_STALE --> NUD_DELAY -(send req again)-> ... -->
> NUD_REACHABLE
> 
> 
> But I also agree your change.
> 
>>  Second problem: NEIGH_UPDATE_F_WEAK_OVERRIDE has no
>> priority over NEIGH_UPDATE_F_ADMIN. For example, now I can not
>> change from NUD_PERMANENT to NUD_STALE:
>>
>> # ip neigh add 192.168.168.111 lladdr 00:11:22:33:44:55 nud perm dev wlan0
>> # ip neigh show to 192.168.168.111
>> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
>> # ip neigh change 192.168.168.111 lladdr 00:11:22:33:44:55 nud stale dev 
>> wlan0
>> # ip neigh show to 192.168.168.111
>> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
>>
>>  IMHO, here is how this place should look:
>>
>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>> index 5cdc62a..2b1cb91 100644
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -1151,10 +1151,8 @@ int neigh_update(struct neighbour *neigh, const u8 
>> *lladdr, u8 new,
>>  goto out;
>>  } else {
>>  if (lladdr == neigh->ha && new == NUD_STALE &&
>> -((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
>> - (old & NUD_CONNECTED))
>> -)
>> -new = old;
>> +!(flags & NEIGH_UPDATE_F_ADMIN))
>> +  

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

[YOSHIFUJI Hideaki/吉藤英明]

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. Because DELAY is not in CONNECTED, it's
>>> possible to change state from DELAY to STALE.
>>>
>>> That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state
>>> is referenced to send packets, so goes to DELAY state. If the entry is not
>>> confirmed by upper layer, it goes to PROBE state, and sends ARP request.
>>> The neigh host sends ARP reply, then the entry goes to REACHABLE state.
>>> But the entry state may be reseted to STALE by broadcast ARP packets, before
>>> the entry goes to PROBE state. So it's possible that the entry will never go
>>> to REACHABLE state, without external confirmation.
>>>
>>> In my case, the gateway refuses to send unicast packets to me, before it 
>>> sees
>>> my ARP request. So it's critical to enter REACHABLE state by sending ARP
>>> request, but not by external confirmation.
>>>
>>> This fixes neigh_update() not to change to STALE if old state is CONNECTED 
>>> or
>>> DELAY.
>>>
>>> Signed-off-by: Chunhui He 
>>> ---
>>>  net/core/neighbour.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>>> index 510cd62..29429eb 100644
>>> --- a/net/core/neighbour.c
>>> +++ b/net/core/neighbour.c
>>> @@ -1152,7 +1152,7 @@ int neigh_update(struct neighbour *neigh, const u8 
>>> *lladdr, u8 new,
>>> } else {
>>> if (lladdr == neigh->ha && new == NUD_STALE &&
>>> ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
>>> -(old & NUD_CONNECTED))
>>> +(old & (NUD_CONNECTED | NUD_DELAY)))
>>> )
>>> new = old;
>>> }
>>
>>  You change looks correct to me. But this place
>> has more problems. There is no good reason to set NUD_STALE
>> for any state that is NUD_VALID if address is not changed.
>> This matches perfectly the comment above this code:
>> NUD_STALE should change a NUD_VALID state only when
>> address changes. It also means that IPv6 does not need
>> to provide NEIGH_UPDATE_F_WEAK_OVERRIDE anymore when
>> NEIGH_UPDATE_F_OVERRIDE is also present.
>>
> 
> The NEIGH_UPDATE_F_WEAK_OVERRIDE is confusing to me, so I choose not to deal
> with the flag.

IPv6 depends on WEAK_OVERRIDE.  Please do not change.

> 
>>  By this way the state machine can continue with
>> the resolving: NUD_STALE -> NUD_DELAY (traffic) ->
>> NUD_PROBE (retries) -> NUD_REACHABLE (unicast reply)
>> while the address is not changed. Your change covers only
>> NUD_DELAY, not NUD_PROBE, so it is better to allow more
>> retries to send. We should not give up until success (NUD_REACHABLE).
>>
> 
> I have thought about this.
> The origin code allows NUD_DELAY -> NUD_STALE and NUD_PROBE -> NUD_STALE.
> This part was imported to kernel since v2.1.79, I don't know clearly why it
> allows that.
> 
> My analysis:
> (1) As shown in my previous mail, NUD_DELAY -> NUD_STALE may cause "dead 
> loop",
> so it should be fixed.
> 
> (2) But NUD_PROBE -> NUD_STALE is acceptable, because in NUD_PROBE, ARP 
> request
> has been sent, it is sufficient to break the "dead loop".
> More attempts are accomplished by the following sequence:
> NUD_STALE --> NUD_DELAY -(sent req)-> NUD_PROBE -(reset by neigh_update())->
> NUD_STALE --> NUD_DELAY -(send req again)-> ... -->
> NUD_REACHABLE
> 
> 
> But I also agree your change.
> 
>>  Second problem: NEIGH_UPDATE_F_WEAK_OVERRIDE has no
>> priority over NEIGH_UPDATE_F_ADMIN. For example, now I can not
>> change from NUD_PERMANENT to NUD_STALE:
>>
>> # ip neigh add 192.168.168.111 lladdr 00:11:22:33:44:55 nud perm dev wlan0
>> # ip neigh show to 192.168.168.111
>> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
>> # ip neigh change 192.168.168.111 lladdr 00:11:22:33:44:55 nud stale dev 
>> wlan0
>> # ip neigh show to 192.168.168.111
>> 192.168.168.111 dev wlan0 lladdr 00:11:22:33:44:55 PERMANENT
>>
>>  IMHO, here is how this place should look:
>>
>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>> index 5cdc62a..2b1cb91 100644
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -1151,10 +1151,8 @@ int neigh_update(struct neighbour *neigh, const u8 
>> *lladdr, u8 new,
>>  goto out;
>>  } else {
>>  if (lladdr == neigh->ha && new == NUD_STALE &&
>> -((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) ||
>> - (old & NUD_CONNECTED))
>> -)
>> -new = old;
>> +!(flags & NEIGH_UPDATE_F_ADMIN))
>> +goto out;
>>  }

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

[YOSHIFUJI Hideaki/吉藤英明]

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 addresses except via the "src" attribute
>>> (which is called prefsrc in the kernel), which is exactly what it not
>>> working. I can't control the chosen source address at all when
>>> source-specific routes are involved.
>> Except that prefsrc and src are two different beasts and usually ip route 
>> from transates to
>> RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length.
>>
>> Try adding two routes to the same destination with the same metric but 
>> different source values with PREFSRC (e.g. IPv4) and then
>> try doing the same with SRC (e.g. IPv6). The former will fail but the latter 
>> will succeed.
> 
> Ah sorry, I didn't know that "src" and "prefsrc" were distinct concepts.
> I meant to refer to "src" whenever I wrote "prefsrc". What are the
> precise semantics of the "src" attribute? Any RFC I can read, or is this
> a Linux-specific concept?
> 

"src" is long-lived feature which is usually used with mutiple routing
tables by "ip rule".

--yoshfuji

>>
>>
>> https://tools.ietf.org/html/draft-troan-homenet-sadr-01
>> was the original draft for source-address dependent routing IIRC so might be 
>> a good read.
> 
> Thanks for the link, that helps a bit.
> 
>>
>>
>>>
>>> Even though the source-specific route has a higher metric than the
>>> generic one, the source-specific one shadows the generic route.
>>
>> (was a bit ago since I read into this so please correct me if I am wrong)
>> IIRC this is intentional since longest-prefix-match beats metric here
>> and the source-address match counts to being more-specific here. See also 
>> above difference between PREFSRC and SRC.
> 
> Ah, that would explain the metric issue. I looks like the source of my
> confusion is that for source-specific routes *all* addresses are in the
> candidate set, not only the addresses of the outgoing interface (which
> makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in
> the source-specific case).
> 
> I'm not sure if this can be fixed in a sane way (as there seems to be a
> dependency cycle: source address should depend on outgoing interface,
> which depends on the chosen route, which depends on the source address),
> but it leads to highly unintuitive source address selection :(
> 
> Markus suggested in the commit message not to call ip6_route_output at
> all before the source address has been selected. Wouldn't this make it
> impossible to choose the source address depending on the outgoing
> interface in the non-source-specific case as well?
> 
>> Cheers,
>>
>> Steven
> 
> Thanks for the explanation,
> Matthias
> 

-- 
吉藤英明 
ミラクル・リナックス株式会社 技術本部 サポート部
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki/吉藤英明]

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 addresses except via the src attribute
 (which is called prefsrc in the kernel), which is exactly what it not
 working. I can't control the chosen source address at all when
 source-specific routes are involved.
 Except that prefsrc and src are two different beasts and usually ip route 
 from transates to
 RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length.

 Try adding two routes to the same destination with the same metric but 
 different source values with PREFSRC (e.g. IPv4) and then
 try doing the same with SRC (e.g. IPv6). The former will fail but the latter 
 will succeed.
 
 Ah sorry, I didn't know that src and prefsrc were distinct concepts.
 I meant to refer to src whenever I wrote prefsrc. What are the
 precise semantics of the src attribute? Any RFC I can read, or is this
 a Linux-specific concept?
 

src is long-lived feature which is usually used with mutiple routing
tables by ip rule.

--yoshfuji



 https://tools.ietf.org/html/draft-troan-homenet-sadr-01
 was the original draft for source-address dependent routing IIRC so might be 
 a good read.
 
 Thanks for the link, that helps a bit.
 



 Even though the source-specific route has a higher metric than the
 generic one, the source-specific one shadows the generic route.

 (was a bit ago since I read into this so please correct me if I am wrong)
 IIRC this is intentional since longest-prefix-match beats metric here
 and the source-address match counts to being more-specific here. See also 
 above difference between PREFSRC and SRC.
 
 Ah, that would explain the metric issue. I looks like the source of my
 confusion is that for source-specific routes *all* addresses are in the
 candidate set, not only the addresses of the outgoing interface (which
 makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in
 the source-specific case).
 
 I'm not sure if this can be fixed in a sane way (as there seems to be a
 dependency cycle: source address should depend on outgoing interface,
 which depends on the chosen route, which depends on the source address),
 but it leads to highly unintuitive source address selection :(
 
 Markus suggested in the commit message not to call ip6_route_output at
 all before the source address has been selected. Wouldn't this make it
 impossible to choose the source address depending on the outgoing
 interface in the non-source-specific case as well?
 
 Cheers,

 Steven
 
 Thanks for the explanation,
 Matthias
 

-- 
吉藤英明 hideaki.yoshif...@miraclelinux.com
ミラクル・リナックス株式会社 技術本部 サポート部
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki/吉藤英明]

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 arise.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  net/core/neighbour.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 3de6542..0bf71da 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -165,11 +165,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
>  static void neigh_add_timer(struct neighbour *n, unsigned long when)
>  {
>   neigh_hold(n);
> - if (unlikely(mod_timer(>timer, when))) {
> - printk("NEIGH: BUG, double timer add, state is %x\n",
> -n->nud_state);
> - dump_stack();
> - }
> + WARN_ON(unlikely(mod_timer(>timer, when)));
>  }

NACK, please do not use WARN_ON for things with side effects.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki/吉藤英明]

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 arise.
 
 Signed-off-by: Nicholas Krause xerofo...@gmail.com
 ---
  net/core/neighbour.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)
 
 diff --git a/net/core/neighbour.c b/net/core/neighbour.c
 index 3de6542..0bf71da 100644
 --- a/net/core/neighbour.c
 +++ b/net/core/neighbour.c
 @@ -165,11 +165,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
  static void neigh_add_timer(struct neighbour *n, unsigned long when)
  {
   neigh_hold(n);
 - if (unlikely(mod_timer(n-timer, when))) {
 - printk(NEIGH: BUG, double timer add, state is %x\n,
 -n-nud_state);
 - dump_stack();
 - }
 + WARN_ON(unlikely(mod_timer(n-timer, when)));
  }

NACK, please do not use WARN_ON for things with side effects.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki/吉藤英明]

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 
> 
> PS: I'm a little uncertain how this is usually done. If I should
> add someone (maybe Hideaki YOSHIFUJI, the original author of the
> bridge IPv6/MLD support?), then please let me know.

If you want to claim copyright, add myself (2010,
yoshf...@linux-ipv6.org).  You may have Authors: lines for both.
Also, you could have description like "Based on MLD support by
...".

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki/吉藤英明]

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 linus.luess...@c0d3.blue
 
 PS: I'm a little uncertain how this is usually done. If I should
 add someone (maybe Hideaki YOSHIFUJI, the original author of the
 bridge IPv6/MLD support?), then please let me know.

If you want to claim copyright, add myself (2010,
yoshf...@linux-ipv6.org).  You may have Authors: lines for both.
Also, you could have description like Based on MLD support by


--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 <[EMAIL PROTECTED]>

Applied to my inet6-2.6.26 tree.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 [EMAIL PROTECTED]

Applied to my inet6-2.6.26 tree.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 Griffin <[EMAIL PROTECTED]>

Applied in my linux-2.6-dev tree.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 Griffin [EMAIL PROTECTED]

Applied in my linux-2.6-dev tree.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 use of 240/4 address space
> 
> This short patch modifies the IPv4 networking to enable use of the
> 240.0.0.0/4 (aka "class-E") address space as propsed in the internet
> draft draft-fuller-240space-00.txt.
> 
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 use of 240/4 address space
 
 This short patch modifies the IPv4 networking to enable use of the
 240.0.0.0/4 (aka class-E) address space as propsed in the internet
 draft draft-fuller-240space-00.txt.
 
 Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 almost automatically type "6" after "ipv"...

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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(a)  IN_EXPERIMENTAL((a))
> >
> >No, please keep these macros.
> >
> >> @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
> >>  
> >>  static inline bool ipv4_is_badclass(__be32 addr)
> >>  {
> >> -  return (addr & htonl(0xf000)) == htonl(0xf000);
> >> +  return addr == 0x;
> >>  }
> >>  
> >
> >To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,
> 
> Unalign? IPv6? "Limited" broadcast?

Sorry, ipv4_is_badclass().
Assuming IN_BADCLASS() is still there, we should not reuse the name
of "ipv6_is_badclass" because the their meanings are different.

> -static inline bool ipv4_is_badclass(__be32 addr)
> +static inline bool ipv4_is_broadcast(__be32 addr)
>  {

I'm just afraid that people might think ipv4_is_broadcast
is for testing subnet broadcast address.

255.255.255.255 is "limited broadcast address"
(vs subnet broadcast address, which can be forwarded by routers).

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 {
>  #define  IN_MULTICAST(a) IN_CLASSD(a)
>  #define IN_MULTICAST_NET 0xF000
>  
> -#define  IN_EXPERIMENTAL(a)  long int) (a)) & 0xf000) == 
> 0xf000)
> -#define  IN_BADCLASS(a)  IN_EXPERIMENTAL((a))
> -
>  /* Address to accept any incoming messages. */
>  #define  INADDR_ANY  ((unsigned long int) 0x)
>  

No, please keep these macros.

> @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
>  
>  static inline bool ipv4_is_badclass(__be32 addr)
>  {
> - return (addr & htonl(0xf000)) == htonl(0xf000);
> + return addr == 0x;
>  }
>  

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,
you should change the name anyway, e.g., ipv6_is_limited_broadcast()
or some something alike.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 {
  #define  IN_MULTICAST(a) IN_CLASSD(a)
  #define IN_MULTICAST_NET 0xF000
  
 -#define  IN_EXPERIMENTAL(a)  long int) (a))  0xf000) == 
 0xf000)
 -#define  IN_BADCLASS(a)  IN_EXPERIMENTAL((a))
 -
  /* Address to accept any incoming messages. */
  #define  INADDR_ANY  ((unsigned long int) 0x)
  

No, please keep these macros.

 @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
  
  static inline bool ipv4_is_badclass(__be32 addr)
  {
 - return (addr  htonl(0xf000)) == htonl(0xf000);
 + return addr == 0x;
  }
  

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,
you should change the name anyway, e.g., ipv6_is_limited_broadcast()
or some something alike.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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(a)  IN_EXPERIMENTAL((a))
 
 No, please keep these macros.
 
  @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
   
   static inline bool ipv4_is_badclass(__be32 addr)
   {
  -  return (addr  htonl(0xf000)) == htonl(0xf000);
  +  return addr == 0x;
   }
   
 
 To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,
 
 Unalign? IPv6? Limited broadcast?

Sorry, ipv4_is_badclass().
Assuming IN_BADCLASS() is still there, we should not reuse the name
of ipv6_is_badclass because the their meanings are different.

 -static inline bool ipv4_is_badclass(__be32 addr)
 +static inline bool ipv4_is_broadcast(__be32 addr)
  {

I'm just afraid that people might think ipv4_is_broadcast
is for testing subnet broadcast address.

255.255.255.255 is limited broadcast address
(vs subnet broadcast address, which can be forwarded by routers).

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 almost automatically type 6 after ipv...

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
> +#define  IN_CLASSE_NSHIFT8
> +#define  IN_CLASSE_HOST  (0x & ~IN_CLASSE_NET)
> +
> +/* 
> + * these are no longer used
>  #define  IN_EXPERIMENTAL(a)  long int) (a)) & 0xf000) == 
> 0xf000)
>  #define  IN_BADCLASS(a)  IN_EXPERIMENTAL((a))
> +*/

Please do not remove this, but have these instead:

#define IN_EXPERIMENTAL(a)  IN_CLASSE((a))
#define IN_BADCASS(a)   IN_CLASSE((a))

And, I think it is good to remove BADCLASS() (inside
#ifdef __KERNEL__ .. #endif) because we do not have its users
any longer, right?

Regards,

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, right?
> > 
> > We cannot / should not enable that space until we have reached
> > a consensus on it.
> 
> This is so incredibly incorrect.
> 
> There is consensus on making network stacks able to use this
> address space.  And that is all that the patch does.

No, we did never make consensus on it.

> The consensus is only missing on whether to make the address
> space public or private.
> 
> This is also clearly spelled out in the draft.
> 
> It is important to get as large of a head start on this as
> possible because of how long it takes to deploy something
> like this.

Okay, though I am afraid this space will not be used widely,
we should be ready for it.

I'll make some more comments on the patch itself from
another point view.

--yoshfuji

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 consistent with the Internet Draft
> > draft-fuller-240space-00.txt.
> 
> Wouldn't it be wise to at least wait for it becoming an RFC first? 

I do think so, too.

There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?

We cannot / should not enable that space until we have reached
a consensus on it.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 consistent with the Internet Draft
  draft-fuller-240space-00.txt.
 
 Wouldn't it be wise to at least wait for it becoming an RFC first? 

I do think so, too.

There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?

We cannot / should not enable that space until we have reached
a consensus on it.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, right?
  
  We cannot / should not enable that space until we have reached
  a consensus on it.
 
 This is so incredibly incorrect.
 
 There is consensus on making network stacks able to use this
 address space.  And that is all that the patch does.

No, we did never make consensus on it.

 The consensus is only missing on whether to make the address
 space public or private.
 
 This is also clearly spelled out in the draft.
 
 It is important to get as large of a head start on this as
 possible because of how long it takes to deploy something
 like this.

Okay, though I am afraid this space will not be used widely,
we should be ready for it.

I'll make some more comments on the patch itself from
another point view.

--yoshfuji

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 < timeout)
> > > > +   if (time_before(jiffies, ent->last_usage + timeout))
> > > 
> > > I don't think this is a safe change? subtraction is always safe (if
> > > you think about it as 'distance'), addition isn't always safe unless
> > > you know the range. The time_before macro will expand that out to
> > > (effectively):
> > > 
> > >   if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 )
> > > 
> > > which seems to introduce an overflow condition in the first term.
> > > 
> > > Dunno, I may be wrong (happens often), but at the very least what
> > > you've transformed it into is no longer obviously correct, and so it's
> > > not a great change.
> > 
> > Indeed.  The bottom form will have overflow issues at time
> > jiffies_wraparound/2, whereas the top form will have overflow issues only 
> > near
> > jiffies_wraparound/1.
> 
> OK, so it seems like it is not such a good idea.
> 
> There are, however, over 200 files that contain calls to the various time 
> functions that follow this pattern, eg:
> 
> arch/arm/kernel/ecard.c:563
> if (!last || time_after(jiffies, last + 5*HZ)) {
> 
> Perhaps they should be coverted to use a subtraction as well?

No, use time_after() etc., unless you have very good reason not using them.
And above is not a good reason at all.
Frequency is not a problem.  If we have longer timeout which could
result in wrap-around, we must use another method, e.g. 64bit jiffies,
anyway.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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  timeout)
+   if (time_before(jiffies, ent-last_usage + timeout))
   
   I don't think this is a safe change? subtraction is always safe (if
   you think about it as 'distance'), addition isn't always safe unless
   you know the range. The time_before macro will expand that out to
   (effectively):
   
 if ( (long)(ent-last_usage + timeout) - (long)(jiffies)  0 )
   
   which seems to introduce an overflow condition in the first term.
   
   Dunno, I may be wrong (happens often), but at the very least what
   you've transformed it into is no longer obviously correct, and so it's
   not a great change.
  
  Indeed.  The bottom form will have overflow issues at time
  jiffies_wraparound/2, whereas the top form will have overflow issues only 
  near
  jiffies_wraparound/1.
 
 OK, so it seems like it is not such a good idea.
 
 There are, however, over 200 files that contain calls to the various time 
 functions that follow this pattern, eg:
 
 arch/arm/kernel/ecard.c:563
 if (!last || time_after(jiffies, last + 5*HZ)) {
 
 Perhaps they should be coverted to use a subtraction as well?

No, use time_after() etc., unless you have very good reason not using them.
And above is not a good reason at all.
Frequency is not a problem.  If we have longer timeout which could
result in wrap-around, we must use another method, e.g. 64bit jiffies,
anyway.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 20:38:34.0 +0100
> @@ -91,6 +91,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -4141,8 +4142,9 @@ static void cas_link_timer(unsigned long
>  
>   if (link_transition_timeout != 0 &&
>   cp->link_transition_jiffies_valid &&
> - ((jiffies - cp->link_transition_jiffies) >
> -   (link_transition_timeout))) {
> + (time_after(jiffies,
> + cp->link_transition_jiffies +
> + (link_transition_timeout {
>   /* One-second counter so link-down workaround doesn't
>* cause resets to occur so fast as to fool the switch
>* into thinking the link is down.
> diff -r -u -p a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
> --- a/drivers/net/cs89x0.c2007-10-22 11:25:14.0 +0200
> +++ b/drivers/net/cs89x0.c2007-12-23 20:38:54.0 +0100
> @@ -450,7 +451,7 @@ wait_eeprom_ready(struct net_device *dev
>  just in case EEPROM is ready when SI_BUSY in the
>  PP_SelfST is clear */
>   while(readreg(dev, PP_SelfST) & SI_BUSY)
> - if (jiffies - timeout >= 40)
> + if (time_before_eq(jiffies, timeout + 40))
>   return -1;
>   return 0;
>  }

time_after_eq().

> @@ -1181,10 +1183,10 @@ send_test_pkt(struct net_device *dev)
:

>   break;
> - if (jiffies - timenow >= 5)
> + if (time_before_eq(jiffies, timenow + 5))
>   return 0;   /* this shouldn't happen */
>  
>   /* Write the contents of the packet */

time_after_eq()

> diff -r -u -p a/drivers/net/e1000/e1000_ethtool.c 
> b/drivers/net/e1000/e1000_ethtool.c
> --- a/drivers/net/e1000/e1000_ethtool.c   2007-12-09 09:35:19.0 
> +0100
> +++ b/drivers/net/e1000/e1000_ethtool.c   2007-12-23 20:30:39.0 
> +0100
> @@ -1537,12 +1537,12 @@ e1000_run_loopback_test(struct e1000_ada
:
>   break;
>   }
> - if (jiffies >= (time + 2)) {
> + if (time_before_eq(jiffies, time + 2)) {
>   ret_val = 14; /* error code for time out error */
>   break;
>   }

ditto.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
> +++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23 20:35:37.0 
> +0100
> @@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device
>   }
>  
>   /* Is the mkey in the process of expiring? */
> - if (dev->mkey_lease_timeout && jiffies >= dev->mkey_lease_timeout) {
> + if (dev->mkey_lease_timeout &&
> + time_before_eq(jiffies, dev->mkey_lease_timeout)) {
>   /* Clear timeout and mkey protection field. */
>   dev->mkey_lease_timeout = 0;
>   dev->mkeyprot = 0;

time_after_eq()

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
> +++ b/arch/ia64/sn/kernel/xpc_main.c  2007-12-23 20:32:54.0 +0100
> @@ -230,7 +231,7 @@ xpc_hb_beater(unsigned long dummy)
>  {
>   xpc_vars->heartbeat++;
>  
> - if (jiffies >= xpc_hb_check_timeout) {
> + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
>   wake_up_interruptible(_act_IRQ_wq);
>   }
>  

time_after_eq()

> @@ -270,7 +271,7 @@ xpc_hb_checker(void *ignore)
>  
>  
>   /* checking of remote heartbeats is skewed by IRQ handling */
> - if (jiffies >= xpc_hb_check_timeout) {
> + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
>   dev_dbg(xpc_part, "checking remote heartbeats\n");
>   xpc_check_remote_hb();
>  

ditto.

> @@ -305,7 +306,7 @@ xpc_hb_checker(void *ignore)
>   /* wait for IRQ or timeout */
>   (void) wait_event_interruptible(xpc_act_IRQ_wq,
>   (last_IRQ_count < atomic_read(_act_IRQ_rcvd) ||
> - jiffies >= xpc_hb_check_timeout ||
> +  time_before_eq(jiffies, xpc_hb_check_timeout) ||
>   (volatile int) xpc_exiting));
>   }
>  

ditto.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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.


> - jiffies >= E
> + time_after_eq(jiffies,E)


> diff -r -u -p a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
> --- a/net/decnet/af_decnet.c  2007-11-08 08:00:53.0 +0100
> +++ b/net/decnet/af_decnet.c  2007-12-23 20:30:40.0 +0100
:
> @@ -601,7 +602,7 @@ int dn_destroy_timer(struct sock *sk)
>   if (sk->sk_socket)
>   return 0;
>  
> - if ((jiffies - scp->stamp) >= (HZ * decnet_time_wait)) {
> + if (time_before_eq(jiffies, scp->stamp + HZ * decnet_time_wait)) {
>   dn_unhash_sock(sk);
>   sock_put(sk);
>   return 1;

ugh?

> --- a/net/decnet/dn_timer.c   2006-11-30 19:05:46.0 +0100
> +++ b/net/decnet/dn_timer.c   2007-12-23 20:30:40.0 +0100
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -96,7 +97,7 @@ static void dn_slow_timer(unsigned long 
>* since the last successful transmission.
>*/
>   if (scp->keepalive && scp->keepalive_fxn && (scp->state == DN_RUN)) {
> - if ((jiffies - scp->stamp) >= scp->keepalive)
> + if (time_before_eq(jiffies, scp->stamp + scp->keepalive))
>   scp->keepalive_fxn(sk);
>   }
>  

ugh?

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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.


 - jiffies = E
 + time_after_eq(jiffies,E)


 diff -r -u -p a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
 --- a/net/decnet/af_decnet.c  2007-11-08 08:00:53.0 +0100
 +++ b/net/decnet/af_decnet.c  2007-12-23 20:30:40.0 +0100
:
 @@ -601,7 +602,7 @@ int dn_destroy_timer(struct sock *sk)
   if (sk-sk_socket)
   return 0;
  
 - if ((jiffies - scp-stamp) = (HZ * decnet_time_wait)) {
 + if (time_before_eq(jiffies, scp-stamp + HZ * decnet_time_wait)) {
   dn_unhash_sock(sk);
   sock_put(sk);
   return 1;

ugh?

 --- a/net/decnet/dn_timer.c   2006-11-30 19:05:46.0 +0100
 +++ b/net/decnet/dn_timer.c   2007-12-23 20:30:40.0 +0100
 @@ -21,6 +21,7 @@
  #include linux/netdevice.h
  #include linux/timer.h
  #include linux/spinlock.h
 +#include linux/jiffies.h
  #include net/sock.h
  #include asm/atomic.h
  #include net/flow.h
 @@ -96,7 +97,7 @@ static void dn_slow_timer(unsigned long 
* since the last successful transmission.
*/
   if (scp-keepalive  scp-keepalive_fxn  (scp-state == DN_RUN)) {
 - if ((jiffies - scp-stamp) = scp-keepalive)
 + if (time_before_eq(jiffies, scp-stamp + scp-keepalive))
   scp-keepalive_fxn(sk);
   }
  

ugh?

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
 +++ b/arch/ia64/sn/kernel/xpc_main.c  2007-12-23 20:32:54.0 +0100
 @@ -230,7 +231,7 @@ xpc_hb_beater(unsigned long dummy)
  {
   xpc_vars-heartbeat++;
  
 - if (jiffies = xpc_hb_check_timeout) {
 + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
   wake_up_interruptible(xpc_act_IRQ_wq);
   }
  

time_after_eq()

 @@ -270,7 +271,7 @@ xpc_hb_checker(void *ignore)
  
  
   /* checking of remote heartbeats is skewed by IRQ handling */
 - if (jiffies = xpc_hb_check_timeout) {
 + if (time_before_eq(jiffies, xpc_hb_check_timeout)) {
   dev_dbg(xpc_part, checking remote heartbeats\n);
   xpc_check_remote_hb();
  

ditto.

 @@ -305,7 +306,7 @@ xpc_hb_checker(void *ignore)
   /* wait for IRQ or timeout */
   (void) wait_event_interruptible(xpc_act_IRQ_wq,
   (last_IRQ_count  atomic_read(xpc_act_IRQ_rcvd) ||
 - jiffies = xpc_hb_check_timeout ||
 +  time_before_eq(jiffies, xpc_hb_check_timeout) ||
   (volatile int) xpc_exiting));
   }
  

ditto.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
 +++ b/drivers/infiniband/hw/ipath/ipath_mad.c 2007-12-23 20:35:37.0 
 +0100
 @@ -1334,7 +1334,8 @@ static int process_subn(struct ib_device
   }
  
   /* Is the mkey in the process of expiring? */
 - if (dev-mkey_lease_timeout  jiffies = dev-mkey_lease_timeout) {
 + if (dev-mkey_lease_timeout 
 + time_before_eq(jiffies, dev-mkey_lease_timeout)) {
   /* Clear timeout and mkey protection field. */
   dev-mkey_lease_timeout = 0;
   dev-mkeyprot = 0;

time_after_eq()

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 20:38:34.0 +0100
 @@ -91,6 +91,7 @@
  #include linux/ip.h
  #include linux/tcp.h
  #include linux/mutex.h
 +#include linux/jiffies.h
  
  #include net/checksum.h
  
 @@ -4141,8 +4142,9 @@ static void cas_link_timer(unsigned long
  
   if (link_transition_timeout != 0 
   cp-link_transition_jiffies_valid 
 - ((jiffies - cp-link_transition_jiffies) 
 -   (link_transition_timeout))) {
 + (time_after(jiffies,
 + cp-link_transition_jiffies +
 + (link_transition_timeout {
   /* One-second counter so link-down workaround doesn't
* cause resets to occur so fast as to fool the switch
* into thinking the link is down.
 diff -r -u -p a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
 --- a/drivers/net/cs89x0.c2007-10-22 11:25:14.0 +0200
 +++ b/drivers/net/cs89x0.c2007-12-23 20:38:54.0 +0100
 @@ -450,7 +451,7 @@ wait_eeprom_ready(struct net_device *dev
  just in case EEPROM is ready when SI_BUSY in the
  PP_SelfST is clear */
   while(readreg(dev, PP_SelfST)  SI_BUSY)
 - if (jiffies - timeout = 40)
 + if (time_before_eq(jiffies, timeout + 40))
   return -1;
   return 0;
  }

time_after_eq().

 @@ -1181,10 +1183,10 @@ send_test_pkt(struct net_device *dev)
:

   break;
 - if (jiffies - timenow = 5)
 + if (time_before_eq(jiffies, timenow + 5))
   return 0;   /* this shouldn't happen */
  
   /* Write the contents of the packet */

time_after_eq()

 diff -r -u -p a/drivers/net/e1000/e1000_ethtool.c 
 b/drivers/net/e1000/e1000_ethtool.c
 --- a/drivers/net/e1000/e1000_ethtool.c   2007-12-09 09:35:19.0 
 +0100
 +++ b/drivers/net/e1000/e1000_ethtool.c   2007-12-23 20:30:39.0 
 +0100
 @@ -1537,12 +1537,12 @@ e1000_run_loopback_test(struct e1000_ada
:
   break;
   }
 - if (jiffies = (time + 2)) {
 + if (time_before_eq(jiffies, time + 2)) {
   ret_val = 14; /* error code for time out error */
   break;
   }

ditto.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 
> the most recent one for 2.6.14.  Will more recent ones (for newer 
> kernels) work with my kernel?

It should work; if it doesn't, please make a report.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ip neigh show not showing arp cache entries?

[YOSHIFUJI Hideaki / 吉藤英明]

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 
 the most recent one for 2.6.14.  Will more recent ones (for newer 
 kernels) work with my kernel?

It should work; if it doesn't, please make a report.  Thanks.

--yoshfuji
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

[YOSHIFUJI Hideaki / 吉藤英明]

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 software checksumming 
> > at the lower layers is quite simply a waste of CPU cycles.  Hardware 
> > checksumming is fine, as long as its "free."
> 
> No matter how strong your underlying checksumming is it's not
> going to protect the IPv6 header is it :)

In that sense, we should use AH.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

[YOSHIFUJI Hideaki / 吉藤英明]

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 this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

[YOSHIFUJI Hideaki / 吉藤英明]

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 this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH] SO_NO_CHECK for IPv6

[YOSHIFUJI Hideaki / 吉藤英明]

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 software checksumming 
  at the lower layers is quite simply a waste of CPU cycles.  Hardware 
  checksumming is fine, as long as its free.
 
 No matter how strong your underlying checksumming is it's not
 going to protect the IPv6 header is it :)

In that sense, we should use AH.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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],
> +[0], [1], [2], [3],
> +[4], [5], [6], [7]);
> +

I think you can use in6_pton() here.

> + count = sscanf(cp,
> +NIPQUAD_FMT "-" NIPQUAD_FMT,
> +[0], [1],
> +[2], [3],
> +[0], [1],
> +[2], [3]);
> +

in4_pton().

> +
> +/**
> + * tmy_print_ipv6 - print ipv6 address
> + * @buffer: pointer to buffer to save the result.
> + * @buffer_len: sizeof @buffer .
> + * @ip: pointer to an IPv6 address in network byte order.
> + *
> + * Returns @buffer .
> + */
> +char *tmy_print_ipv6(char *buffer, const int buffer_len, const u16 *ip)
> +{
> + memset(buffer, 0, buffer_len);
> + snprintf(buffer, buffer_len - 1, NIP6_FMT,
> +  ntohs(ip[0]), ntohs(ip[1]), ntohs(ip[2]), ntohs(ip[3]),
> +  ntohs(ip[4]), ntohs(ip[5]), ntohs(ip[6]), ntohs(ip[7]));
> + return buffer;
> +}
> +

snprintf(buffer, buffer_len - 1, NIP6_FMT, NIP6(*(struct in6_addr *)ip));

> + count = sscanf(cp2,
> +NIP6_FMT "-" NIP6_FMT,
> +[0], [1], [2], [3],
> +[4], [5], [6], [7],
> +[0], [1], [2], [3],
> +[4], [5], [6], [7]);
> +

again, in6_pton().

> + count = sscanf(cp2,
> +NIPQUAD_FMT "-" NIPQUAD_FMT,
> +[0], [1], [2], [3],
> +[0], [1], [2], [3]);
> +

in4_pton().

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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],
 +max[0], max[1], max[2], max[3],
 +max[4], max[5], max[6], max[7]);
 +

I think you can use in6_pton() here.

 + count = sscanf(cp,
 +NIPQUAD_FMT - NIPQUAD_FMT,
 +min[0], min[1],
 +min[2], min[3],
 +max[0], max[1],
 +max[2], max[3]);
 +

in4_pton().

 +
 +/**
 + * tmy_print_ipv6 - print ipv6 address
 + * @buffer: pointer to buffer to save the result.
 + * @buffer_len: sizeof @buffer .
 + * @ip: pointer to an IPv6 address in network byte order.
 + *
 + * Returns @buffer .
 + */
 +char *tmy_print_ipv6(char *buffer, const int buffer_len, const u16 *ip)
 +{
 + memset(buffer, 0, buffer_len);
 + snprintf(buffer, buffer_len - 1, NIP6_FMT,
 +  ntohs(ip[0]), ntohs(ip[1]), ntohs(ip[2]), ntohs(ip[3]),
 +  ntohs(ip[4]), ntohs(ip[5]), ntohs(ip[6]), ntohs(ip[7]));
 + return buffer;
 +}
 +

snprintf(buffer, buffer_len - 1, NIP6_FMT, NIP6(*(struct in6_addr *)ip));

 + count = sscanf(cp2,
 +NIP6_FMT - NIP6_FMT,
 +min[0], min[1], min[2], min[3],
 +min[4], min[5], min[6], min[7],
 +max[0], max[1], max[2], max[3],
 +max[4], max[5], max[6], max[7]);
 +

again, in6_pton().

 + count = sscanf(cp2,
 +NIPQUAD_FMT - NIPQUAD_FMT,
 +min[0], min[1], min[2], min[3],
 +max[0], max[1], max[2], max[3]);
 +

in4_pton().

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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]> (at Fri, 26 Oct 2007 15:55:24 +0900), Keiichi 
KII <[EMAIL PROTECTED]> says:

> From: Keiichi Kii <[EMAIL PROTECTED]>
> 
> This patch adds SubmittingPatches translated into Japanese to 
> Documentation/ja_JP directory.
> 
> I attach the patch because there is a possibility that MUA 
> will change the character encoding sometimes.
> 
> Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
> -- 
> Keiichi KII
> NEC Corporation OSS Platform Development Division
> E-mail: [EMAIL PROTECTED] 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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] (at Fri, 26 Oct 2007 15:55:24 +0900), Keiichi 
KII [EMAIL PROTECTED] says:

 From: Keiichi Kii [EMAIL PROTECTED]
 
 This patch adds SubmittingPatches translated into Japanese to 
 Documentation/ja_JP directory.
 
 I attach the patch because there is a possibility that MUA 
 will change the character encoding sometimes.
 
 Signed-off-by: Keiichi KII [EMAIL PROTECTED]
 -- 
 Keiichi KII
 NEC Corporation OSS Platform Development Division
 E-mail: [EMAIL PROTECTED] 
 
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NVIDIA Ethernet & invalid MAC

[YOSHIFUJI Hideaki / 吉藤英明]

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 allocations for 
> >> ethernet
> >> addresses?
> > 
> > We can teach it two ranges. I doubt anyone will be unlucky enough to have
> > the one which could be either Nvidia or Gigabyte and have it matter.
> > 
> > The "go complain to the BIOS vendor" comment from Nvidia to me isn't an
> > answer. Maybe Nvidia can complain to BIOS vendors but end user complaints
> > of that form rarely have any effect.
> 
> That wasn't the point of the response at all.  The datum is that set of 
> users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is vast 
> majority of cases.
> 
> For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR 
> based on DMI strings or a hueristic like you suggested.

I think we could have kernel parameter as well.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NVIDIA Ethernet invalid MAC

[YOSHIFUJI Hideaki / 吉藤英明]

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
  addresses?
  
  We can teach it two ranges. I doubt anyone will be unlucky enough to have
  the one which could be either Nvidia or Gigabyte and have it matter.
  
  The go complain to the BIOS vendor comment from Nvidia to me isn't an
  answer. Maybe Nvidia can complain to BIOS vendors but end user complaints
  of that form rarely have any effect.
 
 That wasn't the point of the response at all.  The datum is that set of 
 users where DEV_HAS_CORRECT_MACADDR is accurately set or clear is vast 
 majority of cases.
 
 For the rest, we'll want to look at adjusting DEV_HAS_CORRECT_MACADDR 
 based on DMI strings or a hueristic like you suggested.

I think we could have kernel parameter as well.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 iteration + concurrent removal scenario:
> Regarding my singly-linked list, no entries are removed from the list. It's 
> append only (like CD-R media).
> I set is_deleted flag of a entry instead of removing the entry from the list.

It is not a good practice.  Please free such objects.
BTW, how many objects do you have in the list?

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, ptr->next is assigned non-NULL address.
> (3) Assigning to ptr->next is done atomically.

RCU?

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 well-known.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 well-known.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, ptr-next is assigned non-NULL address.
 (3) Assigning to ptr-next is done atomically.

RCU?

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 iteration + concurrent removal scenario:
 Regarding my singly-linked list, no entries are removed from the list. It's 
 append only (like CD-R media).
 I set is_deleted flag of a entry instead of removing the entry from the list.

It is not a good practice.  Please free such objects.
BTW, how many objects do you have in the list?

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 reduce memory usage, I dare not use these API.
> Singly-linked list's rule in TOMOYO Linux is quite simple,
> "ptr->next is NULL if the last element" and "non-NULL if not".

Introducing your own list is not good.
Please use hlist or introduce new "slist".

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 reduce memory usage, I dare not use these API.
 Singly-linked list's rule in TOMOYO Linux is quite simple,
 ptr-next is NULL if the last element and non-NULL if not.

Introducing your own list is not good.
Please use hlist or introduce new slist.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, the following patch
> >   will fix this.
> > 
> >   I don't understand why we must use rt->rt_src in the current
> >   code, if this is a wrong fix, please correct me.
> > 
> > Signed-off-by: Lepton Wu <[EMAIL PROTECTED]>
> 
> That the address is wrong is your opinion only :-)
> 
> Source address selection is a rather complex topic, and
> here we are definitely purposefully using the source
> address selected by the routing lookup for the reply.

And, if you do think something is "wrong", you need to describe it
in detail, at least.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, the following patch
will fix this.
  
I don't understand why we must use rt-rt_src in the current
code, if this is a wrong fix, please correct me.
  
  Signed-off-by: Lepton Wu [EMAIL PROTECTED]
 
 That the address is wrong is your opinion only :-)
 
 Source address selection is a rather complex topic, and
 here we are definitely purposefully using the source
 address selected by the routing lookup for the reply.

And, if you do think something is wrong, you need to describe it
in detail, at least.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 to 
> report the data to the caller of sys_sysctl.

I assume that default strategy have been existing for it, no?!
Maybe, I do miss something...

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
retrans_time and base_reachable_time, we've warned for long
time for its deprecation.  So, maybe, it is time to remove
the old interfaces (retrans_time and base_reachable_time)
and simplify ndisc_ifinfo_syctl_change().

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 think perhaps you misunderstand what Eric is doing.
> 
> sys_sysctl() isn't working properly for these cases and it is both a
> deprecated interface and not worth the pain of adding support
> in these cases.

Would you explain why it does not work properly
for those cases?

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 being used in the stable
> kernel.  I certainly can't seem to fix the problems as fast as
> they are introduced.
:
> The biggest part of the code is the table of valid binary sysctl
> entries, but since we have frozen our set of binary sysctls this table
> should not need to change, and it makes it much easier to detect
> when someone unintentionally adds a new binary sysctl value.

I don't think everyone needs to have this code, so
it is better to make it configurable via
CONFIG_SYSCTL_DEBUG or something..., ...no?

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 possibly unused entries
>   at the end so we can remove them by terminating the table early.
> 
> - In neighbour.c kill the entries with questionable binary sysctl
>   handling behavior.
> 
> - In neighbour.c if we don't have a strategy routine remove the
>   binary path.  So we don't the default sysctl strategy routine
>   on data that is not ready for it.
> 

I disagree.  It is bad to remove existing interface.
Ditto for other patches.

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 possibly unused entries
   at the end so we can remove them by terminating the table early.
 
 - In neighbour.c kill the entries with questionable binary sysctl
   handling behavior.
 
 - In neighbour.c if we don't have a strategy routine remove the
   binary path.  So we don't the default sysctl strategy routine
   on data that is not ready for it.
 

I disagree.  It is bad to remove existing interface.
Ditto for other patches.

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 to 
 report the data to the caller of sys_sysctl.

I assume that default strategy have been existing for it, no?!
Maybe, I do miss something...

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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
retrans_time and base_reachable_time, we've warned for long
time for its deprecation.  So, maybe, it is time to remove
the old interfaces (retrans_time and base_reachable_time)
and simplify ndisc_ifinfo_syctl_change().

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 being used in the stable
 kernel.  I certainly can't seem to fix the problems as fast as
 they are introduced.
:
 The biggest part of the code is the table of valid binary sysctl
 entries, but since we have frozen our set of binary sysctls this table
 should not need to change, and it makes it much easier to detect
 when someone unintentionally adds a new binary sysctl value.

I don't think everyone needs to have this code, so
it is better to make it configurable via
CONFIG_SYSCTL_DEBUG or something..., ...no?

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 think perhaps you misunderstand what Eric is doing.
 
 sys_sysctl() isn't working properly for these cases and it is both a
 deprecated interface and not worth the pain of adding support
 in these cases.

Would you explain why it does not work properly
for those cases?

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 would say, it would be better to add IPV6_ADDR_UNICAST as well
for "reserved" addresses unless we have good reason not to do it,
anyway.

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 after the ACPI preparation for
> powering the system off.  To make it happen, we can separate sysdev_shutdown()
> from device_shutdown() and call it directly wherever necessary.
> 
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 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 is to blame,
> > > > and by reverting that commit, it works appropriately.
> > > 
> > > (1) Can you please apply the appended patch and see if the message gets
> > > printed when you try to power off the system?
> > 
> > Yup, I got it.  Last lines are:
:
> Can you please check if the appended patch helps?

Yes, it definitely does.  Thank you.

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 would say, it would be better to add IPV6_ADDR_UNICAST as well
for reserved addresses unless we have good reason not to do it,
anyway.

-- 
YOSHIFUJI Hideaki @ USAGI Project  [EMAIL PROTECTED]
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 after the ACPI preparation for
 powering the system off.  To make it happen, we can separate sysdev_shutdown()
 from device_shutdown() and call it directly wherever necessary.
 
 Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 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 is to blame,
and by reverting that commit, it works appropriately.
   
   (1) Can you please apply the appended patch and see if the message gets
   printed when you try to power off the system?
  
  Yup, I got it.  Last lines are:
:
 Can you please check if the appended patch helps?

Yes, it definitely does.  Thank you.

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 is to blame,
> > and by reverting that commit, it works appropriately.
> 
> (1) Can you please apply the appended patch and see if the message gets
> printed when you try to power off the system?

Yup, I got it.  Last lines are:

| Shutdown: hda
| ACPI: PCI interrupt for device :02:02.0 disabled
| ACPI: PCI interrupt for device :02:01.0 disabled
| ACPI: Preparing to power off the system

> (2) Can you please post your .config? 

Attached.

Regards,

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 02:01:42 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 is to blame,
  and by reverting that commit, it works appropriately.
 
 (1) Can you please apply the appended patch and see if the message gets
 printed when you try to power off the system?

Yup, I got it.  Last lines are:

| Shutdown: hda
| ACPI: PCI interrupt for device :02:02.0 disabled
| ACPI: PCI interrupt for device :02:01.0 disabled
| ACPI: Preparing to power off the system

 (2) Can you please post your .config? 

Attached.

Regards,

-- 
YOSHIFUJI Hideaki @ USAGI Project  [EMAIL PROTECTED]
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc1
# Mon Jul 23 02:01:42 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CPUSETS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 bd804eba1c8597cbb7cd5a5f9fe886aae16a079a
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date:   Thu Jul 19 01:47:40 2007 -0700

PM: Introduce pm_power_off_prepare

Introduce the pm_power_off_prepare() callback that can be registered by the
interested platforms in analogy with pm_idle() and pm_power_off(), used for
preparing the system to power off (needed by ACPI).

This allows us to drop acpi_sysclass and device_acpi that are only defined 
in
order to register the ACPI power off preparation callback, which is needed 
by
pm_power_off() registered in a much different way.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

:04 04 624870eb14bf9841fa2dca2cf13cc4c9a0479005 
af79f843f3383bbecaed84d493926939cf0e1c12 M  drivers
:04 04 9b28a21970668ce133916bbe8d8fd4a61bce23d7 
80fc84d7982369205dcf94029e3958c90db14bf0 M  include
:04 04 9ce5c8b5d3f87c121b2f7bc6e02bc814648a2739 
2e2e1468dfa0db9dee5bd204fd3f802a975a6454 M  kernel

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 bd804eba1c8597cbb7cd5a5f9fe886aae16a079a
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date:   Thu Jul 19 01:47:40 2007 -0700

PM: Introduce pm_power_off_prepare

Introduce the pm_power_off_prepare() callback that can be registered by the
interested platforms in analogy with pm_idle() and pm_power_off(), used for
preparing the system to power off (needed by ACPI).

This allows us to drop acpi_sysclass and device_acpi that are only defined 
in
order to register the ACPI power off preparation callback, which is needed 
by
pm_power_off() registered in a much different way.

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

:04 04 624870eb14bf9841fa2dca2cf13cc4c9a0479005 
af79f843f3383bbecaed84d493926939cf0e1c12 M  drivers
:04 04 9b28a21970668ce133916bbe8d8fd4a61bce23d7 
80fc84d7982369205dcf94029e3958c90db14bf0 M  include
:04 04 9ce5c8b5d3f87c121b2f7bc6e02bc814648a2739 
2e2e1468dfa0db9dee5bd204fd3f802a975a6454 M  kernel

-- 
YOSHIFUJI Hideaki @ USAGI Project  [EMAIL PROTECTED]
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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  = tcp_sendpage,
> + .splice_read   = tcp_splice_read,
>  #ifdef CONFIG_COMPAT
>   .compat_setsockopt = compat_sock_common_setsockopt,
>   .compat_getsockopt = compat_sock_common_getsockopt,

Please add similar bits in net/ipv6/af_inet6.c
unless there are any dependency on IPv4.
(And if there are, it is not good.)

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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  = tcp_sendpage,
 + .splice_read   = tcp_splice_read,
  #ifdef CONFIG_COMPAT
   .compat_setsockopt = compat_sock_common_setsockopt,
   .compat_getsockopt = compat_sock_common_getsockopt,

Please add similar bits in net/ipv6/af_inet6.c
unless there are any dependency on IPv4.
(And if there are, it is not good.)

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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", dev->name);
> + sysctl = bfin_read_EMAC_OPMODE();
> + sysctl |= RAF;
> + bfin_write_EMAC_OPMODE(sysctl);
> + } else if (dev->flags & IFF_ALLMULTI || dev->mc_count > 16) {
> + /* accept all multicast */
> + sysctl = bfin_read_EMAC_OPMODE();
> + sysctl |= PAM;
> + bfin_write_EMAC_OPMODE(sysctl);
> + } else if (dev->mc_count) {
> + /* set multicast */
> + } else {
> + /* clear promisc or multicast mode */
> + sysctl = bfin_read_EMAC_OPMODE();
> + sysctl &= ~(RAF | PAM);
> + bfin_write_EMAC_OPMODE(sysctl);
> + }
> +}
> +

Is this function really correct?

Please make sure to set up multicast list on device, or
set "all multi" on device if you do not know what to do; e.g.

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", dev->name);
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl |= RAF;
 bfin_write_EMAC_OPMODE(sysctl);
 } else if (dev->flags & IFF_ALLMULTI || dev->mc_count) {
 /* accept all multicast */
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl |= PAM;
 bfin_write_EMAC_OPMODE(sysctl);
 } else {
 /* clear promisc or multicast mode */
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl &= ~(RAF | PAM);
 bfin_write_EMAC_OPMODE(sysctl);
 }
}
--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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, dev-name);
 + sysctl = bfin_read_EMAC_OPMODE();
 + sysctl |= RAF;
 + bfin_write_EMAC_OPMODE(sysctl);
 + } else if (dev-flags  IFF_ALLMULTI || dev-mc_count  16) {
 + /* accept all multicast */
 + sysctl = bfin_read_EMAC_OPMODE();
 + sysctl |= PAM;
 + bfin_write_EMAC_OPMODE(sysctl);
 + } else if (dev-mc_count) {
 + /* set multicast */
 + } else {
 + /* clear promisc or multicast mode */
 + sysctl = bfin_read_EMAC_OPMODE();
 + sysctl = ~(RAF | PAM);
 + bfin_write_EMAC_OPMODE(sysctl);
 + }
 +}
 +

Is this function really correct?

Please make sure to set up multicast list on device, or
set all multi on device if you do not know what to do; e.g.

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, dev-name);
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl |= RAF;
 bfin_write_EMAC_OPMODE(sysctl);
 } else if (dev-flags  IFF_ALLMULTI || dev-mc_count) {
 /* accept all multicast */
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl |= PAM;
 bfin_write_EMAC_OPMODE(sysctl);
 } else {
 /* clear promisc or multicast mode */
 sysctl = bfin_read_EMAC_OPMODE();
 sysctl = ~(RAF | PAM);
 bfin_write_EMAC_OPMODE(sysctl);
 }
}
--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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]> 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.
> 
> It's better than having to check it all the time in the caller :)

How many callers do we have that will get benefit from this change?

Well, the change will hide the bug. It seems all callers in fs/sysfs
already assume that the argument is NOT NULL, and it is a bug to call
sysfs_put() with NULL; the function should be used to "put" something
you "have" (non-NULL). If it is called with NULL, I would say, we
should BUG here to detect the logical bug.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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 unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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] 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.
 
 It's better than having to check it all the time in the caller :)

How many callers do we have that will get benefit from this change?

Well, the change will hide the bug. It seems all callers in fs/sysfs
already assume that the argument is NOT NULL, and it is a bug to call
sysfs_put() with NULL; the function should be used to put something
you have (non-NULL). If it is called with NULL, I would say, we
should BUG here to detect the logical bug.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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);
if (!(set = inode->i_private)) {
if (!(set = inode->i_private = kmalloc(sizeof(struct 
sysfs_buffer_collection), GFP_KERNEL))) {
+   mutex_unlock(>i_mutex);
error = -ENOMEM;
goto Done;
} else {

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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);
if (!(set = inode-i_private)) {
if (!(set = inode-i_private = kmalloc(sizeof(struct 
sysfs_buffer_collection), GFP_KERNEL))) {
+   mutex_unlock(inode-i_mutex);
error = -ENOMEM;
goto Done;
} else {

-- 
YOSHIFUJI Hideaki @ USAGI Project  [EMAIL PROTECTED]
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: TCP_MD5 and Intel e1000

[YOSHIFUJI Hideaki / 吉藤英明]

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.
> > If i run tcpdump on the mashine the packets are generated, it shows on the
> > outgoing interface invalid md5 digests.
> > Are there known issues about tcp-md5 and e1000 NICs?
:
> You could try "ethtool -K tx off", and/or other ethtool -K settings

Disabling offloading should help; currently tcp-md5 stack
blindly copy md5-signature from the first segment
which is not appropriate for rest of segments.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: TCP_MD5 and Intel e1000

[YOSHIFUJI Hideaki / 吉藤英明]

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.
  If i run tcpdump on the mashine the packets are generated, it shows on the
  outgoing interface invalid md5 digests.
  Are there known issues about tcp-md5 and e1000 NICs?
:
 You could try ethtool -K tx off, and/or other ethtool -K settings

Disabling offloading should help; currently tcp-md5 stack
blindly copy md5-signature from the first segment
which is not appropriate for rest of segments.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-2.6.21-gitN - versioning question

[YOSHIFUJI Hideaki / 吉藤英明]

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 
> http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.bz2
> but where do I actually find -git16 in Linus's git tree? git16 is 
> neither a branch nor a tag.

http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.id
tells the commit in his tree.

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-2.6.21-gitN - versioning question

[YOSHIFUJI Hideaki / 吉藤英明]

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 
 http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.bz2
 but where do I actually find -git16 in Linus's git tree? git16 is 
 neither a branch nor a tag.

http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git16.id
tells the commit in his tree.

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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':
> arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
> 'constant_test_bit' from incompatible pointer type
> arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
> 'variable_test_bit' from incompatible pointer type
:
> diff -puN 
> arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation 
> arch/i386/kernel/nmi.c
> --- 
> a/arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation
> +++ a/arch/i386/kernel/nmi.c
> @@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
>   int cpu;
>   BUG_ON(counter > NMI_MAX_COUNTER_BITS);
>   for_each_possible_cpu (cpu) {
> - if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
> + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
>   return 0;
>   }
>   return 1;
:
> 
> I worry rather a lot about how well runtime tested this very late change
> was, and whether it works correctly even with this fix applied.  Perhaps
> we should jsut revert?

Is DEFINE_PER_CPU(type, var[num]) is really valid?
I guess it should be DEFINE_PER_CPU(type[num], var), no?


[I386] NMI: Fix per_cpu() usage.

Per-cpu array should be declared as DEFINE_PER_CPU(type[size], name),
not as DEFINE_PER_CPU(type, name[size]).

Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>

diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c
index 9f1e8c1..eddb4f7 100644
--- a/arch/i386/kernel/nmi.c
+++ b/arch/i386/kernel/nmi.c
@@ -48,8 +48,8 @@ int nmi_watchdog_enabled;
 #define NMI_MAX_COUNTER_BITS 66
 #define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS)
 
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
perfctr_nmi_owner);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
evntsel_nmi_owner);
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 /* nmi_active:
@@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
int cpu;
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -142,7 +142,7 @@ int avail_to_resrv_perfctr_nmi(unsigned int msr)
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -157,7 +157,7 @@ static int __reserve_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, _cpu(perfctr_nmi_owner, cpu)))
+   if (!test_and_set_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -171,7 +171,7 @@ static void __release_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, _cpu(perfctr_nmi_owner, cpu));
+   clear_bit(counter, per_cpu(perfctr_nmi_owner, cpu));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -207,7 +207,7 @@ int __reserve_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, _cpu(evntsel_nmi_owner, cpu)[0]))
+   if (!test_and_set_bit(counter, per_cpu(evntsel_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -221,7 +221,7 @@ static void __release_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter > NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, _cpu(evntsel_nmi_owner, cpu)[0]);
+   clear_bit(counter, per_cpu(evntsel_nmi_owner, cpu));
 }
 
 int reserve_evntsel_nmi(unsigned int msr)

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[EMAIL PROTECTED]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[YOSHIFUJI Hideaki / 吉藤英明]

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':
 arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
 'constant_test_bit' from incompatible pointer type
 arch/i386/kernel/nmi.c:129: warning: passing argument 2 of 
 'variable_test_bit' from incompatible pointer type
:
 diff -puN 
 arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation 
 arch/i386/kernel/nmi.c
 --- 
 a/arch/i386/kernel/nmi.c~fix-x86-fix-potential-overflow-in-perfctr-reservation
 +++ a/arch/i386/kernel/nmi.c
 @@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsig
   int cpu;
   BUG_ON(counter  NMI_MAX_COUNTER_BITS);
   for_each_possible_cpu (cpu) {
 - if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
 + if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
   return 0;
   }
   return 1;
:
 
 I worry rather a lot about how well runtime tested this very late change
 was, and whether it works correctly even with this fix applied.  Perhaps
 we should jsut revert?

Is DEFINE_PER_CPU(type, var[num]) is really valid?
I guess it should be DEFINE_PER_CPU(type[num], var), no?


[I386] NMI: Fix per_cpu() usage.

Per-cpu array should be declared as DEFINE_PER_CPU(type[size], name),
not as DEFINE_PER_CPU(type, name[size]).

Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]

diff --git a/arch/i386/kernel/nmi.c b/arch/i386/kernel/nmi.c
index 9f1e8c1..eddb4f7 100644
--- a/arch/i386/kernel/nmi.c
+++ b/arch/i386/kernel/nmi.c
@@ -48,8 +48,8 @@ int nmi_watchdog_enabled;
 #define NMI_MAX_COUNTER_BITS 66
 #define NMI_MAX_COUNTER_LONGS BITS_TO_LONGS(NMI_MAX_COUNTER_BITS)
 
-static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner[NMI_MAX_COUNTER_LONGS]);
-static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[NMI_MAX_COUNTER_LONGS]);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
perfctr_nmi_owner);
+static DEFINE_PER_CPU(unsigned long [NMI_MAX_COUNTER_LONGS], 
evntsel_nmi_owner);
 
 static cpumask_t backtrace_mask = CPU_MASK_NONE;
 /* nmi_active:
@@ -126,7 +126,7 @@ int avail_to_resrv_perfctr_nmi_bit(unsigned int counter)
int cpu;
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -142,7 +142,7 @@ int avail_to_resrv_perfctr_nmi(unsigned int msr)
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
 
for_each_possible_cpu (cpu) {
-   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
+   if (test_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 0;
}
return 1;
@@ -157,7 +157,7 @@ static int __reserve_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
+   if (!test_and_set_bit(counter, per_cpu(perfctr_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -171,7 +171,7 @@ static void __release_perfctr_nmi(int cpu, unsigned int msr)
counter = nmi_perfctr_msr_to_bit(msr);
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, per_cpu(perfctr_nmi_owner, cpu));
+   clear_bit(counter, per_cpu(perfctr_nmi_owner, cpu));
 }
 
 int reserve_perfctr_nmi(unsigned int msr)
@@ -207,7 +207,7 @@ int __reserve_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
 
-   if (!test_and_set_bit(counter, per_cpu(evntsel_nmi_owner, cpu)[0]))
+   if (!test_and_set_bit(counter, per_cpu(evntsel_nmi_owner, cpu)))
return 1;
return 0;
 }
@@ -221,7 +221,7 @@ static void __release_evntsel_nmi(int cpu, unsigned int msr)
counter = nmi_evntsel_msr_to_bit(msr);
BUG_ON(counter  NMI_MAX_COUNTER_BITS);
 
-   clear_bit(counter, per_cpu(evntsel_nmi_owner, cpu)[0]);
+   clear_bit(counter, per_cpu(evntsel_nmi_owner, cpu));
 }
 
 int reserve_evntsel_nmi(unsigned int msr)

-- 
YOSHIFUJI Hideaki @ USAGI Project  [EMAIL PROTECTED]
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPv6: Connection reset/timeout under heavy load

[YOSHIFUJI Hideaki / 吉藤英明]

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 2.6.16-stable...
> 
> Please forward this patch to Adrian Bunk ([EMAIL PROTECTED]),
> he will definitely add it to 2.6.16-stable for you.

I will do it again...

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPv6: Connection reset/timeout under heavy load

[YOSHIFUJI Hideaki / 吉藤英明]

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 the following change will fix the issue for 2.6.16.y:
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 2.6.16-stable...

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IPv6: Connection reset/timeout under heavy load

[YOSHIFUJI Hideaki / 吉藤英明]

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 the following change will fix the issue for 2.6.16.y:
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 2.6.16-stable...

Regards,

--yoshfuji
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/