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/addrlabel: fix ip6addrlbl_get()

[YOSHIFUJI Hideaki]

Cong Wang wrote:
> On Mon, Dec 21, 2015 at 1:54 AM, Andrey Ryabinin
>  wrote:
>> ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
>> ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
>> ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>>
>> Fix this by inverting ip6addrlbl_hold() check.
>>
>> Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address 
>> selection policy table.")
>> Signed-off-by: Andrey Ryabinin 
> 
> Good catch!
> 
> Reviewed-by: Cong Wang 
Acked-by: YOSHIFUJI Hideaki 

-- 
Hideaki Yoshifuji 
Technical Division, MIRACLE LINUX CORPORATION
--
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] ipv6/addrlabel: fix ip6addrlbl_get()

[YOSHIFUJI Hideaki]

Cong Wang wrote:
> On Mon, Dec 21, 2015 at 1:54 AM, Andrey Ryabinin
> <aryabi...@virtuozzo.com> wrote:
>> ip6addrlbl_get() has never worked. If ip6addrlbl_hold() succeeded,
>> ip6addrlbl_get() will exit with '-ESRCH'. If ip6addrlbl_hold() failed,
>> ip6addrlbl_get() will use about to be free ip6addrlbl_entry pointer.
>>
>> Fix this by inverting ip6addrlbl_hold() check.
>>
>> Fixes: 2a8cc6c89039 ("[IPV6] ADDRCONF: Support RFC3484 configurable address 
>> selection policy table.")
>> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com>
> 
> Good catch!
> 
> Reviewed-by: Cong Wang <cw...@twopensource.com>
Acked-by: YOSHIFUJI Hideaki <yoshf...@linux-ipv6.org>

-- 
Hideaki Yoshifuji <hideaki.yoshif...@miraclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION
--
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] 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 4/9 net-next] ipv6: replace if/BUG by BUG_ON

[YOSHIFUJI Hideaki]

Hi,

Fabian Frederick wrote:
> Signed-off-by: Fabian Frederick 
> ---
>  net/ipv6/addrconf.c | 3 +--
>  net/ipv6/esp6.c | 3 +--
>  net/ipv6/netfilter/nf_conntrack_reasm.c | 3 +--
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 2660263..e205918 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -4805,8 +4805,7 @@ static int inet6_set_link_af(struct net_device *dev, 
> const struct nlattr *nla)
>   if (!idev)
>   return -EAFNOSUPPORT;
>  
> - if (nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0)
> - BUG();
> + BUG_ON(nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0);
>  

NACK, I do not prefer using BUG_ON() with side effects.

--yoshfuji

>   if (tb[IFLA_INET6_TOKEN]) {
>   err = inet6_set_iftoken(idev, nla_data(tb[IFLA_INET6_TOKEN]));
> diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
> index e48f2c7..9e51b69 100644
> --- a/net/ipv6/esp6.c
> +++ b/net/ipv6/esp6.c
> @@ -280,8 +280,7 @@ static int esp_input_done2(struct sk_buff *skb, int err)
>   if (unlikely(err))
>   goto out;
>  
> - if (skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2));
>  
>   err = -EINVAL;
>   padlen = nexthdr[0];
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c 
> b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 6f187c8..cea1a4a 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -538,8 +538,7 @@ find_prev_fhdr(struct sk_buff *skb, u8 *prevhdrp, int 
> *prevhoff, int *fhoff)
>   pr_debug("too short\n");
>   return -1;
>   }
> - if (skb_copy_bits(skb, start, , sizeof(hdr)))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, start, , sizeof(hdr)));
>   if (nexthdr == NEXTHDR_AUTH)
>   hdrlen = (hdr.hdrlen+2)<<2;
>   else
> 

-- 
Hideaki Yoshifuji 
Technical Division, MIRACLE LINUX CORPORATION
--
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 4/9 net-next] ipv6: replace if/BUG by BUG_ON

[YOSHIFUJI Hideaki]

Hi,

Fabian Frederick wrote:
 Signed-off-by: Fabian Frederick f...@skynet.be
 ---
  net/ipv6/addrconf.c | 3 +--
  net/ipv6/esp6.c | 3 +--
  net/ipv6/netfilter/nf_conntrack_reasm.c | 3 +--
  3 files changed, 3 insertions(+), 6 deletions(-)
 
 diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
 index 2660263..e205918 100644
 --- a/net/ipv6/addrconf.c
 +++ b/net/ipv6/addrconf.c
 @@ -4805,8 +4805,7 @@ static int inet6_set_link_af(struct net_device *dev, 
 const struct nlattr *nla)
   if (!idev)
   return -EAFNOSUPPORT;
  
 - if (nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL)  0)
 - BUG();
 + BUG_ON(nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL)  0);
  

NACK, I do not prefer using BUG_ON() with side effects.

--yoshfuji

   if (tb[IFLA_INET6_TOKEN]) {
   err = inet6_set_iftoken(idev, nla_data(tb[IFLA_INET6_TOKEN]));
 diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
 index e48f2c7..9e51b69 100644
 --- a/net/ipv6/esp6.c
 +++ b/net/ipv6/esp6.c
 @@ -280,8 +280,7 @@ static int esp_input_done2(struct sk_buff *skb, int err)
   if (unlikely(err))
   goto out;
  
 - if (skb_copy_bits(skb, skb-len - alen - 2, nexthdr, 2))
 - BUG();
 + BUG_ON(skb_copy_bits(skb, skb-len - alen - 2, nexthdr, 2));
  
   err = -EINVAL;
   padlen = nexthdr[0];
 diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c 
 b/net/ipv6/netfilter/nf_conntrack_reasm.c
 index 6f187c8..cea1a4a 100644
 --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
 +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
 @@ -538,8 +538,7 @@ find_prev_fhdr(struct sk_buff *skb, u8 *prevhdrp, int 
 *prevhoff, int *fhoff)
   pr_debug(too short\n);
   return -1;
   }
 - if (skb_copy_bits(skb, start, hdr, sizeof(hdr)))
 - BUG();
 + BUG_ON(skb_copy_bits(skb, start, hdr, sizeof(hdr)));
   if (nexthdr == NEXTHDR_AUTH)
   hdrlen = (hdr.hdrlen+2)2;
   else
 

-- 
Hideaki Yoshifuji hideaki.yoshif...@miraclelinux.com
Technical Division, MIRACLE LINUX CORPORATION
--
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 net v2] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments

[YOSHIFUJI Hideaki]

Hi,

Rahul Sharma wrote:

ipv6_find_hdr() currently assumes that the next-header field in the
fragment header of the non-first fragment is the "protocol number of
the last header" (here last header excludes any extension header
protocol numbers ) which is incorrect as per RFC2460. The next-header
value is the first header of the fragmentable part of the original
packet (which can be extension header as well).
This can create reassembly problems. For example: Fragmented
authenticated OSPFv3 packets (where AH header is inserted before the
protocol header). For the second fragment, the next header value in
the fragment header will be NEXTHDR_AUTH which is correct but
ipv6_find_hdr will return ENOENT since AH is an extension header
resulting in second fragment getting dropped. This check for the
presence of non-extension header needs to be removed.

Signed-off-by: Rahul Sharma 


Acked-by: YOSHIFUJI Hideaki 

--
Hideaki Yoshifuji 
Technical Division, MIRACLE LINUX CORPORATION
--
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 net v2] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments

[YOSHIFUJI Hideaki]

Hi,

Rahul Sharma wrote:

ipv6_find_hdr() currently assumes that the next-header field in the
fragment header of the non-first fragment is the protocol number of
the last header (here last header excludes any extension header
protocol numbers ) which is incorrect as per RFC2460. The next-header
value is the first header of the fragmentable part of the original
packet (which can be extension header as well).
This can create reassembly problems. For example: Fragmented
authenticated OSPFv3 packets (where AH header is inserted before the
protocol header). For the second fragment, the next header value in
the fragment header will be NEXTHDR_AUTH which is correct but
ipv6_find_hdr will return ENOENT since AH is an extension header
resulting in second fragment getting dropped. This check for the
presence of non-extension header needs to be removed.

Signed-off-by: Rahul Sharma rsha...@arista.com


Acked-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org

--
Hideaki Yoshifuji hideaki.yoshif...@miraclelinux.com
Technical Division, MIRACLE LINUX CORPORATION
--
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/4] tun: Use iovec iterators

[YOSHIFUJI Hideaki]

Hi,

Herbert Xu wrote:

Oops, this patch had a left-over skb_pull which made it broken.
Here is a fixed version.

tun: Use iovec iterators

This patch removes the use of skb_copy_datagram_const_iovec in
favour of the iovec iterator-based skb_copy_datagram_iter.

Signed-off-by: Herbert Xu 

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9dd3746..ff955cdb 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c

:

