Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 > 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > >> YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: >> >> > Would you explain why it does not work properly >> > for those cases? >> >> Mostly no appropriate strategy routine was setup to >> report the data to the caller of sys_sysctl. > > I assume that default strategy have been existing for it, no?! > Maybe, I do miss something... I'd have to go through it case by case. But in general unless your proc_handler is proc_dointvec the default strategy routine which does a raw binary copy of your data out will generally do the wrong thing. So especially if your data is jiffies or otherwise needs processing you don't want to use the default strategy routine. Until relatively recently no one was really policing the sysctl interfaces and even now it isn't too serious. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: > > > Would you explain why it does not work properly > > for those cases? > > Mostly no appropriate strategy routine was setup to > report the data to the caller of sys_sysctl. I assume that default strategy have been existing for it, no?! Maybe, I do miss something... --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> writes: > Would you explain why it does not work properly > for those cases? Mostly no appropriate strategy routine was setup to report the data to the caller of sys_sysctl. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. : Well, retrans_time_ms and base_reachable_time_ms supercedes retrans_time and base_reachable_time, we've warned for long time for its deprecation. So, maybe, it is time to remove the old interfaces (retrans_time and base_reachable_time) and simplify ndisc_ifinfo_syctl_change(). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
Andrew Morton <[EMAIL PROTECTED]> writes: > But it is good to remove bad interfaces, if we possibly can. > > It is worth making the attempt. Does anyone know of anything which will > break? I fed NET_NEIGH_ANYCAST_DELAY at random into > http://www.google.com/codesearch and came up with nothing... My current policy is that since I could only find 5 real world linux programs that even call sys_sysctl, that if I find a broken sysctl binary interface I'm lazy and just remove it. The only networking one I know of is radvd. Added to that I just pushed an autochecking sysctl patch to Andrew that fails register_sysctl_table if the sysctl table is broken. And all of these showed up. So some fix was needed or things would have been even worse. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) > > > I disagree. It is bad to remove existing interface. > > Ditto for other patches. > > I think perhaps you misunderstand what Eric is doing. > > sys_sysctl() isn't working properly for these cases and it is both a > deprecated interface and not worth the pain of adding support > in these cases. Would you explain why it does not work properly for those cases? --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
On Fri, 10 Aug 2007 10:47:10 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> wrote: > Hello. > > In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL > PROTECTED] (Eric W. Biederman) says: > > > > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > > sysctl names for a function that works with proc. > > > > - In neighbour.c reorder the table to put the possibly unused entries > > at the end so we can remove them by terminating the table early. > > > > - In neighbour.c kill the entries with questionable binary sysctl > > handling behavior. > > > > - In neighbour.c if we don't have a strategy routine remove the > > binary path. So we don't the default sysctl strategy routine > > on data that is not ready for it. > > > > I disagree. It is bad to remove existing interface. But it is good to remove bad interfaces, if we possibly can. It is worth making the attempt. Does anyone know of anything which will break? I fed NET_NEIGH_ANYCAST_DELAY at random into http://www.google.com/codesearch and came up with nothing... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) > I disagree. It is bad to remove existing interface. > Ditto for other patches. I think perhaps you misunderstand what Eric is doing. sys_sysctl() isn't working properly for these cases and it is both a deprecated interface and not worth the pain of adding support in these cases. The fact that nobody complains that none of this stuff works via sys_sysctl() to me proves that it is never used. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
Hello. In article <[EMAIL PROTECTED]> (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: > > - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary > sysctl names for a function that works with proc. > > - In neighbour.c reorder the table to put the possibly unused entries > at the end so we can remove them by terminating the table early. > > - In neighbour.c kill the entries with questionable binary sysctl > handling behavior. > > - In neighbour.c if we don't have a strategy routine remove the > binary path. So we don't the default sysctl strategy routine > on data that is not ready for it. > I disagree. It is bad to remove existing interface. Ditto for other patches. Regards, --yoshfuji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] sysctl: Fix neighbour table sysctls.
- In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
sysctl names for a function that works with proc.
- In neighbour.c reorder the table to put the possibly unused entries
at the end so we can remove them by terminating the table early.
- In neighbour.c kill the entries with questionable binary sysctl
handling behavior.
- In neighbour.c if we don't have a strategy routine remove the
binary path. So we don't the default sysctl strategy routine
on data that is not ready for it.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/core/neighbour.c | 75 ++
net/ipv6/ndisc.c | 24 ++-
2 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index ca2a153..27c3f4e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2498,7 +2498,6 @@ static struct neigh_sysctl_table {
.proc_handler = _dointvec,
},
{
- .ctl_name = NET_NEIGH_RETRANS_TIME,
.procname = "retrans_time",
.maxlen = sizeof(int),
.mode = 0644,
@@ -2543,27 +2542,40 @@ static struct neigh_sysctl_table {
.proc_handler = _dointvec,
},
{
- .ctl_name = NET_NEIGH_ANYCAST_DELAY,
.procname = "anycast_delay",
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = _dointvec_userhz_jiffies,
},
{
- .ctl_name = NET_NEIGH_PROXY_DELAY,
.procname = "proxy_delay",
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = _dointvec_userhz_jiffies,
},
{
- .ctl_name = NET_NEIGH_LOCKTIME,
.procname = "locktime",
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = _dointvec_userhz_jiffies,
},
{
+ .ctl_name = NET_NEIGH_RETRANS_TIME_MS,
+ .procname = "retrans_time_ms",
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec_ms_jiffies,
+ .strategy = _ms_jiffies,
+ },
+ {
+ .ctl_name = NET_NEIGH_REACHABLE_TIME_MS,
+ .procname = "base_reachable_time_ms",
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec_ms_jiffies,
+ .strategy = _ms_jiffies,
+ },
+ {
.ctl_name = NET_NEIGH_GC_INTERVAL,
.procname = "gc_interval",
.maxlen = sizeof(int),
@@ -2592,22 +2604,7 @@ static struct neigh_sysctl_table {
.mode = 0644,
.proc_handler = _dointvec,
},
- {
- .ctl_name = NET_NEIGH_RETRANS_TIME_MS,
- .procname = "retrans_time_ms",
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = _dointvec_ms_jiffies,
- .strategy = _ms_jiffies,
- },
- {
- .ctl_name = NET_NEIGH_REACHABLE_TIME_MS,
- .procname = "base_reachable_time_ms",
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = _dointvec_ms_jiffies,
- .strategy = _ms_jiffies,
- },
+ {}
},
.neigh_dev = {
{
@@ -2660,42 +2657,48 @@ int neigh_sysctl_register(struct net_device *dev,
struct neigh_parms *p,
t->neigh_vars[9].data = >anycast_delay;
t->neigh_vars[10].data = >proxy_delay;
t->neigh_vars[11].data = >locktime;
+ t->neigh_vars[12].data = >retrans_time;
+ t->neigh_vars[13].data = >base_reachable_time;
if (dev) {
dev_name_source = dev->name;
t->neigh_dev[0].ctl_name = dev->ifindex;
- t->neigh_vars[12].procname = NULL;
- t->neigh_vars[13].procname = NULL;
-
[PATCH 04/10] sysctl: Fix neighbour table sysctls.
- In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary
sysctl names for a function that works with proc.
- In neighbour.c reorder the table to put the possibly unused entries
at the end so we can remove them by terminating the table early.
- In neighbour.c kill the entries with questionable binary sysctl
handling behavior.
- In neighbour.c if we don't have a strategy routine remove the
binary path. So we don't the default sysctl strategy routine
on data that is not ready for it.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
net/core/neighbour.c | 75 ++
net/ipv6/ndisc.c | 24 ++-
2 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index ca2a153..27c3f4e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2498,7 +2498,6 @@ static struct neigh_sysctl_table {
.proc_handler = proc_dointvec,
},
{
- .ctl_name = NET_NEIGH_RETRANS_TIME,
.procname = retrans_time,
.maxlen = sizeof(int),
.mode = 0644,
@@ -2543,27 +2542,40 @@ static struct neigh_sysctl_table {
.proc_handler = proc_dointvec,
},
{
- .ctl_name = NET_NEIGH_ANYCAST_DELAY,
.procname = anycast_delay,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_userhz_jiffies,
},
{
- .ctl_name = NET_NEIGH_PROXY_DELAY,
.procname = proxy_delay,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_userhz_jiffies,
},
{
- .ctl_name = NET_NEIGH_LOCKTIME,
.procname = locktime,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec_userhz_jiffies,
},
{
+ .ctl_name = NET_NEIGH_RETRANS_TIME_MS,
+ .procname = retrans_time_ms,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ .strategy = sysctl_ms_jiffies,
+ },
+ {
+ .ctl_name = NET_NEIGH_REACHABLE_TIME_MS,
+ .procname = base_reachable_time_ms,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies,
+ .strategy = sysctl_ms_jiffies,
+ },
+ {
.ctl_name = NET_NEIGH_GC_INTERVAL,
.procname = gc_interval,
.maxlen = sizeof(int),
@@ -2592,22 +2604,7 @@ static struct neigh_sysctl_table {
.mode = 0644,
.proc_handler = proc_dointvec,
},
- {
- .ctl_name = NET_NEIGH_RETRANS_TIME_MS,
- .procname = retrans_time_ms,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_ms_jiffies,
- .strategy = sysctl_ms_jiffies,
- },
- {
- .ctl_name = NET_NEIGH_REACHABLE_TIME_MS,
- .procname = base_reachable_time_ms,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_ms_jiffies,
- .strategy = sysctl_ms_jiffies,
- },
+ {}
},
.neigh_dev = {
{
@@ -2660,42 +2657,48 @@ int neigh_sysctl_register(struct net_device *dev,
struct neigh_parms *p,
t-neigh_vars[9].data = p-anycast_delay;
t-neigh_vars[10].data = p-proxy_delay;
t-neigh_vars[11].data = p-locktime;
+ t-neigh_vars[12].data = p-retrans_time;
+ t-neigh_vars[13].data = p-base_reachable_time;
if (dev) {
dev_name_source = dev-name;
t-neigh_dev[0].ctl_name = dev-ifindex;
- t-neigh_vars[12].procname = NULL;
- t-neigh_vars[13].procname
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
Hello. In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. - In neighbour.c reorder the table to put the possibly unused entries at the end so we can remove them by terminating the table early. - In neighbour.c kill the entries with questionable binary sysctl handling behavior. - In neighbour.c if we don't have a strategy routine remove the binary path. So we don't the default sysctl strategy routine on data that is not ready for it. I disagree. It is bad to remove existing interface. Ditto for other patches. Regards, --yoshfuji - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) I disagree. It is bad to remove existing interface. Ditto for other patches. I think perhaps you misunderstand what Eric is doing. sys_sysctl() isn't working properly for these cases and it is both a deprecated interface and not worth the pain of adding support in these cases. The fact that nobody complains that none of this stuff works via sys_sysctl() to me proves that it is never used. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
On Fri, 10 Aug 2007 10:47:10 +0900 (JST) YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] wrote: Hello. In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. - In neighbour.c reorder the table to put the possibly unused entries at the end so we can remove them by terminating the table early. - In neighbour.c kill the entries with questionable binary sysctl handling behavior. - In neighbour.c if we don't have a strategy routine remove the binary path. So we don't the default sysctl strategy routine on data that is not ready for it. I disagree. It is bad to remove existing interface. But it is good to remove bad interfaces, if we possibly can. It is worth making the attempt. Does anyone know of anything which will break? I fed NET_NEIGH_ANYCAST_DELAY at random into http://www.google.com/codesearch and came up with nothing... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes: Would you explain why it does not work properly for those cases? Mostly no appropriate strategy routine was setup to report the data to the caller of sys_sysctl. I assume that default strategy have been existing for it, no?! Maybe, I do miss something... --yoshfuji - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes: Would you explain why it does not work properly for those cases? Mostly no appropriate strategy routine was setup to report the data to the caller of sys_sysctl. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:56:09 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: - In ipv6 ndisc_ifinfo_syctl_change so it doesn't depend on binary sysctl names for a function that works with proc. : Well, retrans_time_ms and base_reachable_time_ms supercedes retrans_time and base_reachable_time, we've warned for long time for its deprecation. So, maybe, it is time to remove the old interfaces (retrans_time and base_reachable_time) and simplify ndisc_ifinfo_syctl_change(). --yoshfuji - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 18:49:21 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 10 Aug 2007 10:47:10 +0900 (JST) I disagree. It is bad to remove existing interface. Ditto for other patches. I think perhaps you misunderstand what Eric is doing. sys_sysctl() isn't working properly for these cases and it is both a deprecated interface and not worth the pain of adding support in these cases. Would you explain why it does not work properly for those cases? --yoshfuji - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
Andrew Morton [EMAIL PROTECTED] writes: But it is good to remove bad interfaces, if we possibly can. It is worth making the attempt. Does anyone know of anything which will break? I fed NET_NEIGH_ANYCAST_DELAY at random into http://www.google.com/codesearch and came up with nothing... My current policy is that since I could only find 5 real world linux programs that even call sys_sysctl, that if I find a broken sysctl binary interface I'm lazy and just remove it. The only networking one I know of is radvd. Added to that I just pushed an autochecking sysctl patch to Andrew that fails register_sysctl_table if the sysctl table is broken. And all of these showed up. So some fix was needed or things would have been even worse. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] sysctl: Fix neighbour table sysctls.
YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED] (at Thu, 09 Aug 2007 20:23:16 -0600), [EMAIL PROTECTED] (Eric W. Biederman) says: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] writes: Would you explain why it does not work properly for those cases? Mostly no appropriate strategy routine was setup to report the data to the caller of sys_sysctl. I assume that default strategy have been existing for it, no?! Maybe, I do miss something... I'd have to go through it case by case. But in general unless your proc_handler is proc_dointvec the default strategy routine which does a raw binary copy of your data out will generally do the wrong thing. So especially if your data is jiffies or otherwise needs processing you don't want to use the default strategy routine. Until relatively recently no one was really policing the sysctl interfaces and even now it isn't too serious. Eric - 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/
neighbour table overflow?
Could someone please explain the reason that this error would occur? I mean the root of the problem ie. what really causes it in the kernel? And then some common laymen reasons that it might be showing up on 2 of my machines that I use as routers? I have searched deja.com and found a few suggestions but nothing seemed to do any good. I get the same message on 2 machines of 3 that have had kernels 2.2.17, 2.2.18, and 2.4.1 on them - no matter what kernel I get the error. I have also tried playing musical network cards but no help there either. Thanks in advance. -- Jason Straight NMO.net Chief Network Engineer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
neighbour table overflow?
Could someone please explain the reason that this error would occur? I mean the root of the problem ie. what really causes it in the kernel? And then some common laymen reasons that it might be showing up on 2 of my machines that I use as routers? I have searched deja.com and found a few suggestions but nothing seemed to do any good. I get the same message on 2 machines of 3 that have had kernels 2.2.17, 2.2.18, and 2.4.1 on them - no matter what kernel I get the error. I have also tried playing musical network cards but no help there either. Thanks in advance. -- Jason Straight NMO.net Chief Network Engineer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: neighbour table?
"Eric W. Biederman" wrote: > > Be sure lo is established before eth0 and you won't see this message. > > Hmm. How does the interaction work. I've been meaning to track it for > a while but haven't yet. > > >From the cases I have observed it seems to be connected with arp requests > that aren't answered. (I.e when something is misconfigured and you try to nfsroot off > of the wrong ip on your subnet) > And I keep thinking neighbour table underflow would have been a better message. I'm not sure, I'm repeating what Alexey (iirc) has said in the past. I've been there/done that and sure enough making sure 'lo' is brought up first prevents that message. As to the NFS, no idea, I've never messed w/ nfsroot. -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: neighbour table?
David Ford <[EMAIL PROTECTED]> writes: > Andrew Park wrote: > > > I get a message > > > > neighbour table overflow > > > > What does that mean? It seems that > > > > net/ipv4/route.c > > > > is the place where it prints this. But under what circumstances > > does this happen? > > Thanks > > It means you set the link state of eth0 up before lo. > > Be sure lo is established before eth0 and you won't see this message. Hmm. How does the interaction work. I've been meaning to track it for a while but haven't yet. >From the cases I have observed it seems to be connected with arp requests that aren't answered. (I.e when something is misconfigured and you try to nfsroot off of the wrong ip on your subnet) And I keep thinking neighbour table underflow would have been a better message. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: neighbour table?
David Ford [EMAIL PROTECTED] writes: Andrew Park wrote: I get a message neighbour table overflow What does that mean? It seems that net/ipv4/route.c is the place where it prints this. But under what circumstances does this happen? Thanks It means you set the link state of eth0 up before lo. Be sure lo is established before eth0 and you won't see this message. Hmm. How does the interaction work. I've been meaning to track it for a while but haven't yet. From the cases I have observed it seems to be connected with arp requests that aren't answered. (I.e when something is misconfigured and you try to nfsroot off of the wrong ip on your subnet) And I keep thinking neighbour table underflow would have been a better message. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: neighbour table?
"Eric W. Biederman" wrote: Be sure lo is established before eth0 and you won't see this message. Hmm. How does the interaction work. I've been meaning to track it for a while but haven't yet. From the cases I have observed it seems to be connected with arp requests that aren't answered. (I.e when something is misconfigured and you try to nfsroot off of the wrong ip on your subnet) And I keep thinking neighbour table underflow would have been a better message. I'm not sure, I'm repeating what Alexey (iirc) has said in the past. I've been there/done that and sure enough making sure 'lo' is brought up first prevents that message. As to the NFS, no idea, I've never messed w/ nfsroot. -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
Re: neighbour table?
Andrew Park wrote: > I get a message > > neighbour table overflow > > What does that mean? It seems that > > net/ipv4/route.c > > is the place where it prints this. But under what circumstances > does this happen? > Thanks It means you set the link state of eth0 up before lo. Be sure lo is established before eth0 and you won't see this message. -d begin:vcard n:Ford;David x-mozilla-html:TRUE adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;14688 fn:David Ford end:vcard
neighbour table?
I get a message neighbour table overflow What does that mean? It seems that net/ipv4/route.c is the place where it prints this. But under what circumstances does this happen? Thanks -A. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
neighbour table?
I get a message neighbour table overflow What does that mean? It seems that net/ipv4/route.c is the place where it prints this. But under what circumstances does this happen? Thanks -A. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
