Re: Off-by-one bug at unix_mkname ?

2005-03-28 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 11:25:39 +0200 (MEST)), Jan 
(BEngelhardt <[EMAIL PROTECTED]> says:
(B
(B> 
(B> On Mar 28 2005 17:39, YOSHIFUJI Hideaki / [EMAIL PROTECTED](B wrote:
(B> 
(B> >+ *  This may look like an off by one error but it is
(B> >+ *  a bit more subtle. 108 is the longest valid AF_UNIX
(B> >+ *  path for a binding. sun_path[108] doesnt as such
(B> >+ *  exist. However in kernel space we are guaranteed that
(B> >+ *  it is a valid memory location in our kernel
(B> >+ *  address buffer.
(B> >+ */
(B> 
(B> Now, does 2.6. _still_ guarantee that 108 is a valid offset?
(B
(BYes, it does.
(B
(B--yoshfuji
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: Off-by-one bug at unix_mkname ?

2005-03-28 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 17:39:38 +0900 (JST)), 
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> So, I'd suggest to put the comment back to 2.4/2.6 instead.
(B> (Note: net/socket.c refers this around MAX_SOCK_ADDR definition.)
(B> 
(B> Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(BOops, sorry, I made a mistake when I did copy-n-paste...
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/unix/af_unix.c 1.73 vs edited =
(B--- 1.73/net/unix/af_unix.c 2005-03-10 13:42:53 +09:00
(B+++ edited/net/unix/af_unix.c   2005-03-28 17:45:26 +09:00
(B@@ -188,6 +188,14 @@
(Bif (!sunaddr || sunaddr->sun_family != AF_UNIX)
(Breturn -EINVAL;
(Bif (sunaddr->sun_path[0]) {
(B+   /*
(B+*  This may look like an off by one error but it is
(B+*  a bit more subtle. 108 is the longest valid AF_UNIX
(B+*  path for a binding. sun_path[108] doesnt as such
(B+*  exist. However in kernel space we are guaranteed that
(B+*  it is a valid memory location in our kernel
(B+*  address buffer.
(B+*/
(B((char *)sunaddr)[len]=0;
(Blen = strlen(sunaddr->sun_path)+1+sizeof(short);
(Breturn len;
(B
(B-- 
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: Off-by-one bug at unix_mkname ?

2005-03-28 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 17:21:08 +0900 (JST)), 
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> > It seems to me that the following code is off-by-one bug.
(B:
(B> Well, 2.2 has some comment on this:
(B
(BSo, I'd suggest to put the comment back to 2.4/2.6 instead.
(B(Note: net/socket.c refers this around MAX_SOCK_ADDR definition.)
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/unix/af_unix.c 1.73 vs edited =
(B--- 1.73/net/unix/af_unix.c 2005-03-10 13:42:53 +09:00
(B+++ edited/net/unix/af_unix.c   2005-03-28 17:31:33 +09:00
(B@@ -188,6 +188,15 @@
(Bif (!sunaddr || sunaddr->sun_family != AF_UNIX)
(Breturn -EINVAL;
(Bif (sunaddr->sun_path[0]) {
(B+   /*
(B+*  This may look like an off by one error but it is
(B+*  a bit more subtle. 108 is the longest valid AF_UNIX
(B+*  path for a binding. sun_path[108] doesnt as such
(B+*  exist. However in kernel space we are guaranteed that
(B+*  it is a valid memory location in our kernel
(B+*  address buffer.
(B+*/
(B+   if (len > sizeof(*sunaddr))
(B((char *)sunaddr)[len]=0;
(Blen = strlen(sunaddr->sun_path)+1+sizeof(short);
(Breturn len;
(B
(B-- 
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: Off-by-one bug at unix_mkname ?

2005-03-28 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 28 Mar 2005 17:00:05 +0900), Tetsuo 
Handa <[EMAIL PROTECTED]> says:

> It seems to me that the following code is off-by-one bug.
> 
> http://lxr.linux.no/source/net/unix/af_unix.c#L191
> http://lxr.linux.no/source/net/unix/af_unix.c?v=2.4.28#L182
> 
> I think
> ((char *)sunaddr)[len]=0;
> should be
> ((char *)sunaddr)[len-1]=0;

Well, 2.2 has some comment on this:

static int unix_mkname(struct sockaddr_un * sunaddr, int len, unsigned *hashp)
{
if (len <= sizeof(short) || len > sizeof(*sunaddr))
return -EINVAL;
:
if (sunaddr->sun_path[0])
{
/*
 *  This may look like an off by one error but it is
 *  a bit more subtle. 108 is the longest valid AF_UNIX
 *  path for a binding. sun_path[108] doesnt as such
 *  exist. However in kernel space we are guaranteed that
 *  it is a valid memory location in our kernel
 *  address buffer.
 */
if (len > sizeof(*sunaddr))
len = sizeof(*sunaddr);
((char *)sunaddr)[len]=0;
len = strlen(sunaddr->sun_path)+1+sizeof(short);
return len;
}
:

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

[PATCH] [IPV6] Fix address/interface handling according to the scoping architecture (is Re: 2.6.11: USB broken on nforce4, ipv6 still broken, centrino speedstep even more broken than in 2.6.10)

2005-03-24 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Fri, 11 Mar 2005 17:33:08 -0800), Andrew 
Morton <[EMAIL PROTECTED]> says:

> Felix von Leitner <[EMAIL PROTECTED]> wrote:
> >
> > Now about IPv6: npush and npoll are two applications I wrote.  npush
> > sends multicast announcements and opens a TCP socket.  npoll receives
> > the multicast announcement and connects to the source IP/port/scope_id
> > of the announcement.  If both are run on the same machine, npoll sees
> > the link local address of eth0 as source IP, and the interface number of
> > eth0 as scope_id.  So far so good.  Trying to connect() however hangs.
> > Since this has been broken in different ways for as long as I can
> > remember in Linux, and I keep complaining about it every half a year or
> > so.  Can't someone fix this once and for all?  IPv4 checks whether we
> > are connecting to our own address and reroutes through loopback, why
> > can't IPv6?

I think this has been there for long time (maybe since 2.4...).

With the following patch, I can connect local link-local address.
- Change incoming interface according to the scoping architecture
- Choose source address on appropriate interface, according to the
  scoping architecture.

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

= net/ipv6/ip6_input.c 1.23 vs edited =
--- 1.23/net/ipv6/ip6_input.c   2005-03-10 14:12:11 +09:00
+++ edited/net/ipv6/ip6_input.c 2005-03-24 17:49:15 +09:00
@@ -71,10 +71,18 @@
goto out;
}
 
-   /* Store incoming device index. When the packet will
-  be queued, we cannot refer to skb->dev anymore.
+   /*
+* Store incoming device index. When the packet will
+* be queued, we cannot refer to skb->dev anymore.
+* 
+* BTW, when we send a packet for our own local address on a
+* non-loopback interface (e.g. ethX), it is being delivered
+* via the loopback interface (lo) here; skb->dev = &loopback_dev.
+* It, however, should be considered as if it is being
+* arrived via the sending interface (ethX), because of the
+* nature of scoping architecture. --yoshfuji
 */
-   IP6CB(skb)->iif = dev->ifindex;
+   IP6CB(skb)->iif = skb->dst ? ((struct rt6_info 
*)skb->dst)->rt6i_idev->dev->ifindex : dev->ifindex;
 
if (skb->len < sizeof(struct ipv6hdr))
goto err;
= net/ipv6/addrconf.c 1.134 vs edited =
--- 1.134/net/ipv6/addrconf.c   2005-03-15 14:21:11 +09:00
+++ edited/net/ipv6/addrconf.c  2005-03-24 11:52:17 +09:00
@@ -942,7 +942,7 @@
 int ipv6_get_saddr(struct dst_entry *dst,
   struct in6_addr *daddr, struct in6_addr *saddr)
 {
-   return ipv6_dev_get_saddr(dst ? dst->dev : NULL, daddr, saddr);
+   return ipv6_dev_get_saddr(dst ? ((struct rt6_info 
*)dst)->rt6i_idev->dev : NULL, daddr, saddr);
 }
 
 

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

Re: [PATCH] don't do pointless NULL checks and casts before kfree() in security/

2005-03-20 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sun, 20 Mar 2005 13:31:43 +), Ralph 
Corderoy <[EMAIL PROTECTED]> says:

> > the short version also have the real bennefits of generating shorter
> > and faster code as well as being shorter "on-screen".
> 
> Faster code?  I'd have thought avoiding the function call outweighed the
> overhead of checking before calling.

Modern CPU can run nicely (expecially with register parameters).
Even if even matters, we can check inline like this:

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

= include/linux/slab.h 1.40 vs edited =
--- 1.40/include/linux/slab.h   2005-03-12 05:32:31 +09:00
+++ edited/include/linux/slab.h 2005-03-20 22:47:57 +09:00
@@ -106,8 +106,17 @@
 }
 
 extern void *kcalloc(size_t, size_t, int);
-extern void kfree(const void *);
+extern void __kfree(const void *);
 extern unsigned int ksize(const void *);
+
+static inline void kfree(const void *p)
+{
+#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
+   if (!p)
+   return;
+#endif
+   __kfree(p);
+}
 
 extern int FASTCALL(kmem_cache_reap(int));
 extern int FASTCALL(kmem_ptr_validate(kmem_cache_t *cachep, void *ptr));
= mm/slab.c 1.156 vs edited =
--- 1.156/mm/slab.c 2005-03-10 17:38:21 +09:00
+++ edited/mm/slab.c2005-03-20 22:42:45 +09:00
@@ -2561,7 +2561,7 @@
 EXPORT_SYMBOL(kcalloc);
 
 /**
- * kfree - free previously allocated memory
+ * __kfree - free previously allocated memory
  * @objp: pointer returned by kmalloc.
  *
  * Don't free memory not originally allocated by kmalloc()
@@ -2572,8 +2572,10 @@
kmem_cache_t *c;
unsigned long flags;
 
+#ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
if (!objp)
return;
+#endif
local_irq_save(flags);
kfree_debugcheck(objp);
c = GET_PAGE_CACHE(virt_to_page(objp));
@@ -2581,7 +2583,7 @@
local_irq_restore(flags);
 }
 
-EXPORT_SYMBOL(kfree);
+EXPORT_SYMBOL(__kfree);
 
 #ifdef CONFIG_SMP
 /**
-
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] net, ipv6: remove redundant NULL checks before kfree in ip6_flowlabel.c

2005-03-16 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Thu, 17 Mar 2005 00:36:35 +0100 (CET)), 
Jesper Juhl <[EMAIL PROTECTED]> says:

> I considered also rewriting the 
> if (fl)
> fl_free(fl);
> bit as simply fl_free(fl) as well, but that if() potentially saves two 
> calls to kfree() inside fl_free as well as the call to fl_free itself, so 
> I guess that's worth the if().

I don't mind calling kfree twice itself (because that function is not
so performance critical), but fl_free(NULL) is out because
if fl is NULL, kfree(fl->opt) is out.

So, what do you think of checking fl inside fl_free like this?

We can even make fl_free inline and check as following:
  if (fl) {
kfree(fl->opt);
kfree(fl);
  }

Based on patch from Jesper Juhl <[EMAIL PROTECTED]>.

David?

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

= net/ipv6/ip6_flowlabel.c 1.18 vs edited =
--- 1.18/net/ipv6/ip6_flowlabel.c   2005-01-14 13:41:06 +09:00
+++ edited/net/ipv6/ip6_flowlabel.c 2005-03-17 11:23:32 +09:00
@@ -87,7 +87,7 @@
 
 static void fl_free(struct ip6_flowlabel *fl)
 {
-   if (fl->opt)
+   if (fl)
kfree(fl->opt);
kfree(fl);
 }
@@ -351,8 +351,7 @@
return fl;
 
 done:
-   if (fl)
-   fl_free(fl);
+   fl_free(fl);
*err_p = err;
return NULL;
 }
@@ -551,10 +550,8 @@
}
 
 done:
-   if (fl)
-   fl_free(fl);
-   if (sfl1)
-   kfree(sfl1);
+   fl_free(fl);
+   kfree(sfl1);
return err;
 }
 

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

BK Snapshots (Re: where did 2.6.11-bkx go?)

2005-03-15 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Tue, 15 Mar 2005 13:28:26 -0500), sean 
<[EMAIL PROTECTED]> says:

> pub/mirrors/linux/kernel/linux/kernel/v2.6/snapshots
> 
> Now there just the 2.6.11.x snapshots.
> 
> For instance where is bk10?

Now 2.6.11.3-bk1 has come up...

The bk-snap script seems to be scewed up by the v2.6.11.3 tag.
It'd very nice to see 2.6.11-bk11 instead.
Current naming is very confusing; e.g. is this patch against 2.6.11.3?

--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: select() doesn't respect SO_RCVLOWAT ?

2005-03-14 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 14 Mar 2005 13:24:24 +), Alan Cox 
<[EMAIL PROTECTED]> says:

> 1003.1g both agree with your expectations. The right list is probably
> netdev@oss.sgi.com however.

I've just forwarded this thread to netdev.

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

Re: ipv6 and ipv4 interaction weirdness

2005-03-11 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Fri, 11 Mar 2005 23:16:55 +1100), CaT 
<[EMAIL PROTECTED]> says:

> If it bound to :: port 22 then 0.0.0.0:22 would fail.
> 
> On the other hand if I got it to bind to each address individually then
> both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed.
> 
> Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere
> with each other?

It is 100% intended, even it is not similar to BSD variants do.

IPv4 and IPv6 share address/port space.
:: and 0.0.0.0 is special "any" address, thus they confict.
:::a.b.c.d and a.b.c.d also conflict.

--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/1] /proc/$$/ipaddr and per-task networking bits

2005-03-10 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Thu, 10 Mar 2005 15:16:42 +0100), Lorenzo 
Hernández García-Hierro <[EMAIL PROTECTED]> says:

> Ported feature from grSecurity that makes possible to add an ipaddr
> entry in each /proc/ (/proc//ipaddr), where the task originating
> IP address is stored, and subsequently made available (readable) by the 
> process
> itself and also the root user with CAP_DAC_OVERRIDE capability (that can be 
> managed
> by specific security models implementations like SELinux).
> Available also at http://pearls.tuxedo-es.org/patches/task-curr_ip.patch

Please don't.

You already can get this information via procfs; e.g. lsof does,
It does support IPv6 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: RFD: Kernel release numbering

2005-03-02 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Wed, 2 Mar 2005 19:37:44 -0800 (PST)), Linus 
Torvalds <[EMAIL PROTECTED]> says:

> In contrast, making it a real release, and making it clear that it's a 
> release in its own right, might actually get people to use it. 
> 
> Might. Maybe.

I believe people soon stop using 2.6. "release"s.

--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: RFD: Kernel release numbering

2005-03-02 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Wed, 2 Mar 2005 16:58:30 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> All this "I have to hold onto my backlog longer, WAHHH!" arguments are bogus
> IMHO.  We're using a week of quiescence to fix the tree for users so they
> are happy whilst we work on the 2.6.${odd} interesting stuff :-)

I'm afarid people start waiting 2.6.${even} releases...

--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: bkbits.net down?

2005-03-01 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Tue, 1 Mar 2005 08:54:15 -0800), [EMAIL 
PROTECTED] (Larry McVoy) says:

> No, sorry.  We're working on the tarball+patch server we talked about about
> a couple years back and I screwed up the http server.  The bk:// urls work,
> please use them until I fix this, should be quick.

Okay, thanks. But bk:// urls does not seem to work, unfortunately.

|% bk pull
|Pull bk://linux.bkbits.net:8080/linux-2.5
|  -> file://home2/yoshfuji/BitKeeper/linux-2.6
|% 

No message like "nothing to pull."

Anyway, it's time to sleep for me. ZZZzzz...

> 
> On Wed, Mar 02, 2005 at 01:00:10AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ 
> wrote:
> > Hello.
> > 
> > *.bkbits.net (port 8080) seems to reply with no data.
> > And "bk pull" on linux-2.5 also fails.
> > Is this scheduled?
> > 
> > Thank you.
> > 
> > --yoshfuji
> 
> -- 
> ---
> Larry McVoylm at bitmover.com   
> http://www.bitkeeper.com
-
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/

bkbits.net down?

2005-03-01 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
Hello.

*.bkbits.net (port 8080) seems to reply with no data.
And "bk pull" on linux-2.5 also fails.
Is this scheduled?

Thank you.

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

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

2005-02-26 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian 
Bunk <[EMAIL PROTECTED]> says:


> +
> +What:EXPORT_SYMBOL(do_settimeofday)
> +When:26 Aug 2005
   ~~~ Feb?
> +Files:   arch/*/kernel/time.c
> +Why: not used in the kernel
> +Who: Adrian Bunk <[EMAIL PROTECTED]>

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

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

2005-02-26 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 26 Feb 2005 22:37:42 +0900 (JST)), 
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> In article <[EMAIL PROTECTED]> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian 
(B> Bunk <[EMAIL PROTECTED]> says:
(B> 
(B> 
(B> > +
(B> > +What:  EXPORT_SYMBOL(do_settimeofday)
(B> > +When:  26 Aug 2005
(B>~~~ Feb?
(B> > +Files: arch/*/kernel/time.c
(B> > +Why:   not used in the kernel
(B> > +Who:   Adrian Bunk <[EMAIL PROTECTED]>
(B
(Boops, I was wrong. This is schedule. sorry.
(B
(B--yoshfuji
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-06 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sun, 6 Feb 2005 22:41:45 +1100), Herbert Xu 
<[EMAIL PROTECTED]> says:

> On Sat, Feb 05, 2005 at 09:45:59PM +1100, herbert wrote:
> > 
> > Although I still think this is a bug, I'm now starting to suspect
> > that there is another bug around as well.
> > 
> > There is probably an ifp leak which in turn leads to a split dst
> > leak that allows the first bug to make its mark.
> 
> Found it.  This is what happens:
> 
> lo goes down =>
>   rt6_ifdown =>
>   eth0's local address route gets deleted
> 
> eth0 goes down =>
>   __ipv6_ifa_notify =>
>   ip6_del_rt fails so we fall through to the
>   dst_free path.  At this point the refcount
>   taken by __ipv6_ifa_notify is leaked.

Oh, you're right! Thanks.

How about this; Ignore entries addrconf_dst_alloc'ed entries in rt6_ifdown()?

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

= include/linux/ipv6_route.h 1.6 vs edited =
--- 1.6/include/linux/ipv6_route.h  2004-10-26 12:54:23 +09:00
+++ edited/include/linux/ipv6_route.h   2005-02-06 21:27:02 +09:00
@@ -26,6 +26,7 @@
 #define RTF_FLOW   0x0200  /* flow significant route   */
 #define RTF_POLICY 0x0400  /* policy route */
 
+#define RTF_ANYCAST0x4000
 #define RTF_LOCAL  0x8000
 
 struct in6_rtmsg {
= net/ipv6/route.c 1.105 vs edited =
--- 1.105/net/ipv6/route.c  2005-01-15 17:44:48 +09:00
+++ edited/net/ipv6/route.c 2005-02-06 21:26:35 +09:00
@@ -1408,7 +1408,9 @@
rt->u.dst.obsolete = -1;
 
rt->rt6i_flags = RTF_UP | RTF_NONEXTHOP;
-   if (!anycast)
+   if (anycast)
+   rt->rt6i_flags |= RTF_ANYCAST;
+   else
rt->rt6i_flags |= RTF_LOCAL;
rt->rt6i_nexthop = ndisc_get_neigh(rt->rt6i_dev, &rt->rt6i_gateway);
if (rt->rt6i_nexthop == NULL) {
@@ -1427,7 +1429,8 @@
 static int fib6_ifdown(struct rt6_info *rt, void *arg)
 {
if (((void*)rt->rt6i_dev == arg || arg == NULL) &&
-   rt != &ip6_null_entry) {
+   rt != &ip6_null_entry &&
+   !(rt->rt6i_flags & (RTF_LOCAL|RTF_ANYCAST))) {
RT6_TRACE("deleted by ifdown %p\n", rt);
return -1;
}

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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-06 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sun, 06 Feb 2005 11:55:19 +0100), Andre Tomt 
<[EMAIL PROTECTED]> says:

> I'm contemplating just using it as a quick-fix until 2.6.11 to get this 
> problem under control.

Would you find if my patch works? 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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sun, 06 Feb 2005 14:31:07 +0900 (JST)), 
(BYOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> says:
(B
(B> The source of problem is entry (*) which still on routing entry,
(B> not on gc list. And, the owner of entry is not routing table but
(B> unicast/anycast address structure(s).
(B> We need to "kill" active address on the other interfaces.
(B
(BWhich means in addrconf_notiry(), if the dev == &loopback_dev,
(Bcall addrconf_ifdown for every device like this:
(B
(BSigned-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
(B
(B= net/ipv6/addrconf.c 1.129 vs edited =
(B--- 1.129/net/ipv6/addrconf.c   2005-01-18 06:13:31 +09:00
(B+++ edited/net/ipv6/addrconf.c  2005-02-06 14:48:25 +09:00
(B@@ -1961,6 +1961,20 @@
(Bcase NETDEV_DOWN:
(Bcase NETDEV_UNREGISTER:
(B/*
(B+* If lo is doing down we need to kill
(B+* all addresses on the host because it owns
(B+* route on lo. --yoshfuji
(B+*/
(B+   if (dev == &loopback_dev) {
(B+   struct net_device *dev1;
(B+   for (dev1 = dev_base; dev1; dev1 = dev->next) {
(B+   if (dev1 == &loopback_dev ||
(B+   __in6_dev_get(dev1) == NULL)
(B+   continue;
(B+   addrconf_ifdown(dev1, event != NETDEV_DOWN);
(B+   }
(B+   }
(B+   /*
(B *  Remove all addresses from this interface.
(B */
(Baddrconf_ifdown(dev, event != NETDEV_DOWN);
(B
(B
(B-- 
(BHideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
(BGPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 21:04:11 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> On Sun, 06 Feb 2005 13:37:23 +0900 (JST)
> YOSHIFUJI Hideaki / [EMAIL PROTECTED](B <[EMAIL PROTECTED]> wrote:
> 
> > How about making dst->ops->dev_check() like this:
> > 
> > static int inline dst_dev_check(struct dst_entry *dst, struct net_device 
> > *dev)
> > {
> > if (dst->ops->dev_check)
> > return dst->ops->dev_check(dst, dev)
> > else
> > return dst->dev == dev;
> > }
> 
> Oh I see.  That would work, and it seems the simplest, and
> lowest risk fix for this problem.

Well...

Here, lo is going down.
rt->rt6i_dev = lo and rt->rt6i_idev = ethX.
I think we already see dst->dev == dev (==lo)  now.
So, I doubt that fix the problem.

The source of problem is entry (*) which still on routing entry,
not on gc list. And, the owner of entry is not routing table but
unicast/anycast address structure(s).
We need to "kill" active address on the other interfaces.

*: rt->rt6i_dev = lo and rt->rt6i_idev = ethX


BTW, I wish we could shut down eth0 during lo is pending...

--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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:02:42 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> > Yes, IPv6 needs "split device" semantics
> > (for per-device statistics such as Ip6InDelivers etc),
> > and I like later solution.
> 
> Ok.  I never read whether ipv6, like ipv4, is specified to support
> a model of host based ownership of addresses.  Does anyone know?

I'm not sure it is explicitly specified, but there're some hints:

1. we need to allow multiple addresses on multiple interfaces.
   e.g. link-local address

2. if a packet has come from A to link-local address on the other side B,
   we should not receive it.
 +---+
>|A B|
 +---+

   Currently, it does not happen in usual because ndisc does NOT handle
   addresses on other device.

3. mib document states that we should take statistics on interface which 
   the address belongs to; not the interface where the packet has come
   from:

cited from RFC2011bis:
Local (*) packets on the input side are counted on the interface
associated with their destination address, which may not be the
interface on which they were received.  This requirement is caused by
the possibility of losing the original interface during processing,
especially re-assembly.

(*): here it means incoming, but not forwarding.


BTW, BSD has similar reference to interface structure in routeing entry.

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

Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 20:10:44 -0800), "David S. 
Miller" <[EMAIL PROTECTED]> says:

> > Alternatively we can
> > remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> > and move that test down to the individual ifdown functions.
> 
> I think there is a hole in this idea maybe.
> 
> If the idea is to scan dst_garbage_list down in ipv6 specific code,
> you can't do that since 'dst' objects from every pool in the kernel
> get put onto the dst_garbage_list.   It is generic.

How about making dst->ops->dev_check() like this:

static int inline dst_dev_check(struct dst_entry *dst, struct net_device *dev)
{
if (dst->ops->dev_check)
return dst->ops->dev_check(dst, dev)
else
return dst->dev == dev;
}

--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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 05 Feb 2005 12:48:15 +0100), Andre Tomt 
<[EMAIL PROTECTED]> says:

> > Please tell me, why your lo is down...
:
> "ifdown -a" gets run on shutdown and reboot here, and ifdown -a in 
> Debian brings down loopback before any other interfaces.

Okay, thanks. (I now remember someone told me this before.) hmm...

--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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 05 Feb 2005 12:14:04 +0100), Andre Tomt 
<[EMAIL PROTECTED]> says:

> This patch fixes my problems with hangs when dot1q VLAN interfaces gets 
> removed when loopback is down, as reported in the thread "2.6.10 
> ipv6/8021q lockup on vconfig on interface removal".

Please tell me, why your lo is down...

Anyway, if we really want to "fix" this,
we should do in other way.

I think "Make loopback idev stick around" patches
(for IPv4 and IPv6) could be start of that.

--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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)

2005-02-05 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 5 Feb 2005 17:46:43 +1100), Herbert Xu 
<[EMAIL PROTECTED]> says:

> If we wanted to preserve the split device semantics, then we
> can create a local GC list in IPv6 so that it can search based
> on rt6i_idev as well as the other keys.  Alternatively we can
> remove the dst->dev == dev check in dst_dev_event and dst_ifdown
> and move that test down to the individual ifdown functions.

Yes, IPv6 needs "split device" semantics
(for per-device statistics such as Ip6InDelivers etc),
and I like later solution.

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: Memory leak in 2.6.11-rc1?

2005-01-30 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 31 Jan 2005 06:00:40 +0100), Patrick 
McHardy <[EMAIL PROTECTED]> says:

|We don't need this for IPv6 yet. Once we get nf_conntrack in we
|might need this, but its IPv6 fragment handling is different from
|ip_conntrack, I need to check first.

Ok. It would be better to have some comment but anyway...
kozakai-san?

--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: Memory leak in 2.6.11-rc1?

2005-01-30 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Mon, 31 Jan 2005 15:11:32 +1100), Herbert Xu 
<[EMAIL PROTECTED]> says:

> Patrick McHardy <[EMAIL PROTECTED]> wrote:
> > 
> > Ok, final decision: you are right :) conntrack also defragments locally
> > generated packets before they hit ip_fragment. In this case the fragments
> > have skb->dst set.
> 
> Well caught.  The same thing is needed for IPv6, right?

(not yet confirmed, but) yes, please.

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

= net/ipv6/ip6_output.c 1.82 vs edited =
--- 1.82/net/ipv6/ip6_output.c  2005-01-25 09:40:10 +09:00
+++ edited/net/ipv6/ip6_output.c2005-01-31 13:44:01 +09:00
@@ -463,6 +463,7 @@
to->priority = from->priority;
to->protocol = from->protocol;
to->security = from->security;
+   dst_release(to->dst);
to->dst = dst_clone(from->dst);
to->dev = from->dev;
 

--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: multiple neighbour cache tables for AF_INET

2005-01-28 Thread YOSHIFUJI Hideaki / $B5HF#1QL@(B 
In article <[EMAIL PROTECTED]> (at Sat, 29 Jan 2005 09:19:49 +1100), Herbert Xu 
<[EMAIL PROTECTED]> says:

> IMHO you need to give the user a way to specify which table they want
> to operate on.  If they don't specify one, then the current behaviour
> of choosing the first table found is reasonble.

We have dev. Isn't is sufficient?

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