@@ -1244,23 +1245,25 @@ static ssize_t tun_put_user(struct tun_struct *tun,
if (tun->flags & TUN_VNET_HDR)
vnet_hdr_sz = tun->vnet_hdr_sz;

+   total = skb->len + vlan_hlen + vnet_hdr_sz;
+
if (!(tun->flags & TUN_NO_PI)) {
-   if ((len -= sizeof(pi)) < 0)
+   if (iov_iter_count(iter) < sizeof(pi))
return -EINVAL;

-   if (len < skb->len + vlan_hlen + vnet_hdr_sz) {
+   if (iov_iter_count(iter) < total) {


I guess this should be: sizeof(pi) + total

--
Hideaki Yoshifuji 
Technical Division, MIRACLE LINUX CORPORATION
--
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/4] tun: Use iovec iterators

[YOSHIFUJI Hideaki]

Hi,

Herbert Xu wrote:

Oops, this patch had a left-over skb_pull which made it broken.
Here is a fixed version.

tun: Use iovec iterators

This patch removes the use of skb_copy_datagram_const_iovec in
favour of the iovec iterator-based skb_copy_datagram_iter.

Signed-off-by: Herbert Xu herb...@gondor.apana.org.au

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 9dd3746..ff955cdb 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c

:

@@ -1244,23 +1245,25 @@ static ssize_t tun_put_user(struct tun_struct *tun,
if (tun-flags  TUN_VNET_HDR)
vnet_hdr_sz = tun-vnet_hdr_sz;

+   total = skb-len + vlan_hlen + vnet_hdr_sz;
+
if (!(tun-flags  TUN_NO_PI)) {
-   if ((len -= sizeof(pi))  0)
+   if (iov_iter_count(iter)  sizeof(pi))
return -EINVAL;

-   if (len  skb-len + vlan_hlen + vnet_hdr_sz) {
+   if (iov_iter_count(iter)  total) {


I guess this should be: sizeof(pi) + total

--
Hideaki Yoshifuji hideaki.yoshif...@miraclelinux.com
Technical Division, MIRACLE LINUX CORPORATION
--
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/

[PATCH] isdnloop: Validate NUL-terminated strings from user.

[YOSHIFUJI Hideaki]

Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.

Signed-off-by: YOSHIFUJI Hideaki 
---
 drivers/isdn/isdnloop/isdnloop.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/isdn/isdnloop/isdnloop.c b/drivers/isdn/isdnloop/isdnloop.c
index 02125e6..e1f8748 100644
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -1070,6 +1070,12 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef *sdefp)
return -EBUSY;
if (copy_from_user((char *) , (char *) sdefp, sizeof(sdef)))
return -EFAULT;
+
+   for (i = 0; i < 3; i++) {
+   if (!memchr(sdef.num[i], 0, sizeof(sdef.num[i])))
+   return -EINVAL;
+   }
+
spin_lock_irqsave(>isdnloop_lock, flags);
switch (sdef.ptype) {
case ISDN_PTYPE_EURO:
-- 
1.7.9.5

--
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] isdnloop: NUL-terminate strings from userspace

[YOSHIFUJI Hideaki]

Vegard Nossum wrote:
> Both the in-kernel and BSD strlcpy() require that the source string is
> NUL terminated. We could use strncpy() + explicitly terminate the result,
> but this relies on src and dest having the same size, so the safest thing
> to do seems to explicitly terminate the source string before doing the
> strlcpy().
:
> diff --git a/drivers/isdn/isdnloop/isdnloop.c 
> b/drivers/isdn/isdnloop/isdnloop.c
> index 02125e6..50cd348 100644
> --- a/drivers/isdn/isdnloop/isdnloop.c
> +++ b/drivers/isdn/isdnloop/isdnloop.c
> @@ -1070,6 +1070,14 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef 
> *sdefp)
>   return -EBUSY;
>   if (copy_from_user((char *) , (char *) sdefp, sizeof(sdef)))
>   return -EFAULT;
> +
> + /*
> +  * Null terminate strings from userspace so we don't have to worry
> +  * about this later on.
> +  */
> + for (i = 0; i < 3; i++)
> + sdef.num[i][sizeof(sdef.num[0]) - 1] = '\0';
> +

Why don't we return -EINVAL if it is not correctly terminated by NUL?

--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] isdnloop: NUL-terminate strings from userspace

[YOSHIFUJI Hideaki]

Vegard Nossum wrote:
 Both the in-kernel and BSD strlcpy() require that the source string is
 NUL terminated. We could use strncpy() + explicitly terminate the result,
 but this relies on src and dest having the same size, so the safest thing
 to do seems to explicitly terminate the source string before doing the
 strlcpy().
:
 diff --git a/drivers/isdn/isdnloop/isdnloop.c 
 b/drivers/isdn/isdnloop/isdnloop.c
 index 02125e6..50cd348 100644
 --- a/drivers/isdn/isdnloop/isdnloop.c
 +++ b/drivers/isdn/isdnloop/isdnloop.c
 @@ -1070,6 +1070,14 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef 
 *sdefp)
   return -EBUSY;
   if (copy_from_user((char *) sdef, (char *) sdefp, sizeof(sdef)))
   return -EFAULT;
 +
 + /*
 +  * Null terminate strings from userspace so we don't have to worry
 +  * about this later on.
 +  */
 + for (i = 0; i  3; i++)
 + sdef.num[i][sizeof(sdef.num[0]) - 1] = '\0';
 +

Why don't we return -EINVAL if it is not correctly terminated by NUL?

--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/

[PATCH] isdnloop: Validate NUL-terminated strings from user.

[YOSHIFUJI Hideaki]

Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.

Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
---
 drivers/isdn/isdnloop/isdnloop.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/isdn/isdnloop/isdnloop.c b/drivers/isdn/isdnloop/isdnloop.c
index 02125e6..e1f8748 100644
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -1070,6 +1070,12 @@ isdnloop_start(isdnloop_card *card, isdnloop_sdef *sdefp)
return -EBUSY;
if (copy_from_user((char *) sdef, (char *) sdefp, sizeof(sdef)))
return -EFAULT;
+
+   for (i = 0; i  3; i++) {
+   if (!memchr(sdef.num[i], 0, sizeof(sdef.num[i])))
+   return -EINVAL;
+   }
+
spin_lock_irqsave(card-isdnloop_lock, flags);
switch (sdef.ptype) {
case ISDN_PTYPE_EURO:
-- 
1.7.9.5

--
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: Disable IPv4-mapped - enforce IPV6_V6ONLY

[YOSHIFUJI Hideaki]

Hello.

Alexander Holler wrote:
> Am 22.02.2013 16:21, schrieb Alexander Holler:
>> Hello,
>>
>> I'm searching for a way to either enforce IPV6_V6ONLY or to block
>> IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide.
>>
>> E.g. net.ipv6.bindv6only doesn't help if something calls
>>
>> int v6on = 0;
>> setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *), sizeof(v6on))
>>
>> In such a case I still want to disable or block IPv4-mapped addresses on
>> that socket, even if the program thinks it nows it better.
>>
>> Until now I haven't found a solution.
> 
> I've now done it by the following hack:
> 
> ---
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index d1e2e8e..9eefd3e 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, 
> int optname,
> if (optlen < sizeof(int) ||
> inet_sk(sk)->inet_num)
> goto e_inval;
> -   np->ipv6only = valbool;
> +   np->ipv6only = valbool || net->ipv6.sysctl.bindv6only;
> retv = 0;
> break;
> ---
> 
> A proper solution would be to either return false if net.ipv6.bindv6only is 
> true and optval is false (which would break downward compatibility because it 
> wouldn't just be a default and setsockopt might return an error) or to 
> introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently. 
> ("silently" because setsockopt() wouldn't return an error if 
> net.ipv6.bindv6only is true and optval (v6only in the example above) is 
> false.)
> 
> I would volunteer to write a patch which introduces something like 
> net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
> 
> If so, the question remains if
> 
> systemctl net.ipv6.bindv6only_enforced_silently = 1
> 
> should set systemctl.net.ipv6.bindv6only too or if an error should be 
> returned if net.ipv6.bindv6only is false.

I am not convinced why you need this, and I am not in favor of
enfocing IPV6_V6ONLY, but... some points:

- We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
- CAP_NET_ADMIN users should always be able to use both modes
  (They can do sysctl anyway.)
- setsockopt should fail w/ EPERM if user tries to override.

--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: Disable IPv4-mapped - enforce IPV6_V6ONLY

[YOSHIFUJI Hideaki]

Hello.

Alexander Holler wrote:
 Am 22.02.2013 16:21, schrieb Alexander Holler:
 Hello,

 I'm searching for a way to either enforce IPV6_V6ONLY or to block
 IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide.

 E.g. net.ipv6.bindv6only doesn't help if something calls

 int v6on = 0;
 setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)v6on, sizeof(v6on))

 In such a case I still want to disable or block IPv4-mapped addresses on
 that socket, even if the program thinks it nows it better.

 Until now I haven't found a solution.
 
 I've now done it by the following hack:
 
 ---
 diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
 index d1e2e8e..9eefd3e 100644
 --- a/net/ipv6/ipv6_sockglue.c
 +++ b/net/ipv6/ipv6_sockglue.c
 @@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, 
 int optname,
 if (optlen  sizeof(int) ||
 inet_sk(sk)-inet_num)
 goto e_inval;
 -   np-ipv6only = valbool;
 +   np-ipv6only = valbool || net-ipv6.sysctl.bindv6only;
 retv = 0;
 break;
 ---
 
 A proper solution would be to either return false if net.ipv6.bindv6only is 
 true and optval is false (which would break downward compatibility because it 
 wouldn't just be a default and setsockopt might return an error) or to 
 introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently. 
 (silently because setsockopt() wouldn't return an error if 
 net.ipv6.bindv6only is true and optval (v6only in the example above) is 
 false.)
 
 I would volunteer to write a patch which introduces something like 
 net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
 
 If so, the question remains if
 
 systemctl net.ipv6.bindv6only_enforced_silently = 1
 
 should set systemctl.net.ipv6.bindv6only too or if an error should be 
 returned if net.ipv6.bindv6only is false.

I am not convinced why you need this, and I am not in favor of
enfocing IPV6_V6ONLY, but... some points:

- We should allow system-admin to enforce IPV6_V6ONLY to 0 as well.
- CAP_NET_ADMIN users should always be able to use both modes
  (They can do sysctl anyway.)
- setsockopt should fail w/ EPERM if user tries to override.

--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: WARNING: at net/core/neighbour.c:1545 neigh_table_init()

[YOSHIFUJI Hideaki]

Eric Dumazet wrote:
> On Sat, 2013-02-09 at 20:39 +0800, Fengguang Wu wrote:
>> Greetings,
>>
>> I got the below oops in linux-next and the first bad commit is
>>
>> commit 455e987c0c2eb2c9045dc854559474cf41509965
>> Merge: 7c17e48 fd6da69
>> Author: Linus Torvalds 
>> Date:   Sat Dec 1 13:07:48 2012 -0800
>>
>> Merge branch 'perf-urgent-for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> 
>> Pull perf fixes from Ingo Molnar:
>>  "This is mostly about unbreaking architectures that took the UAPI
>>   changes in the v3.7 cycle, plus misc fixes."
>> 
>> * 'perf-urgent-for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>>   perf kvm: Fix building perf kvm on non x86 arches
>>   perf kvm: Rename perf_kvm to perf_kvm_stat
>>   perf: Make perf build for x86 with UAPI disintegration applied
>>   perf powerpc: Use uapi/unistd.h to fix build error
>>   tools: Pass the target in descend
>>   tools: Honour the O= flag when tool build called from a higher Makefile
>>   tools: Define a Makefile function to do subdir processing
>>   x86: Export asm/{svm.h,vmx.h,perf_regs.h}
>>   perf tools: Fix strbuf_addf() when the buffer needs to grow
>>   perf header: Fix numa topology printing
>>   perf, powerpc: Fix hw breakpoints returning -ENOSPC
>>
>> [  108.102297] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet 
>> Project Team
>> [  108.105501] [ cut here ]
>> [  108.106286] WARNING: at 
>> /c/kernel-tests/src/i386/net/core/neighbour.c:1545 
>> neigh_table_init+0x16f/0x490()
>> [  108.107506] Hardware name: Bochs
>> [  108.108577] Pid: 1, comm: swapper Not tainted 3.8.0-rc5-01118-geee5035 #17
>> [  108.109506] Call Trace:
>> [  108.79]  [] warn_slowpath_common+0xf2/0x140
>> [  108.112064]  [] ? neigh_table_init+0x16f/0x490
>> [  108.112880]  [] ? neigh_table_init+0x16f/0x490
>> [  108.114164]  [] ? atm_clip_init+0x98/0x98
>> [  108.115409]  [] warn_slowpath_null+0x39/0x50
>> [  108.116776]  [] neigh_table_init+0x16f/0x490
>> [  108.118169]  [] ? mutex_unlock+0x16/0x30
>> [  108.119260]  [] ? proto_register+0x65/0x350
>> [  108.120016]  [] ? atm_clip_init+0x98/0x98
>> [  108.121591]  [] dn_neigh_init+0x1b/0x2b
>> [  108.122305]  [] decnet_init+0x67/0xfc
>> [  108.123169]  [] do_one_initcall+0xf2/0x259
>> [  108.124259]  [] kernel_init_freeable+0x223/0x393
>> [  108.125053]  [] ? loglevel+0x55/0x55
>> [  108.125712]  [] kernel_init+0x19/0x200
>> [  108.126411]  [] ret_from_kernel_thread+0x1b/0x30
>> [  108.127194]  [] ? rest_init+0x1f0/0x1f0
>> [  108.128351] ---[ end trace 1bcbb5f262552fec ]---
>>
>> git bisect start v3.7 v3.6 --
>> git bisect good d66e6737d454553e1e62109d8298ede5351178a4  #10  
>> 2013-02-09 11:28:24  Merge 
>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
>> git bisect good e1b28147f684af67bfac989756c27c19859d3d4e  #10  
>> 2013-02-09 11:58:58  Merge branch 'for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>> git bisect good 37820108f395032e850e400139d956561a043c26  #10  
>> 2013-02-09 12:28:59  Merge tag 'fixes-for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>> git bisect good 60541d778e536455970281de25b2476e01c03aef  #10  
>> 2013-02-09 12:59:29  unicore32: switch to generic sys_execve()
>> git bisect good 403f43c937d24832b18524f65415c0bbba6b5064  #10  
>> 2013-02-09 13:29:53  team: bcast: convert return value of 
>> team_dev_queue_xmit() to bool correctly
>> git bisect good e23739b4ade80a3a7f87198f008f6c44a7cbc9fd  #10  
>> 2013-02-09 14:00:15  Merge branch 'v4l_for_linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
>> git bisect  bad 455e987c0c2eb2c9045dc854559474cf41509965  # 0  
>> 2013-02-09 14:03:12  Merge branch 'perf-urgent-for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good 50a53bbe1280839755cb120eef729ad150f644f9  #10  
>> 2013-02-09 14:31:02  Merge branch 'akpm' (Fixes from Andrew)
>> git bisect good 31e06a42a34395111842707a85774151245447b7  #10  
>> 2013-02-09 15:01:25  Merge branch 'for-linus' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
>> git bisect good 97a13bf3fed11a7508d58b67515c4b83cce25540  #10  
>> 2013-02-09 15:31:48  Merge tag 'perf-uapi-20121119' of 
>> git://git.infradead.org/users/dhowells/linux-headers into perf/urgent
>> git bisect good 8fdd78eeb11aeda018b22424f863344ef83a92d3  #10  
>> 2013-02-09 16:02:24  Merge tag 'for-linus' of 
>> git://linux-c6x.org/git/projects/linux-c6x-upstreaming
>> git bisect good 7c17e486e865d616f0e37c7f7f0e4dcfab704cd8  #10  
>> 2013-02-09 16:32:42  Merge branch 'x86/urgent' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> git bisect good 7321090f6751c9987c26a8c81c63680d16a614d7  #10  
>> 2013-02-09 17:03:13  perf kvm: Fix building perf kvm on non x86 arches
>> git 

[PATCH net-next] net neighbour,decnet: Ensure to align device private data on preferred alignment.

[YOSHIFUJI Hideaki]

To allow both of protocol-specific data and device-specific data
attached with neighbour entry, and to eliminate size calculation
cost when allocating entry, sizeof protocol-speicic data must be
multiple of NEIGH_PRIV_ALIGN.  On 64bit archs,
sizeof(struct dn_neigh) is multiple of NEIGH_PRIV_ALIGN, but on
32bit archs, it was not.

Introduce NEIGH_ENTRY_SPACE() macro to ensure that protocol-specific
entry-size meets our requirement.

Reported-by: Fengguang Wu 
Signed-off-by: YOSHIFUJI Hideaki 
---
 include/net/neighbour.h |1 +
 net/decnet/dn_neigh.c   |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 629ee57..7e748ad 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -181,6 +181,7 @@ struct neigh_table {
 };
 
 #define NEIGH_PRIV_ALIGN   sizeof(long long)
+#define NEIGH_ENTRY_SIZE(size) ALIGN((size), NEIGH_PRIV_ALIGN)
 
 static inline void *neighbour_priv(const struct neighbour *n)
 {
diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c
index 3aede1b..856636a 100644
--- a/net/decnet/dn_neigh.c
+++ b/net/decnet/dn_neigh.c
@@ -95,7 +95,7 @@ static u32 dn_neigh_hash(const void *pkey,
 
 struct neigh_table dn_neigh_table = {
.family =   PF_DECnet,
-   .entry_size =   sizeof(struct dn_neigh),
+   .entry_size =   NEIGH_ENTRY_SIZE(sizeof(struct 
dn_neigh)),
.key_len =  sizeof(__le16),
.hash = dn_neigh_hash,
.constructor =  dn_neigh_construct,
-- 
1.7.9.5

--
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/

[PATCH net-next] net neighbour,decnet: Ensure to align device private data on preferred alignment.

[YOSHIFUJI Hideaki]

To allow both of protocol-specific data and device-specific data
attached with neighbour entry, and to eliminate size calculation
cost when allocating entry, sizeof protocol-speicic data must be
multiple of NEIGH_PRIV_ALIGN.  On 64bit archs,
sizeof(struct dn_neigh) is multiple of NEIGH_PRIV_ALIGN, but on
32bit archs, it was not.

Introduce NEIGH_ENTRY_SPACE() macro to ensure that protocol-specific
entry-size meets our requirement.

Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
---
 include/net/neighbour.h |1 +
 net/decnet/dn_neigh.c   |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index 629ee57..7e748ad 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -181,6 +181,7 @@ struct neigh_table {
 };
 
 #define NEIGH_PRIV_ALIGN   sizeof(long long)
+#define NEIGH_ENTRY_SIZE(size) ALIGN((size), NEIGH_PRIV_ALIGN)
 
 static inline void *neighbour_priv(const struct neighbour *n)
 {
diff --git a/net/decnet/dn_neigh.c b/net/decnet/dn_neigh.c
index 3aede1b..856636a 100644
--- a/net/decnet/dn_neigh.c
+++ b/net/decnet/dn_neigh.c
@@ -95,7 +95,7 @@ static u32 dn_neigh_hash(const void *pkey,
 
 struct neigh_table dn_neigh_table = {
.family =   PF_DECnet,
-   .entry_size =   sizeof(struct dn_neigh),
+   .entry_size =   NEIGH_ENTRY_SIZE(sizeof(struct 
dn_neigh)),
.key_len =  sizeof(__le16),
.hash = dn_neigh_hash,
.constructor =  dn_neigh_construct,
-- 
1.7.9.5

--
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: WARNING: at net/core/neighbour.c:1545 neigh_table_init()

[YOSHIFUJI Hideaki]

Eric Dumazet wrote:
 On Sat, 2013-02-09 at 20:39 +0800, Fengguang Wu wrote:
 Greetings,

 I got the below oops in linux-next and the first bad commit is

 commit 455e987c0c2eb2c9045dc854559474cf41509965
 Merge: 7c17e48 fd6da69
 Author: Linus Torvalds torva...@linux-foundation.org
 Date:   Sat Dec 1 13:07:48 2012 -0800

 Merge branch 'perf-urgent-for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
 
 Pull perf fixes from Ingo Molnar:
  This is mostly about unbreaking architectures that took the UAPI
   changes in the v3.7 cycle, plus misc fixes.
 
 * 'perf-urgent-for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
   perf kvm: Fix building perf kvm on non x86 arches
   perf kvm: Rename perf_kvm to perf_kvm_stat
   perf: Make perf build for x86 with UAPI disintegration applied
   perf powerpc: Use uapi/unistd.h to fix build error
   tools: Pass the target in descend
   tools: Honour the O= flag when tool build called from a higher Makefile
   tools: Define a Makefile function to do subdir processing
   x86: Export asm/{svm.h,vmx.h,perf_regs.h}
   perf tools: Fix strbuf_addf() when the buffer needs to grow
   perf header: Fix numa topology printing
   perf, powerpc: Fix hw breakpoints returning -ENOSPC

 [  108.102297] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet 
 Project Team
 [  108.105501] [ cut here ]
 [  108.106286] WARNING: at 
 /c/kernel-tests/src/i386/net/core/neighbour.c:1545 
 neigh_table_init+0x16f/0x490()
 [  108.107506] Hardware name: Bochs
 [  108.108577] Pid: 1, comm: swapper Not tainted 3.8.0-rc5-01118-geee5035 #17
 [  108.109506] Call Trace:
 [  108.79]  [c1054e52] warn_slowpath_common+0xf2/0x140
 [  108.112064]  [c1acc2af] ? neigh_table_init+0x16f/0x490
 [  108.112880]  [c1acc2af] ? neigh_table_init+0x16f/0x490
 [  108.114164]  [c24d8c67] ? atm_clip_init+0x98/0x98
 [  108.115409]  [c1054ff9] warn_slowpath_null+0x39/0x50
 [  108.116776]  [c1acc2af] neigh_table_init+0x16f/0x490
 [  108.118169]  [c1d0ba16] ? mutex_unlock+0x16/0x30
 [  108.119260]  [c1a9cbf5] ? proto_register+0x65/0x350
 [  108.120016]  [c24d8c67] ? atm_clip_init+0x98/0x98
 [  108.121591]  [c24d91c6] dn_neigh_init+0x1b/0x2b
 [  108.122305]  [c24d8cce] decnet_init+0x67/0xfc
 [  108.123169]  [c2472470] do_one_initcall+0xf2/0x259
 [  108.124259]  [c24727fa] kernel_init_freeable+0x223/0x393
 [  108.125053]  [c2471548] ? loglevel+0x55/0x55
 [  108.125712]  [c1ce8b59] kernel_init+0x19/0x200
 [  108.126411]  [c1d114fb] ret_from_kernel_thread+0x1b/0x30
 [  108.127194]  [c1ce8b40] ? rest_init+0x1f0/0x1f0
 [  108.128351] ---[ end trace 1bcbb5f262552fec ]---

 git bisect start v3.7 v3.6 --
 git bisect good d66e6737d454553e1e62109d8298ede5351178a4  #10  
 2013-02-09 11:28:24  Merge 
 git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
 git bisect good e1b28147f684af67bfac989756c27c19859d3d4e  #10  
 2013-02-09 11:58:58  Merge branch 'for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
 git bisect good 37820108f395032e850e400139d956561a043c26  #10  
 2013-02-09 12:28:59  Merge tag 'fixes-for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
 git bisect good 60541d778e536455970281de25b2476e01c03aef  #10  
 2013-02-09 12:59:29  unicore32: switch to generic sys_execve()
 git bisect good 403f43c937d24832b18524f65415c0bbba6b5064  #10  
 2013-02-09 13:29:53  team: bcast: convert return value of 
 team_dev_queue_xmit() to bool correctly
 git bisect good e23739b4ade80a3a7f87198f008f6c44a7cbc9fd  #10  
 2013-02-09 14:00:15  Merge branch 'v4l_for_linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
 git bisect  bad 455e987c0c2eb2c9045dc854559474cf41509965  # 0  
 2013-02-09 14:03:12  Merge branch 'perf-urgent-for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
 git bisect good 50a53bbe1280839755cb120eef729ad150f644f9  #10  
 2013-02-09 14:31:02  Merge branch 'akpm' (Fixes from Andrew)
 git bisect good 31e06a42a34395111842707a85774151245447b7  #10  
 2013-02-09 15:01:25  Merge branch 'for-linus' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal
 git bisect good 97a13bf3fed11a7508d58b67515c4b83cce25540  #10  
 2013-02-09 15:31:48  Merge tag 'perf-uapi-20121119' of 
 git://git.infradead.org/users/dhowells/linux-headers into perf/urgent
 git bisect good 8fdd78eeb11aeda018b22424f863344ef83a92d3  #10  
 2013-02-09 16:02:24  Merge tag 'for-linus' of 
 git://linux-c6x.org/git/projects/linux-c6x-upstreaming
 git bisect good 7c17e486e865d616f0e37c7f7f0e4dcfab704cd8  #10  
 2013-02-09 16:32:42  Merge branch 'x86/urgent' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
 git bisect good 7321090f6751c9987c26a8c81c63680d16a614d7  #10  
 2013-02-09 17:03:13  perf kvm: Fix building perf kvm on non x86 arches
 git bisect good 

[PATCH] digsig: Fix memory leakage in digsig_verify_rsa().

[YOSHIFUJI Hideaki]

digsig_verify_rsa() does not free kmalloc'ed buffer returned by
mpi_get_buffer().

Signed-off-by: YOSHIFUJI Hideaki 
---
 lib/digsig.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/digsig.c b/lib/digsig.c
index 8c0e629..dc2be7e 100644
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key *key,
memset(out1, 0, head);
memcpy(out1 + head, p, l);
 
+   kfree(p);
+
err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, );
if (err)
goto err;
-- 
1.7.9.5

--
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/

[PATCH] digsig: Fix memory leakage in digsig_verify_rsa().

[YOSHIFUJI Hideaki]

digsig_verify_rsa() does not free kmalloc'ed buffer returned by
mpi_get_buffer().

Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
---
 lib/digsig.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/digsig.c b/lib/digsig.c
index 8c0e629..dc2be7e 100644
--- a/lib/digsig.c
+++ b/lib/digsig.c
@@ -162,6 +162,8 @@ static int digsig_verify_rsa(struct key *key,
memset(out1, 0, head);
memcpy(out1 + head, p, l);
 
+   kfree(p);
+
err = pkcs_1_v1_5_decode_emsa(out1, len, mblen, out2, len);
if (err)
goto err;
-- 
1.7.9.5

--
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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues

[YOSHIFUJI Hideaki]

YOSHIFUJI Hideaki wrote:
> Jussi Kivilinna wrote:
> 
>>>>> diff --git a/include/uapi/linux/pfkeyv2.h
>>>>> b/include/uapi/linux/pfkeyv2.h
>>>>> index 0b80c80..d61898e 100644
>>>>> --- a/include/uapi/linux/pfkeyv2.h
>>>>> +++ b/include/uapi/linux/pfkeyv2.h
>>>>> @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>>>>  #define SADB_X_AALG_SHA2_512HMAC7
>>>>>  #define SADB_X_AALG_RIPEMD160HMAC8
>>>>>  #define SADB_X_AALG_AES_XCBC_MAC9
>>>>> +#define SADB_X_AALG_AES_CMAC_MAC10
>>>>>  #define SADB_X_AALG_NULL251/* kame */
>>>>>  #define SADB_AALG_MAX251
>>>>
>>>> Should these values be based on IANA assigned IPSEC AH transform
>>>> identifiers?
>>>>
>>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>>
>>> There is no CMAC entry apparently ... despite the fact that CMAC is a 
>>> proposed RFC standard for IPsec.
>>>
>>> It might be safer to move that to 14 since it's currently unassigned and 
>>> then go through whatever channels are required to allocate it.  Mostly this 
>>> affects key setting.  So this means my patch would break AH_RSA setkey 
>>> calls (which the kernel doesn't support anyways).
>>>
>>
>> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM 
>> API should be used instead. There is new numbers assigned for IKEv2: 
>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
>>
>> For new SADB_X_AALG_*, I'd think you should use value from "Reserved for 
>> private use" range. Maybe 250?
> 
> We can choose any value unless we do not break existing
> binaries.  When IKE used, the daemon is responsible
> for translation.

I meant, we can choose any values "if" we do not break ...

--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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues

[YOSHIFUJI Hideaki]

Jussi Kivilinna wrote:

>>> > diff --git a/include/uapi/linux/pfkeyv2.h
>>> > b/include/uapi/linux/pfkeyv2.h
>>> > index 0b80c80..d61898e 100644
>>> > --- a/include/uapi/linux/pfkeyv2.h
>>> > +++ b/include/uapi/linux/pfkeyv2.h
>>> > @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
>>> >  #define SADB_X_AALG_SHA2_512HMAC7
>>> >  #define SADB_X_AALG_RIPEMD160HMAC8
>>> >  #define SADB_X_AALG_AES_XCBC_MAC9
>>> > +#define SADB_X_AALG_AES_CMAC_MAC10
>>> >  #define SADB_X_AALG_NULL251/* kame */
>>> >  #define SADB_AALG_MAX251
>>>
>>> Should these values be based on IANA assigned IPSEC AH transform
>>> identifiers?
>>>
>>> https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6
>>
>> There is no CMAC entry apparently ... despite the fact that CMAC is a 
>> proposed RFC standard for IPsec.
>>
>> It might be safer to move that to 14 since it's currently unassigned and 
>> then go through whatever channels are required to allocate it.  Mostly this 
>> affects key setting.  So this means my patch would break AH_RSA setkey calls 
>> (which the kernel doesn't support anyways).
>>
> 
> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM API 
> should be used instead. There is new numbers assigned for IKEv2: 
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
> 
> For new SADB_X_AALG_*, I'd think you should use value from "Reserved for 
> private use" range. Maybe 250?

We can choose any value unless we do not break existing
binaries.  When IKE used, the daemon is responsible
for translation.

--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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues

[YOSHIFUJI Hideaki]

Jussi Kivilinna wrote:

  diff --git a/include/uapi/linux/pfkeyv2.h
  b/include/uapi/linux/pfkeyv2.h
  index 0b80c80..d61898e 100644
  --- a/include/uapi/linux/pfkeyv2.h
  +++ b/include/uapi/linux/pfkeyv2.h
  @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
   #define SADB_X_AALG_SHA2_512HMAC7
   #define SADB_X_AALG_RIPEMD160HMAC8
   #define SADB_X_AALG_AES_XCBC_MAC9
  +#define SADB_X_AALG_AES_CMAC_MAC10
   #define SADB_X_AALG_NULL251/* kame */
   #define SADB_AALG_MAX251

 Should these values be based on IANA assigned IPSEC AH transform
 identifiers?

 https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6

 There is no CMAC entry apparently ... despite the fact that CMAC is a 
 proposed RFC standard for IPsec.

 It might be safer to move that to 14 since it's currently unassigned and 
 then go through whatever channels are required to allocate it.  Mostly this 
 affects key setting.  So this means my patch would break AH_RSA setkey calls 
 (which the kernel doesn't support anyways).

 
 Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM API 
 should be used instead. There is new numbers assigned for IKEv2: 
 https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7
 
 For new SADB_X_AALG_*, I'd think you should use value from Reserved for 
 private use range. Maybe 250?

We can choose any value unless we do not break existing
binaries.  When IKE used, the daemon is responsible
for translation.

--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] CMAC support for CryptoAPI, fixed patch issues, indent, and testmgr build issues

[YOSHIFUJI Hideaki]

YOSHIFUJI Hideaki wrote:
 Jussi Kivilinna wrote:
 
 diff --git a/include/uapi/linux/pfkeyv2.h
 b/include/uapi/linux/pfkeyv2.h
 index 0b80c80..d61898e 100644
 --- a/include/uapi/linux/pfkeyv2.h
 +++ b/include/uapi/linux/pfkeyv2.h
 @@ -296,6 +296,7 @@ struct sadb_x_kmaddress {
  #define SADB_X_AALG_SHA2_512HMAC7
  #define SADB_X_AALG_RIPEMD160HMAC8
  #define SADB_X_AALG_AES_XCBC_MAC9
 +#define SADB_X_AALG_AES_CMAC_MAC10
  #define SADB_X_AALG_NULL251/* kame */
  #define SADB_AALG_MAX251

 Should these values be based on IANA assigned IPSEC AH transform
 identifiers?

 https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xml#isakmp-registry-6

 There is no CMAC entry apparently ... despite the fact that CMAC is a 
 proposed RFC standard for IPsec.

 It might be safer to move that to 14 since it's currently unassigned and 
 then go through whatever channels are required to allocate it.  Mostly this 
 affects key setting.  So this means my patch would break AH_RSA setkey 
 calls (which the kernel doesn't support anyways).


 Problem seems to be that PFKEYv2 does not quite work with IKEv2, and XFRM 
 API should be used instead. There is new numbers assigned for IKEv2: 
 https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-7

 For new SADB_X_AALG_*, I'd think you should use value from Reserved for 
 private use range. Maybe 250?
 
 We can choose any value unless we do not break existing
 binaries.  When IKE used, the daemon is responsible
 for translation.

I meant, we can choose any values if we do not break ...

--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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> 
>> "Off-link source" means the source exists on the different L2
>> network.  In other words, source is connected via router(s).
>>
>>   ethernet firewire
>>   Host -- Router  Host
>>
> 
> O.k., understood. But the receiving router verifies the checksum of incoming 
> packets and sends them on the firewire link. On firewire we have CRC 
> checksums to ensure the integrity of packets.
> 
> I agree with your patch but I don't see why we should check them in the 
> driver. I thought your patch will ensure that the checksums will be verified 
> in the upper layers.

Routers do not inspect whole packet.
For IPv4, we have IP checksum, but routers (usually) do not check
upper-layer (e.g. UDP) checksum.
For IPv6, we do not have IP checksum.

CHECKSUM_UNNECESSARY means the driver has verified upper layer
(e.g. TCP/UDP) checksum.  Modern hardware can perform upper-layer
checksumming as well. But of course, not all drivers are required
to verify the upper-layer checksum; if the driver do not verify
checksum in the packet, just say CHECKSUM_NONE.

Regards,

--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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
> 
>>> Indeed neither the device nor the lower drivers check protocol checksums.
>>> But the CRCs of the encapsulating 1394 packets are checked in hardware.
>>> Shall protocol checksums be verified regardless?
>>
>> Yes, because packets may come from off-link source.
>>
> 
> Hm, I can't see any off-link packets coming from 
> fwnet_finish_incoming_packet()
> 
> So I wont verify checksums in the driver.

"Off-link source" means the source exists on the different L2
network.  In other words, source is connected via router(s).

 ethernet firewire
 Host -- Router  Host

--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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stefan Richter wrote:
> On Jan 20 YOSHIFUJI Hideaki wrote:
>> It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
>> the device has already checked it.
>>
>> Signed-off-by: YOSHIFUJI Hideaki 
>> ---
>>  drivers/firewire/net.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
>> index e7a711f5..df6a1ca 100644
>> --- a/drivers/firewire/net.c
>> +++ b/drivers/firewire/net.c
>> @@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct 
>> net_device *net,
>>  dev = netdev_priv(net);
>>  /* Write metadata, and then pass to the receive level */
>>  skb->dev = net;
>> -skb->ip_summed = CHECKSUM_UNNECESSARY;  /* don't check it */
>> +skb->ip_summed = CHECKSUM_NONE;
>>  
>>  /*
>>   * Parse the encapsulation header. This actually does the job of
> 
> Indeed neither the device nor the lower drivers check protocol checksums.
> But the CRCs of the encapsulating 1394 packets are checked in hardware.
> Shall protocol checksums be verified regardless?

Yes, because packets may come from off-link source.

--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/

[PATCH] firewire net: Use LL_RESERVED_SPACE(), HH_DATA_OFF().

[YOSHIFUJI Hideaki]

Signed-off-by: YOSHIFUJI Hideaki 
---
 drivers/firewire/net.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index df6a1ca..2b27bff 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -270,7 +270,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
if (type == cpu_to_be16(ETH_P_802_3))
return -1;
net = neigh->dev;
-   h = (struct fwnet_header *)((u8 *)hh->hh_data + 16 - sizeof(*h));
+   h = (struct fwnet_header *)((u8 *)hh->hh_data + 
HH_DATA_OFF(sizeof(*h)));
h->h_proto = type;
memcpy(h->h_dest, neigh->ha, net->addr_len);
hh->hh_len = FWNET_HLEN;
@@ -282,7 +282,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
 static void fwnet_header_cache_update(struct hh_cache *hh,
const struct net_device *net, const unsigned char *haddr)
 {
-   memcpy((u8 *)hh->hh_data + 16 - FWNET_HLEN, haddr, net->addr_len);
+   memcpy((u8 *)hh->hh_data + HH_DATA_OFF(FWNET_HLEN), haddr, 
net->addr_len);
 }
 
 static int fwnet_header_parse(const struct sk_buff *skb, unsigned char *haddr)
@@ -398,11 +398,11 @@ static struct fwnet_partial_datagram *fwnet_pd_new(struct 
net_device *net,
 
new->datagram_label = datagram_label;
new->datagram_size = dg_size;
-   new->skb = dev_alloc_skb(dg_size + net->hard_header_len + 15);
+   new->skb = dev_alloc_skb(dg_size + LL_RESERVED_SPACE(net));
if (new->skb == NULL)
goto fail_w_fi;
 
-   skb_reserve(new->skb, (net->hard_header_len + 15) & ~15);
+   skb_reserve(new->skb, LL_RESERVED_SPACE(net));
new->pbuf = skb_put(new->skb, dg_size);
memcpy(new->pbuf + frag_off, frag_buf, frag_len);
list_add_tail(>pd_link, >pd_list);
@@ -690,14 +690,14 @@ static int fwnet_incoming_packet(struct fwnet_device 
*dev, __be32 *buf, int len,
buf++;
len -= RFC2374_UNFRAG_HDR_SIZE;
 
-   skb = dev_alloc_skb(len + net->hard_header_len + 15);
+   skb = dev_alloc_skb(len + LL_RESERVED_SPACE(net));
if (unlikely(!skb)) {
dev_err(>dev, "out of memory\n");
net->stats.rx_dropped++;
 
return -ENOMEM;
}
-   skb_reserve(skb, (net->hard_header_len + 15) & ~15);
+   skb_reserve(skb, LL_RESERVED_SPACE(net));
memcpy(skb_put(skb, len), buf, len);
 
return fwnet_finish_incoming_packet(net, skb, source_node_id,
-- 
1.7.9.5

--
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/

[PATCH] firewire net: Use LL_RESERVED_SPACE(), HH_DATA_OFF().

[YOSHIFUJI Hideaki]

Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
---
 drivers/firewire/net.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index df6a1ca..2b27bff 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -270,7 +270,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
if (type == cpu_to_be16(ETH_P_802_3))
return -1;
net = neigh-dev;
-   h = (struct fwnet_header *)((u8 *)hh-hh_data + 16 - sizeof(*h));
+   h = (struct fwnet_header *)((u8 *)hh-hh_data + 
HH_DATA_OFF(sizeof(*h)));
h-h_proto = type;
memcpy(h-h_dest, neigh-ha, net-addr_len);
hh-hh_len = FWNET_HLEN;
@@ -282,7 +282,7 @@ static int fwnet_header_cache(const struct neighbour *neigh,
 static void fwnet_header_cache_update(struct hh_cache *hh,
const struct net_device *net, const unsigned char *haddr)
 {
-   memcpy((u8 *)hh-hh_data + 16 - FWNET_HLEN, haddr, net-addr_len);
+   memcpy((u8 *)hh-hh_data + HH_DATA_OFF(FWNET_HLEN), haddr, 
net-addr_len);
 }
 
 static int fwnet_header_parse(const struct sk_buff *skb, unsigned char *haddr)
@@ -398,11 +398,11 @@ static struct fwnet_partial_datagram *fwnet_pd_new(struct 
net_device *net,
 
new-datagram_label = datagram_label;
new-datagram_size = dg_size;
-   new-skb = dev_alloc_skb(dg_size + net-hard_header_len + 15);
+   new-skb = dev_alloc_skb(dg_size + LL_RESERVED_SPACE(net));
if (new-skb == NULL)
goto fail_w_fi;
 
-   skb_reserve(new-skb, (net-hard_header_len + 15)  ~15);
+   skb_reserve(new-skb, LL_RESERVED_SPACE(net));
new-pbuf = skb_put(new-skb, dg_size);
memcpy(new-pbuf + frag_off, frag_buf, frag_len);
list_add_tail(new-pd_link, peer-pd_list);
@@ -690,14 +690,14 @@ static int fwnet_incoming_packet(struct fwnet_device 
*dev, __be32 *buf, int len,
buf++;
len -= RFC2374_UNFRAG_HDR_SIZE;
 
-   skb = dev_alloc_skb(len + net-hard_header_len + 15);
+   skb = dev_alloc_skb(len + LL_RESERVED_SPACE(net));
if (unlikely(!skb)) {
dev_err(net-dev, out of memory\n);
net-stats.rx_dropped++;
 
return -ENOMEM;
}
-   skb_reserve(skb, (net-hard_header_len + 15)  ~15);
+   skb_reserve(skb, LL_RESERVED_SPACE(net));
memcpy(skb_put(skb, len), buf, len);
 
return fwnet_finish_incoming_packet(net, skb, source_node_id,
-- 
1.7.9.5

--
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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stefan Richter wrote:
 On Jan 20 YOSHIFUJI Hideaki wrote:
 It is wrong to set skb-ip_summed to CHECKSUM_UNNECESSARY unless
 the device has already checked it.

 Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
 ---
  drivers/firewire/net.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
 index e7a711f5..df6a1ca 100644
 --- a/drivers/firewire/net.c
 +++ b/drivers/firewire/net.c
 @@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct 
 net_device *net,
  dev = netdev_priv(net);
  /* Write metadata, and then pass to the receive level */
  skb-dev = net;
 -skb-ip_summed = CHECKSUM_UNNECESSARY;  /* don't check it */
 +skb-ip_summed = CHECKSUM_NONE;
  
  /*
   * Parse the encapsulation header. This actually does the job of
 
 Indeed neither the device nor the lower drivers check protocol checksums.
 But the CRCs of the encapsulating 1394 packets are checked in hardware.
 Shall protocol checksums be verified regardless?

Yes, because packets may come from off-link source.

--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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
 
 Indeed neither the device nor the lower drivers check protocol checksums.
 But the CRCs of the encapsulating 1394 packets are checked in hardware.
 Shall protocol checksums be verified regardless?

 Yes, because packets may come from off-link source.

 
 Hm, I can't see any off-link packets coming from 
 fwnet_finish_incoming_packet()
 
 So I wont verify checksums in the driver.

Off-link source means the source exists on the different L2
network.  In other words, source is connected via router(s).

 ethernet firewire
 Host -- Router  Host

--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] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

Stephan Gatzka wrote:
 
 Off-link source means the source exists on the different L2
 network.  In other words, source is connected via router(s).

   ethernet firewire
   Host -- Router  Host

 
 O.k., understood. But the receiving router verifies the checksum of incoming 
 packets and sends them on the firewire link. On firewire we have CRC 
 checksums to ensure the integrity of packets.
 
 I agree with your patch but I don't see why we should check them in the 
 driver. I thought your patch will ensure that the checksums will be verified 
 in the upper layers.

Routers do not inspect whole packet.
For IPv4, we have IP checksum, but routers (usually) do not check
upper-layer (e.g. UDP) checksum.
For IPv6, we do not have IP checksum.

CHECKSUM_UNNECESSARY means the driver has verified upper layer
(e.g. TCP/UDP) checksum.  Modern hardware can perform upper-layer
checksumming as well. But of course, not all drivers are required
to verify the upper-layer checksum; if the driver do not verify
checksum in the packet, just say CHECKSUM_NONE.

Regards,

--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/

[PATCH] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
the device has already checked it.

Signed-off-by: YOSHIFUJI Hideaki 
---
 drivers/firewire/net.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index e7a711f5..df6a1ca 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct net_device 
*net,
dev = netdev_priv(net);
/* Write metadata, and then pass to the receive level */
skb->dev = net;
-   skb->ip_summed = CHECKSUM_UNNECESSARY;  /* don't check it */
+   skb->ip_summed = CHECKSUM_NONE;
 
/*
 * Parse the encapsulation header. This actually does the job of
-- 
1.7.9.5


--
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/

[PATCH] firewire net: Ensure checksumming in upper layer.

[YOSHIFUJI Hideaki]

It is wrong to set skb-ip_summed to CHECKSUM_UNNECESSARY unless
the device has already checked it.

Signed-off-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org
---
 drivers/firewire/net.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index e7a711f5..df6a1ca 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -520,7 +520,7 @@ static int fwnet_finish_incoming_packet(struct net_device 
*net,
dev = netdev_priv(net);
/* Write metadata, and then pass to the receive level */
skb-dev = net;
-   skb-ip_summed = CHECKSUM_UNNECESSARY;  /* don't check it */
+   skb-ip_summed = CHECKSUM_NONE;
 
/*
 * Parse the encapsulation header. This actually does the job of
-- 
1.7.9.5


--
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: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
> On 01/18/2013 05:44 AM, Pedro Alves wrote:
>> On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
>>> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger  wrote:
 On Wednesday 16 January 2013 22:15:38 David Miller wrote:
> From: Carlos O'Donell 
> Date: Wed, 16 Jan 2013 21:15:03 -0500
>
>> +/* If a glibc-based userspace has already included in.h, then we will
>> not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq.
>> The + * ABI used by the kernel and by glibc match exactly. Neither the
>> kernel + * nor glibc should break this ABI without coordination.
>> + */
>> +#ifndef _NETINET_IN_H
>> +
>
> I think we should shoot for a non-glibc-centric solution.
>
> I can't imagine that other libc's won't have the same exact problem
> with their netinet/in.h conflicting with the kernel's, redefining
> structures like in6_addr, that we'd want to provide a protection
> scheme for here as well.

 yes, the kernel's use of __GLIBC__ in exported headers has already caused
 problems in the past.  fortunately, it's been reduced down to just one case
 now (stat.h).  let's not balloon it back up.
 -mike
>>>
>>> I also see coda.h has grown a __GLIBC__ usage.
>>>
>>> In the next revision of the patch I created a single libc-compat.h header
>>> which encompasses the logic for any libc that wants to coordinate with
>>> the kernel headers.
>>
>>
>>> It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
>>> then you control userspace libc coordination from one file.
>>
>> How about just deciding on a single macro/symbol both the
>> kernel and libc (any libc that needs this) define?  Something
>> like both the kernel and userland doing:
>> 
>> #ifndef __IPV6_BITS_DEFINED
>> #define __IPV6_BITS_DEFINED
>> ...
>> define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
>> #endif

Hmm, how should we handle future structs/enums then?
For example, if I want to have in6_flowlabel_req{} defined in
glibc, what should we do?

We probably want to have __LIBC_HAS_STRUCT_IN6_FLOWLABEL_REQ
defined.

--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: Redefinition of struct in6_addr in netinet/in.h and linux/in6.h

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
 On 01/18/2013 05:44 AM, Pedro Alves wrote:
 On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
 On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Wednesday 16 January 2013 22:15:38 David Miller wrote:
 From: Carlos O'Donell car...@systemhalted.org
 Date: Wed, 16 Jan 2013 21:15:03 -0500

 +/* If a glibc-based userspace has already included in.h, then we will
 not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq.
 The + * ABI used by the kernel and by glibc match exactly. Neither the
 kernel + * nor glibc should break this ABI without coordination.
 + */
 +#ifndef _NETINET_IN_H
 +

 I think we should shoot for a non-glibc-centric solution.

 I can't imagine that other libc's won't have the same exact problem
 with their netinet/in.h conflicting with the kernel's, redefining
 structures like in6_addr, that we'd want to provide a protection
 scheme for here as well.

 yes, the kernel's use of __GLIBC__ in exported headers has already caused
 problems in the past.  fortunately, it's been reduced down to just one case
 now (stat.h).  let's not balloon it back up.
 -mike

 I also see coda.h has grown a __GLIBC__ usage.

 In the next revision of the patch I created a single libc-compat.h header
 which encompasses the logic for any libc that wants to coordinate with
 the kernel headers.


 It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
 then you control userspace libc coordination from one file.

 How about just deciding on a single macro/symbol both the
 kernel and libc (any libc that needs this) define?  Something
 like both the kernel and userland doing:
 
 #ifndef __IPV6_BITS_DEFINED
 #define __IPV6_BITS_DEFINED
 ...
 define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
 #endif

Hmm, how should we handle future structs/enums then?
For example, if I want to have in6_flowlabel_req{} defined in
glibc, what should we do?

We probably want to have __LIBC_HAS_STRUCT_IN6_FLOWLABEL_REQ
defined.

--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: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index f79c372..a2b16a5 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
> @@ -23,6 +23,13 @@
>  
>  #include 
>  
> +/* If a glibc-based userspace has already included in.h, then we will not 
> + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
> + * ABI used by the kernel and by glibc match exactly. Neither the kernel
> + * nor glibc should break this ABI without coordination.
> + */
> +#ifndef _NETINET_IN_H
> +
>  /*
>   *   IPv6 address structure
>   */

This should be
#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)

> @@ -30,12 +37,20 @@
>  struct in6_addr {
>   union {
>   __u8u6_addr8[16];
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
>   __be16  u6_addr16[8];
>   __be32  u6_addr32[4];
> +#endif
>   } in6_u;
> +#if !defined(__GLIBC__) \
> +|| (defined(__GLIBC__) && (defined(__USE_MISC) || defined(__USE_GNU))) \
> +|| defined(__KERNEL__)
>  #define s6_addr  in6_u.u6_addr8
>  #define s6_addr16in6_u.u6_addr16
>  #define s6_addr32in6_u.u6_addr32
> +#endif
>  };

2nd "if" be after s6_addr?

--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: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
> index f79c372..a2b16a5 100644
> --- a/include/uapi/linux/in6.h
> +++ b/include/uapi/linux/in6.h
:
>  #define IPV6_PRIORITY_14 0x0e00
>  #define IPV6_PRIORITY_15 0x0f00
>  
> +
> +#ifndef _NETINET_IN_H
> +#if defined (__GLIBC__)
> +/* Include all of the other IPPROTO_* defines for userspace. */
> +#include 
> +#endif
>  /*
>   *   IPV6 extension headers

Overall, it looks good, but why including linux/ipproto.h?

--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: Redefinition of struct in6_addr in and

[YOSHIFUJI Hideaki]

Cong Wang wrote:
> (Cc'ing some glibc developers...)
> 
> Hello,
> 
> In glibc source file inet/netinet/in.h and kernel source file
> include/uapi/linux/in6.h, both define struct in6_addr, and both are
> visible to user applications. Thomas reported a conflict below.
> 
> So, how can we handle this? /me is wondering why we didn't see this
> before.
> 
> Thanks.
> 
> On Tue, 2013-01-15 at 12:55 +0200, Thomas Backlund wrote:
>> Cong Wang skrev 15.1.2013 12:11:
>>>
>>> Does the following patch help?
>>>
>>> $ git diff include/uapi/linux/if_bridge.h
>>> diff --git a/include/uapi/linux/if_bridge.h
>>> b/include/uapi/linux/if_bridge.h
>>> index 5db2975..653db23 100644
>>> --- a/include/uapi/linux/if_bridge.h
>>> +++ b/include/uapi/linux/if_bridge.h
>>> @@ -14,6 +14,7 @@
>>>   #define _UAPI_LINUX_IF_BRIDGE_H
>>>
>>>   #include 
>>> +#include 
>>>
>>>   #define SYSFS_BRIDGE_ATTR  "bridge"
>>>   #define SYSFS_BRIDGE_FDB   "brforward"
>>>
>>
>> Well, I suggested the same fix in the beginning of the thread
>> on netdev and lkml: "if_bridge.h: include in6.h for struct in6_addr use"
>>
>> as it seemed to fix the libvirt case
>>
>> but then asked it to be ignored after I tried to build connman,
>> and hit this conflict with glibc-2.17:
>>
>> In file included from /usr/include/arpa/inet.h:22:0,
>>   from ./include/connman/inet.h:25,
>>   from src/connman.h:128,
>>   from src/tethering.c:40:
>> /usr/include/netinet/in.h:35:5: error: expected identifier before 
>> numeric constant
>> /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>>   from src/tethering.c:38:
>> /usr/include/linux/in6.h:30:8: note: originally defined here
>> In file included from /usr/include/arpa/inet.h:22:0,
>>   from ./include/connman/inet.h:25,
>>   from src/connman.h:128,
>>   from src/tethering.c:40:
>> /usr/include/netinet/in.h:238:8: error: redefinition of 'struct 
>> sockaddr_in6'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>>   from src/tethering.c:38:
>> /usr/include/linux/in6.h:46:8: note: originally defined here
>> In file included from /usr/include/arpa/inet.h:22:0,
>>   from ./include/connman/inet.h:25,
>>   from src/connman.h:128,
>>   from src/tethering.c:40:
>> /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq'
>> In file included from /usr/include/linux/if_bridge.h:17:0,
>>   from src/tethering.c:38:
>> /usr/include/linux/in6.h:54:8: note: originally defined here
>> make[1]: *** [src/src_connmand-tethering.o] Error 1
>>
>>
>> So I'm not sure it's the right one...

This is not a new issue.  In addition to this,
netinet/in.h also conflits with linux/in.h.

We might have
 #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
 :
 #endif
around those conflicting definitions in uapi/linux/in{,6}.h.

--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: Redefinition of struct in6_addr in netinet/in.h and linux/in6.h

[YOSHIFUJI Hideaki]

Cong Wang wrote:
 (Cc'ing some glibc developers...)
 
 Hello,
 
 In glibc source file inet/netinet/in.h and kernel source file
 include/uapi/linux/in6.h, both define struct in6_addr, and both are
 visible to user applications. Thomas reported a conflict below.
 
 So, how can we handle this? /me is wondering why we didn't see this
 before.
 
 Thanks.
 
 On Tue, 2013-01-15 at 12:55 +0200, Thomas Backlund wrote:
 Cong Wang skrev 15.1.2013 12:11:

 Does the following patch help?

 $ git diff include/uapi/linux/if_bridge.h
 diff --git a/include/uapi/linux/if_bridge.h
 b/include/uapi/linux/if_bridge.h
 index 5db2975..653db23 100644
 --- a/include/uapi/linux/if_bridge.h
 +++ b/include/uapi/linux/if_bridge.h
 @@ -14,6 +14,7 @@
   #define _UAPI_LINUX_IF_BRIDGE_H

   #include linux/types.h
 +#include linux/in6.h

   #define SYSFS_BRIDGE_ATTR  bridge
   #define SYSFS_BRIDGE_FDB   brforward


 Well, I suggested the same fix in the beginning of the thread
 on netdev and lkml: if_bridge.h: include in6.h for struct in6_addr use

 as it seemed to fix the libvirt case

 but then asked it to be ignored after I tried to build connman,
 and hit this conflict with glibc-2.17:

 In file included from /usr/include/arpa/inet.h:22:0,
   from ./include/connman/inet.h:25,
   from src/connman.h:128,
   from src/tethering.c:40:
 /usr/include/netinet/in.h:35:5: error: expected identifier before 
 numeric constant
 /usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
 In file included from /usr/include/linux/if_bridge.h:17:0,
   from src/tethering.c:38:
 /usr/include/linux/in6.h:30:8: note: originally defined here
 In file included from /usr/include/arpa/inet.h:22:0,
   from ./include/connman/inet.h:25,
   from src/connman.h:128,
   from src/tethering.c:40:
 /usr/include/netinet/in.h:238:8: error: redefinition of 'struct 
 sockaddr_in6'
 In file included from /usr/include/linux/if_bridge.h:17:0,
   from src/tethering.c:38:
 /usr/include/linux/in6.h:46:8: note: originally defined here
 In file included from /usr/include/arpa/inet.h:22:0,
   from ./include/connman/inet.h:25,
   from src/connman.h:128,
   from src/tethering.c:40:
 /usr/include/netinet/in.h:274:8: error: redefinition of 'struct ipv6_mreq'
 In file included from /usr/include/linux/if_bridge.h:17:0,
   from src/tethering.c:38:
 /usr/include/linux/in6.h:54:8: note: originally defined here
 make[1]: *** [src/src_connmand-tethering.o] Error 1


 So I'm not sure it's the right one...

This is not a new issue.  In addition to this,
netinet/in.h also conflits with linux/in.h.

We might have
 #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
 :
 #endif
around those conflicting definitions in uapi/linux/in{,6}.h.

--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: Redefinition of struct in6_addr in netinet/in.h and linux/in6.h

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
 diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
 index f79c372..a2b16a5 100644
 --- a/include/uapi/linux/in6.h
 +++ b/include/uapi/linux/in6.h
:
  #define IPV6_PRIORITY_14 0x0e00
  #define IPV6_PRIORITY_15 0x0f00
  
 +
 +#ifndef _NETINET_IN_H
 +#if defined (__GLIBC__)
 +/* Include all of the other IPPROTO_* defines for userspace. */
 +#include linux/ipproto.h
 +#endif
  /*
   *   IPV6 extension headers

Overall, it looks good, but why including linux/ipproto.h?

--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: Redefinition of struct in6_addr in netinet/in.h and linux/in6.h

[YOSHIFUJI Hideaki]

Carlos O'Donell wrote:
 diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
 index f79c372..a2b16a5 100644
 --- a/include/uapi/linux/in6.h
 +++ b/include/uapi/linux/in6.h
 @@ -23,6 +23,13 @@
  
  #include linux/types.h
  
 +/* If a glibc-based userspace has already included in.h, then we will not 
 + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
 + * ABI used by the kernel and by glibc match exactly. Neither the kernel
 + * nor glibc should break this ABI without coordination.
 + */
 +#ifndef _NETINET_IN_H
 +
  /*
   *   IPv6 address structure
   */

This should be
#if !defined(__GLIBC__) || !defined(_NETINET_IN_H)

 @@ -30,12 +37,20 @@
  struct in6_addr {
   union {
   __u8u6_addr8[16];
 +#if !defined(__GLIBC__) \
 +|| (defined(__GLIBC__)  (defined(__USE_MISC) || defined(__USE_GNU))) \
 +|| defined(__KERNEL__)
   __be16  u6_addr16[8];
   __be32  u6_addr32[4];
 +#endif
   } in6_u;
 +#if !defined(__GLIBC__) \
 +|| (defined(__GLIBC__)  (defined(__USE_MISC) || defined(__USE_GNU))) \
 +|| defined(__KERNEL__)
  #define s6_addr  in6_u.u6_addr8
  #define s6_addr16in6_u.u6_addr16
  #define s6_addr32in6_u.u6_addr32
 +#endif
  };

2nd if be after s6_addr?

--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 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route

[YOSHIFUJI Hideaki]

Romain KUNTZ wrote:
> From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001
> From: Romain Kuntz 
> Date: Wed, 9 Jan 2013 15:02:26 +0100
> Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
> 
> The tests on the flags in addrconf_get_prefix_route() does no make
> much sense: the 'noflags' parameter contains the set of flags that
> must not match with the route flags, so the test must be done
> against 'noflags', and not against 'flags'.
> 
> Signed-off-by: Romain Kuntz 
> ---
>  net/ipv6/addrconf.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 408cac4a..29ba4ff 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1877,7 +1877,7 @@ static struct rt6_info *addrconf_get_prefix_route(const 
> struct in6_addr *pfx,
>   continue;
>   if ((rt->rt6i_flags & flags) != flags)
>   continue;
> - if ((noflags != 0) && ((rt->rt6i_flags & flags) != 0))
> + if ((rt->rt6i_flags & noflags) != 0)
>       continue;
>   dst_hold(>dst);
>   break;
> 

Acked-by: YOSHIFUJI Hideaki 

--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 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route

[YOSHIFUJI Hideaki]

Romain KUNTZ wrote:
 From e7ece201c35615c44a3cfdc10ee28ad5a5878f41 Mon Sep 17 00:00:00 2001
 From: Romain Kuntz r.ku...@ipflavors.com
 Date: Wed, 9 Jan 2013 15:02:26 +0100
 Subject: [PATCH 1/1] ipv6: fix the noflags test in addrconf_get_prefix_route
 
 The tests on the flags in addrconf_get_prefix_route() does no make
 much sense: the 'noflags' parameter contains the set of flags that
 must not match with the route flags, so the test must be done
 against 'noflags', and not against 'flags'.
 
 Signed-off-by: Romain Kuntz r.ku...@ipflavors.com
 ---
  net/ipv6/addrconf.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
 index 408cac4a..29ba4ff 100644
 --- a/net/ipv6/addrconf.c
 +++ b/net/ipv6/addrconf.c
 @@ -1877,7 +1877,7 @@ static struct rt6_info *addrconf_get_prefix_route(const 
 struct in6_addr *pfx,
   continue;
   if ((rt-rt6i_flags  flags) != flags)
   continue;
 - if ((noflags != 0)  ((rt-rt6i_flags  flags) != 0))
 + if ((rt-rt6i_flags  noflags) != 0)
   continue;
   dst_hold(rt-dst);
   break;
 

Acked-by: YOSHIFUJI Hideaki yoshf...@linux-ipv6.org

--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: [IPv6] crashed when __ip6_del_rt()

[YOSHIFUJI Hideaki]

stanley zhou wrote:

> when call write_lock_bh() table is null cause crash in __ip6_del_rt().
> kernel version is 2.6.30.10
:
> static int __ip6_del_rt(struct rt6_info *rt, struct nl_info *info)
> {
> int err;
> struct fib6_table *table;
> struct net *net = dev_net(rt->rt6i_dev);
> 
> if (rt == net->ipv6.ip6_null_entry) {
> +++err = -ENOENT;
> +++goto out;
> --- return -ENOENT;
> }
> 
> table = rt->rt6i_table;
> write_lock_bh(>tb6_lock);
> err = fib6_del(rt, info);
> write_unlock_bh(>tb6_lock);
> +++out:
> dst_release(>u.dst);
> return err;
> } 
>  

I think this is what commit 6825a26c ("ipv6: release reference of
ip6_null_entry's dst entry in __ip6_del_rt") by Gao feng
 does, which is already in v3.7.

Are you suggesting that we should have this in -stable tree as well?

--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: [IPv6] crashed when __ip6_del_rt()

[YOSHIFUJI Hideaki]

stanley zhou wrote:

 when call write_lock_bh() table is null cause crash in __ip6_del_rt().
 kernel version is 2.6.30.10
:
 static int __ip6_del_rt(struct rt6_info *rt, struct nl_info *info)
 {
 int err;
 struct fib6_table *table;
 struct net *net = dev_net(rt-rt6i_dev);
 
 if (rt == net-ipv6.ip6_null_entry) {
 +++err = -ENOENT;
 +++goto out;
 --- return -ENOENT;
 }
 
 table = rt-rt6i_table;
 write_lock_bh(table-tb6_lock);
 err = fib6_del(rt, info);
 write_unlock_bh(table-tb6_lock);
 +++out:
 dst_release(rt-u.dst);
 return err;
 } 
  

I think this is what commit 6825a26c (ipv6: release reference of
ip6_null_entry's dst entry in __ip6_del_rt) by Gao feng
gaof...@cn.fujitsu.com does, which is already in v3.7.

Are you suggesting that we should have this in -stable tree as well?

--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/