* [PATCH] pcnet: fix sparse triviality
From: Auke Kok @ 2007-10-26 22:11 UTC (permalink / raw)
To: pcnet32; +Cc: netdev
Since data can never exceed u32, it can't even be larger than LONG_MAX/HZ.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Cc: pcnet32@verizon.net
---
drivers/net/pcnet32.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c
index ff92aca..3573e77 100644
--- a/drivers/net/pcnet32.c
+++ b/drivers/net/pcnet32.c
@@ -1101,9 +1101,8 @@ static int pcnet32_phys_id(struct net_device *dev, u32 data)
mod_timer(&lp->blink_timer, jiffies);
set_current_state(TASK_INTERRUPTIBLE);
- /* AV: the limit here makes no sense whatsoever */
- if ((!data) || (data > (u32) (MAX_SCHEDULE_TIMEOUT / HZ)))
- data = (u32) (MAX_SCHEDULE_TIMEOUT / HZ);
+ if (!data)
+ data = INT_MAX;
msleep_interruptible(data * 1000);
del_timer_sync(&lp->blink_timer);
^ permalink raw reply related
* Re: [PATCH] skye/skge: sparse fix - data can't ever be bigger than LONG_MAX / HZ
From: Stephen Hemminger @ 2007-10-26 22:12 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev
In-Reply-To: <20071026221028.1873.3005.stgit@localhost.localdomain>
On Fri, 26 Oct 2007 15:10:28 -0700
Auke Kok <auke-jan.h.kok@intel.com> wrote:
> Trivial replacement - use INT_MAX instead here.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> Cc: shemminger@linux-foundation.org
Acked-by: Stephen Hemminger <shemminger@linux-foundation.org>
Sure that works. Note: original code was copied from e100 which I assume
is why you found/fixed this case.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH] skye/skge: sparse fix - data can't ever be bigger than LONG_MAX / HZ
From: Kok, Auke @ 2007-10-26 22:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071026151240.0ce5f7ec@freepuppy.rosehill>
Stephen Hemminger wrote:
> On Fri, 26 Oct 2007 15:10:28 -0700
> Auke Kok <auke-jan.h.kok@intel.com> wrote:
>
>> Trivial replacement - use INT_MAX instead here.
>>
>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
>> Cc: shemminger@linux-foundation.org
>
> Acked-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> Sure that works. Note: original code was copied from e100 which I assume
> is why you found/fixed this case.
I went over your sparse fixes and decided to fix that last warning that you had
not fixed. I thought I might as well fix those poor drivers that copied our
bad-ass code ;)
still testing the code you sent me though... hopefully not much longer.
Auke
^ permalink raw reply
* Re: Files, sockets, and closing
From: Al Viro @ 2007-10-26 22:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20071026150901.3b7fa6a3@freepuppy.rosehill>
On Fri, Oct 26, 2007 at 03:09:01PM -0700, Stephen Hemminger wrote:
> > close() from another thread is not a way to abort blocked accept(). Never
> > promised to be that. Just as close() from another thread is not a way to
> > abort blocked write() or read() or sendmsg() or...
>
> The problem is the Linux interpretation conflicts with the expectation
> of applications that run on other Unix systems. Most likely, it is
> one of those corner cases not covered by SUS or Posix specs otherwise
> it would have come up earlier. The existing Linux behavior works fine
> it just isn't expected (or well documented).
>
> I'm fine with just closing the bug (which is what I did initially), but
> where should this get documented?
close(2), perhaps? "System call on opened file holds a reference to
opened file regardless of what happens to descriptor originally passed
to it" or something to the same effect...
That's what really happens - you get the same effect as if there had been
an additional temporary opened descriptor for that sucker. And really,
multithreaded application that has one thread rip descriptors from under
another should be damn careful on _any_ system. Anything that goes
"I've got -EBADF, guess another thread had removed that descriptor,
got to recover" is insane - in effect, it calls accept() blindly and
hopes that race will play out nicely, without hitting
* thread A calls accept(3)
* thread B calls close()
* thread B calls e.g. dup() for unrelated reason and gets the same
descriptor reused
* thread A finally gets from libc to accept(2), sees no EBADF and
proceeds with accept() on completely unrelated socket, with no indication of
the problem (or returns giving you a bogus errno, depending on what the
hell that descriptor happens to be).
IOW, if you rely on -EBADF to deal with such (userland) races, you are
extremely likely to be screwed. On Linux, on FreeBSD, on Solaris, whatever.
In very controlled circumstances you might get away with that, but it's
almost certainly a Very Bad Idea(tm).
The bottom line: if descriptor table is a shared resource in your
multithreaded program, treat it as such. Kernel will survive having
descriptors closed in the middle of syscall just fine; your userland
code is a different story.
^ permalink raw reply
* [2.6 patch] always export sysctl_{r,w}mem_max
From: Adrian Bunk @ 2007-10-26 23:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Eric W. Biederman
This patch fixes the following build error with CONFIG_SYSCTL=n:
<-- snip -->
...
ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
make[2]: *** [__modpost] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
22ea6cd56e4fa844b0b1bbab2542f09eb6c9a5ab
diff --git a/net/core/sock.c b/net/core/sock.c
index febbcbc..ee1cc4f 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2004,7 +2004,5 @@ EXPORT_SYMBOL(sock_wmalloc);
EXPORT_SYMBOL(sock_i_uid);
EXPORT_SYMBOL(sock_i_ino);
EXPORT_SYMBOL(sysctl_optmem_max);
-#ifdef CONFIG_SYSCTL
EXPORT_SYMBOL(sysctl_rmem_max);
EXPORT_SYMBOL(sysctl_wmem_max);
-#endif
^ permalink raw reply related
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: Eric W. Biederman @ 2007-10-26 23:20 UTC (permalink / raw)
To: Adrian Bunk; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20071026230807.GE30533@stusta.de>
Adrian Bunk <bunk@kernel.org> writes:
> This patch fixes the following build error with CONFIG_SYSCTL=n:
>
> <-- snip -->
>
> ...
> ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
> ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
> ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
> make[2]: *** [__modpost] Error 1
I was going to ask if allowing drivers to increase rmem_max
is something that we want to do. Apparently the road runner
driver has been doing this since the 2.6.12-rc1 when the
git repository starts so this probably isn't a latent bug.
So removing unnecessary #ifdef sounds good to me.
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> 22ea6cd56e4fa844b0b1bbab2542f09eb6c9a5ab
> diff --git a/net/core/sock.c b/net/core/sock.c
> index febbcbc..ee1cc4f 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2004,7 +2004,5 @@ EXPORT_SYMBOL(sock_wmalloc);
> EXPORT_SYMBOL(sock_i_uid);
> EXPORT_SYMBOL(sock_i_ino);
> EXPORT_SYMBOL(sysctl_optmem_max);
> -#ifdef CONFIG_SYSCTL
> EXPORT_SYMBOL(sysctl_rmem_max);
> EXPORT_SYMBOL(sysctl_wmem_max);
> -#endif
^ permalink raw reply
* [ofa-general] Re: [PATCH 1/14 v2] nes: module and device initialization
From: Roland Dreier @ 2007-10-26 23:23 UTC (permalink / raw)
To: ggrundstrom; +Cc: netdev, ewg, general
In-Reply-To: <200710192001.l9JK1U8O021689@neteffect.com>
OK, a couple quick review comments and a process comment too:
- First step in the driver is to kill off a lot of the #ifdefs:
> +#ifdef IRQF_SHARED
The upstream driver really shouldn't have compatibility gunk for older
kernels... just make it build against the kernel it's in.
> +#ifdef OFED_1_2
Same... kernel code shouldn't worry about OFED.
> +#ifdef CONFIG_PCI_MSI
> + if (nesdev->msi_enabled) {
> + pci_disable_msi(pcidev);
> + }
> +#endif
This can be much simpler, because pci_disable_msi() is always
available and is a NOP if the config option is off or MSI is not
enabled. So you can just unconditionally do
pci_disable_msi(pcidev);
> +#ifdef NES_NAPI
I don't see anything that defines NES_NAPI. I think for the final
merge we want a NAPI-only driver (ie no ifdef at all)... is there any
performance or other reason to ever build a non-NAPI driver (for a
modern kernel)?
OK, on a process level, my plan is to pull the current driver into a
"neteffect" branch in my git tree with the intention of merging it for
2.6.25. I'll let you know when that's ready (probably early next
week). I'll probably do some cleanups there, and you can send me
cleanup/fix patches against that branch any time too. We should try
to keep the cycle time short: the interval between the first posting
of this driver and the current one was pretty long, and there's a lot
of cleanup to do to get ready for the next merge window. Does that
plan make sense?
- R.
^ permalink raw reply
* [PATCH] netns: Fix get_net_ns_by_pid
From: Eric W. Biederman @ 2007-10-26 23:29 UTC (permalink / raw)
To: David Miller
Cc: netdev, Linux Containers, Denis V. Lunev, Benjamin Thery,
Daniel Lezcano
The pid namespace patches changed the semantics of
find_task_by_pid without breaking the compile resulting
in get_net_ns_by_pid doing the wrong thing.
So switch to using the intended find_task_by_vpid.
Combined with Denis' earlier patch to make netlink traffic
fully synchronous the inadvertent race I introduced with
accessing current is actually removed.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/core/rtnetlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 4a2640d..e1ba26f 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -742,7 +742,7 @@ static struct net *get_net_ns_by_pid(pid_t pid)
/* Lookup the network namespace */
net = ERR_PTR(-ESRCH);
rcu_read_lock();
- tsk = find_task_by_pid(pid);
+ tsk = find_task_by_vpid(pid);
if (tsk) {
struct nsproxy *nsproxy;
nsproxy = task_nsproxy(tsk);
--
1.5.3.rc6.17.g1911
^ permalink raw reply related
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: Rick Jones @ 2007-10-26 23:31 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Adrian Bunk, davem, netdev, linux-kernel
In-Reply-To: <m1zly5wjie.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Adrian Bunk <bunk@kernel.org> writes:
>
>
>>This patch fixes the following build error with CONFIG_SYSCTL=n:
>>
>><-- snip -->
>>
>>...
>>ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
>>ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
>>ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
>>make[2]: *** [__modpost] Error 1
>
>
> I was going to ask if allowing drivers to increase rmem_max
> is something that we want to do. Apparently the road runner
> driver has been doing this since the 2.6.12-rc1 when the
> git repository starts so this probably isn't a latent bug.
Although it does rather sound like a driver writer yanking the rope from the
hand's of the sysadmin and hanging him with it rather than letting the sysadmin
do it himself. I've seen other drivers' README's suggesting larger mem's but
not their sources doing it.
rick jones
^ permalink raw reply
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: David Miller @ 2007-10-26 23:39 UTC (permalink / raw)
To: rick.jones2; +Cc: ebiederm, bunk, netdev, linux-kernel
In-Reply-To: <472278E3.4000909@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Fri, 26 Oct 2007 16:31:47 -0700
> Eric W. Biederman wrote:
> > Adrian Bunk <bunk@kernel.org> writes:
> >
> >
> >>This patch fixes the following build error with CONFIG_SYSCTL=n:
> >>
> >><-- snip -->
> >>
> >>...
> >>ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
> >>ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
> >>ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
> >>make[2]: *** [__modpost] Error 1
> >
> >
> > I was going to ask if allowing drivers to increase rmem_max
> > is something that we want to do. Apparently the road runner
> > driver has been doing this since the 2.6.12-rc1 when the
> > git repository starts so this probably isn't a latent bug.
>
> Although it does rather sound like a driver writer yanking the rope from the
> hand's of the sysadmin and hanging him with it rather than letting the sysadmin
> do it himself. I've seen other drivers' README's suggesting larger mem's but
> not their sources doing it.
I really don't think what the roadrunner driver is doing is
correct at all.
I also think what DLM is doing is wrong too.
If DLM really wants minimum, it can use SO_SNDBUFFORCE and
SO_RCVBUFFORCE socket options and use whatever limits it
likes.
But even this is questionable.
I'll put in Adrian's patch to fix the build as a first
priority, but in the long term this cruft has gotta go.
^ permalink raw reply
* Re: [NETNS] Oops in register_pernet_operations() with CONFIG_NET_NS=n
From: Eric W. Biederman @ 2007-10-26 23:40 UTC (permalink / raw)
To: David Miller; +Cc: benjamin.thery, netdev, dlunev, containers, clg, xemul
In-Reply-To: <20071026.045503.62376243.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Thanks for doing this.
>
> But this appears to be still discussed, so I'll give
> Denis and others another day to work out the fix they
> want to include.
At this point I think all that really needs to happen is to remove
__net_initdata. The function attributes seem sane. Not that
I have any problem with the complete revert either.
I will send a patch to that effect in just a moment.
Eric
^ permalink raw reply
* [PATCH] net: Marking struct pernet_operations __net_initdata was inappropriate
From: Eric W. Biederman @ 2007-10-26 23:45 UTC (permalink / raw)
To: David Miller
Cc: benjamin.thery, ebiederm, netdev, dlunev, containers, clg, xemul
In-Reply-To: <20071026.045503.62376243.davem@davemloft.net>
It is not safe to to place struct pernet_operations in a special section.
We need struct pernet_operations to last until we call unregister_pernet_subsys.
Which doesn't happen until module unload.
So marking struct pernet_operations is a disaster for modules in two ways.
- We discard it before we call the exit method it points to.
- Because I keep struct pernet_operations on a linked list discarding
it for compiled in code removes elements in the middle of a linked
list and does horrible things for linked insert.
So this looks safe assuming __exit_refok is not discarded
for modules.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/net/loopback.c | 2 +-
fs/proc/proc_net.c | 2 +-
include/net/net_namespace.h | 2 --
net/core/dev.c | 6 +++---
net/core/dev_mcast.c | 2 +-
net/netlink/af_netlink.c | 2 +-
6 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 662b8d1..45f30a2 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -284,7 +284,7 @@ static __net_exit void loopback_net_exit(struct net *net)
unregister_netdev(dev);
}
-static struct pernet_operations __net_initdata loopback_net_ops = {
+static struct pernet_operations loopback_net_ops = {
.init = loopback_net_init,
.exit = loopback_net_exit,
};
diff --git a/fs/proc/proc_net.c b/fs/proc/proc_net.c
index 4edaad0..749def0 100644
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -185,7 +185,7 @@ static __net_exit void proc_net_ns_exit(struct net *net)
kfree(net->proc_net_root);
}
-static struct pernet_operations __net_initdata proc_net_ns_ops = {
+static struct pernet_operations proc_net_ns_ops = {
.init = proc_net_ns_init,
.exit = proc_net_ns_exit,
};
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 93aa87d..5279466 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -102,11 +102,9 @@ static inline void release_net(struct net *net)
#ifdef CONFIG_NET_NS
#define __net_init
#define __net_exit
-#define __net_initdata
#else
#define __net_init __init
#define __net_exit __exit_refok
-#define __net_initdata __initdata
#endif
struct pernet_operations {
diff --git a/net/core/dev.c b/net/core/dev.c
index ddfef3b..853c8b5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2668,7 +2668,7 @@ static void __net_exit dev_proc_net_exit(struct net *net)
proc_net_remove(net, "dev");
}
-static struct pernet_operations __net_initdata dev_proc_ops = {
+static struct pernet_operations dev_proc_ops = {
.init = dev_proc_net_init,
.exit = dev_proc_net_exit,
};
@@ -4328,7 +4328,7 @@ static void __net_exit netdev_exit(struct net *net)
kfree(net->dev_index_head);
}
-static struct pernet_operations __net_initdata netdev_net_ops = {
+static struct pernet_operations netdev_net_ops = {
.init = netdev_init,
.exit = netdev_exit,
};
@@ -4359,7 +4359,7 @@ static void __net_exit default_device_exit(struct net *net)
rtnl_unlock();
}
-static struct pernet_operations __net_initdata default_device_ops = {
+static struct pernet_operations default_device_ops = {
.exit = default_device_exit,
};
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 15241cf..ae35405 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -285,7 +285,7 @@ static void __net_exit dev_mc_net_exit(struct net *net)
proc_net_remove(net, "dev_mcast");
}
-static struct pernet_operations __net_initdata dev_mc_net_ops = {
+static struct pernet_operations dev_mc_net_ops = {
.init = dev_mc_net_init,
.exit = dev_mc_net_exit,
};
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 3252729..4f994c0 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1888,7 +1888,7 @@ static void __net_exit netlink_net_exit(struct net *net)
#endif
}
-static struct pernet_operations __net_initdata netlink_net_ops = {
+static struct pernet_operations netlink_net_ops = {
.init = netlink_net_init,
.exit = netlink_net_exit,
};
--
1.5.3.rc6.17.g1911
^ permalink raw reply related
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: Rick Jones @ 2007-10-26 23:46 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, bunk, netdev, linux-kernel
In-Reply-To: <20071026.163958.171785530.davem@davemloft.net>
David Miller wrote:
> If DLM really wants minimum, it can use SO_SNDBUFFORCE and
> SO_RCVBUFFORCE socket options and use whatever limits it
> likes.
>
> But even this is questionable.
Drift...
Is that something netperf should be using though? Right now it uses the regular
SO_[SND|RCV]BUF calls and is at the mercy of sysctls. I wonder if it would be
better to have it use their FORCE versions to make life easier on the
benchmarker - such as myself - who has an unfortunate habit of forgetting to
update sysctl.conf :)
rick jones
^ permalink raw reply
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: David Miller @ 2007-10-26 23:52 UTC (permalink / raw)
To: rick.jones2; +Cc: ebiederm, bunk, netdev, linux-kernel
In-Reply-To: <47227C5C.1070507@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Fri, 26 Oct 2007 16:46:36 -0700
> David Miller wrote:
> > If DLM really wants minimum, it can use SO_SNDBUFFORCE and
> > SO_RCVBUFFORCE socket options and use whatever limits it
> > likes.
> >
> > But even this is questionable.
>
> Drift...
>
> Is that something netperf should be using though? Right now it uses the regular
> SO_[SND|RCV]BUF calls and is at the mercy of sysctls. I wonder if it would be
> better to have it use their FORCE versions to make life easier on the
> benchmarker - such as myself - who has an unfortunate habit of forgetting to
> update sysctl.conf :)
The force calls are for root only.
And I want to remind you that explicitly setting socket
buffer sizes hurts performance with TCP. I know you know
this but it bears restating for the benefit of others.
^ permalink raw reply
* Re: [2.6 patch] always export sysctl_{r,w}mem_max
From: Eric W. Biederman @ 2007-10-27 0:04 UTC (permalink / raw)
To: David Miller; +Cc: rick.jones2, bunk, netdev, linux-kernel
In-Reply-To: <20071026.163958.171785530.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Fri, 26 Oct 2007 16:31:47 -0700
>
>> Eric W. Biederman wrote:
>> > Adrian Bunk <bunk@kernel.org> writes:
>> >
>> >
>> >>This patch fixes the following build error with CONFIG_SYSCTL=n:
>> >>
>> >><-- snip -->
>> >>
>> >>...
>> >>ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
>> >>ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
>> >>ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
>> >>make[2]: *** [__modpost] Error 1
>> >
>> >
>> > I was going to ask if allowing drivers to increase rmem_max
>> > is something that we want to do. Apparently the road runner
>> > driver has been doing this since the 2.6.12-rc1 when the
>> > git repository starts so this probably isn't a latent bug.
>>
>> Although it does rather sound like a driver writer yanking the rope from the
>> hand's of the sysadmin and hanging him with it rather than letting the
> sysadmin
>> do it himself. I've seen other drivers' README's suggesting larger mem's but
>> not their sources doing it.
>
> I really don't think what the roadrunner driver is doing is
> correct at all.
>
> I also think what DLM is doing is wrong too.
>
> If DLM really wants minimum, it can use SO_SNDBUFFORCE and
> SO_RCVBUFFORCE socket options and use whatever limits it
> likes.
>
> But even this is questionable.
>
> I'll put in Adrian's patch to fix the build as a first
> priority, but in the long term this cruft has gotta go.
As it stands this is a very old build bug. I believe those
symbols have always been exported inside of #ifdef CONFIG_SYSCTL.
So if this is really something we want to stop doing we should
be able to take a few extra moments remove the code from the
two problem drivers, and remove the exports.
It didn't look like any of the other users could possibly be
modular.
Eric
^ permalink raw reply
* [2.6 patch] net/ipv{4,6}/esp{4,6}.c must #include <linux/scatterlist.h>
From: Adrian Bunk @ 2007-10-27 2:34 UTC (permalink / raw)
To: David S. Miller, Jens Axboe; +Cc: linux-kernel, netdev
This patch fixes the following compile errors in some configurations:
<-- snip -->
...
CC net/ipv4/esp4.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/esp4.c: In function 'esp_output':
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/esp4.c:113: error: implicit declaration of function 'sg_init_table'
make[3]: *** [net/ipv4/esp4.o] Error 1
...
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv6/esp6.c: In function 'esp6_output':
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv6/esp6.c:112: error: implicit declaration of function 'sg_init_table'
make[3]: *** [net/ipv6/esp6.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
net/ipv4/esp4.c | 2 +-
net/ipv6/esp6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
ecf93220d6af83516dbe04dcd09474a0423ce2ef
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index ba98401..23b647c 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -3,7 +3,7 @@
#include <net/ip.h>
#include <net/xfrm.h>
#include <net/esp.h>
-#include <asm/scatterlist.h>
+#include <linux/scatterlist.h>
#include <linux/crypto.h>
#include <linux/kernel.h>
#include <linux/pfkeyv2.h>
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index f67d51a..f8bb136 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -29,7 +29,7 @@
#include <net/ip.h>
#include <net/xfrm.h>
#include <net/esp.h>
-#include <asm/scatterlist.h>
+#include <linux/scatterlist.h>
#include <linux/crypto.h>
#include <linux/kernel.h>
#include <linux/pfkeyv2.h>
^ permalink raw reply related
* [PATCH] tcp v6: fix softnet build breakage
From: Jeff Garzik @ 2007-10-27 3:42 UTC (permalink / raw)
To: David Miller, Andrew Morton, Linus Torvalds; +Cc: netdev, LKML
net/ipv6/tcp_ipv6.c: In function 'tcp_v6_rcv':
net/ipv6/tcp_ipv6.c:1736: error: implicit declaration of function
'get_softnet_dma'
net/ipv6/tcp_ipv6.c:1736: warning: assignment makes pointer from integer
without a cast
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
---
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 06fa4ba..8520802 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -59,6 +59,7 @@
#include <net/snmp.h>
#include <net/dsfield.h>
#include <net/timewait_sock.h>
+#include <net/netdma.h>
#include <asm/uaccess.h>
^ permalink raw reply related
* Re: [PATCH] tcp v6: fix softnet build breakage
From: David Miller @ 2007-10-27 5:53 UTC (permalink / raw)
To: jeff; +Cc: akpm, torvalds, netdev, linux-kernel
In-Reply-To: <20071027034240.GA13016@havoc.gtf.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 26 Oct 2007 23:42:40 -0400
>
> net/ipv6/tcp_ipv6.c: In function 'tcp_v6_rcv':
> net/ipv6/tcp_ipv6.c:1736: error: implicit declaration of function
> 'get_softnet_dma'
> net/ipv6/tcp_ipv6.c:1736: warning: assignment makes pointer from integer
> without a cast
>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Applied, thanks Jeff.
^ permalink raw reply
* Re: [2.6 patch] net/ipv{4,6}/esp{4,6}.c must #include <linux/scatterlist.h>
From: David Miller @ 2007-10-27 5:54 UTC (permalink / raw)
To: bunk; +Cc: jens.axboe, linux-kernel, netdev
In-Reply-To: <20071027023448.GP30533@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Sat, 27 Oct 2007 04:34:48 +0200
> This patch fixes the following compile errors in some configurations:
>
> <-- snip -->
>
> ...
> CC net/ipv4/esp4.o
> /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/esp4.c: In function 'esp_output':
> /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/esp4.c:113: error: implicit declaration of function 'sg_init_table'
> make[3]: *** [net/ipv4/esp4.o] Error 1
> ...
> /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv6/esp6.c: In function 'esp6_output':
> /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv6/esp6.c:112: error: implicit declaration of function 'sg_init_table'
> make[3]: *** [net/ipv6/esp6.o] Error 1
>
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [PATCH] net: Marking struct pernet_operations __net_initdata was inappropriate
From: David Miller @ 2007-10-27 5:55 UTC (permalink / raw)
To: ebiederm; +Cc: benjamin.thery, netdev, dlunev, containers, clg, xemul
In-Reply-To: <m1hckdwici.fsf_-_@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 26 Oct 2007 17:45:33 -0600
>
> It is not safe to to place struct pernet_operations in a special section.
> We need struct pernet_operations to last until we call unregister_pernet_subsys.
> Which doesn't happen until module unload.
>
> So marking struct pernet_operations is a disaster for modules in two ways.
> - We discard it before we call the exit method it points to.
> - Because I keep struct pernet_operations on a linked list discarding
> it for compiled in code removes elements in the middle of a linked
> list and does horrible things for linked insert.
>
> So this looks safe assuming __exit_refok is not discarded
> for modules.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied, thanks Eric.
Although juding by his comments I though that Denis had different
plans in mind to fix this.
^ permalink raw reply
* Re: [PATCH] netns: Fix get_net_ns_by_pid
From: David Miller @ 2007-10-27 5:56 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers, dlunev, benjamin.thery, dlezcano
In-Reply-To: <m1ve8twj2y.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 26 Oct 2007 17:29:41 -0600
>
> The pid namespace patches changed the semantics of
> find_task_by_pid without breaking the compile resulting
> in get_net_ns_by_pid doing the wrong thing.
>
> So switch to using the intended find_task_by_vpid.
>
> Combined with Denis' earlier patch to make netlink traffic
> fully synchronous the inadvertent race I introduced with
> accessing current is actually removed.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Marking struct pernet_operations __net_initdata was inappropriate
From: Eric W. Biederman @ 2007-10-27 6:07 UTC (permalink / raw)
To: David Miller; +Cc: benjamin.thery, netdev, dlunev, containers, clg, xemul
In-Reply-To: <20071026.225516.152502425.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
>
> Applied, thanks Eric.
>
> Although juding by his comments I though that Denis had different
> plans in mind to fix this.
He might. Somehow I wasn't on that thread so I missed it until after
I sent this patch. Reading through that thread again it looks like
he had a thought for another attribute. It all sounded very clever.
This patch is minimal stupid and should just work. Doubtless the
clever patch can be applied on top, once the details are figured
out.
Eric
^ permalink raw reply
* Re: [PATCH] net: Marking struct pernet_operations __net_initdata was inappropriate
From: David Miller @ 2007-10-27 7:29 UTC (permalink / raw)
To: ebiederm; +Cc: benjamin.thery, netdev, dlunev, containers, clg, xemul
In-Reply-To: <m1zly5rsz3.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sat, 27 Oct 2007 00:07:12 -0600
> This patch is minimal stupid and should just work. Doubtless the
> clever patch can be applied on top, once the details are figured
> out.
That is true and that's why I applied your patch.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/2] [CRYPTO] tcrypt: Move sg_init_table out of timing loops
From: David Miller @ 2007-10-27 7:51 UTC (permalink / raw)
To: herbert; +Cc: linux-kernel, linux-crypto, netdev
In-Reply-To: <E1IlQfM-0003cO-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 26 Oct 2007 23:00:04 +0800
> [CRYPTO] tcrypt: Move sg_init_table out of timing loops
>
> This patch moves the sg_init_table out of the timing loops for hash
> algorithms so that it doesn't impact on the speed test results.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] [CRYPTO] users: Fix up scatterlist conversion errors
From: David Miller @ 2007-10-27 7:52 UTC (permalink / raw)
To: herbert; +Cc: linux-kernel, linux-crypto, netdev
In-Reply-To: <E1IlQfN-0003cW-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 26 Oct 2007 23:00:05 +0800
> [CRYPTO] users: Fix up scatterlist conversion errors
>
> This patch fixes the errors made in the users of the crypto layer during
> the sg_init_table conversion. It also adds a few conversions that were
> missing altogether.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Also applied, thanks Herbert!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox