Linus Torvalds wrote:
>
> On Mon, 11 Dec 2006, Chuck Ebbert wrote:
>> Prevent oops when an app tries to create a pipe while pipefs
>> is not mounted.
>
> Have you actually seen this, or is this just from looking at code?
>
> Quite frankly, if "pipe_mnt" is ever NULL, we're dead for lots of
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Chuck Ebbert wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
Have you actually seen this, or is this just from looking at code?
Quite frankly, if pipe_mnt is ever NULL, we're dead for lots of other
reasons.
On Mon, 11 Dec 2006, Andrew Morton wrote:
>
> Looks like this might break pcmcia which for some reason does firmware
> requesting at fs_initcall level (drivers/pcmcia/ds.c).
Ok, that's just strange.
I think it's fine to do init_pcmcia_bus early to make sure that the PCMCIA
bus interface is
On Mon, Dec 11, 2006 at 06:08:22PM -0800, Andrew Morton wrote:
> > diff --git a/include/linux/init.h b/include/linux/init.h
> > index 5eb5d24..5a593a1 100644
> > --- a/include/linux/init.h
> > +++ b/include/linux/init.h
> > @@ -111,6 +111,7 @@ extern void setup_arch(char **);
> > #define
On Mon, 11 Dec 2006 08:01:40 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 11 Dec 2006, Al Viro wrote:
>
> > On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
> > > @@ -115,6 +115,11 @@ extern void setup_arch(char **);
> > > #define device_initcall_sync(fn)
> So it makes perfect sense to say
>
>"you won't be getting any notification by anything built-in, until
> 'device_initcall' (which is the default module_init, of course)".
>
> which in the case of certain drivers obviously _does_ mean that they had
> better not try to use any early
On Mon, 11 Dec 2006, Al Viro wrote:
>
> FWIW, I really think that this sort of bugs ("oh, I call hotplug,
> rootfs is there but kernel is not ready, woe is me") clearly show
> that many, _many_ users of hotplug are BS. The reason is simple -
> if we have a call of hotplug that early, we have a
On Mon, Dec 11, 2006 at 08:01:40AM -0800, Linus Torvalds wrote:
>
>
> On Mon, 11 Dec 2006, Al Viro wrote:
>
> > On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
> > > @@ -115,6 +115,11 @@ extern void setup_arch(char **);
> > > #define device_initcall_sync(fn)
On Mon, 11 Dec 2006, Al Viro wrote:
> On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
> > @@ -115,6 +115,11 @@ extern void setup_arch(char **);
> > #define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
> > #define late_initcall(fn)
On Mon, 11 Dec 2006, Chuck Ebbert wrote:
>
> Prevent oops when an app tries to create a pipe while pipefs
> is not mounted.
Have you actually seen this, or is this just from looking at code?
Quite frankly, if "pipe_mnt" is ever NULL, we're dead for lots of other
reasons.
In fact, pipe_mnt
Andrew Morton wrote:
A heck of a lot of things can trigger an /sbin/hotplug run. It could well
be that Andrew's driver didn't want to run hotplug at all, but the kernel
did it anwyay. But as soon as the script appeared at /sbin/hotplug, and it
happened to use foo|bar: boom.
In fact, things
On Mon, Dec 11, 2006 at 11:48:57AM +0100, Olaf Hering wrote:
> On Mon, Dec 11, Chuck Ebbert wrote:
>
> > Why not create a new initcall category for things that must run before
> > early userspace?
>
> Why do you want to continue with papering over the root cause?
> Pick some janitor, let him
On Mon, Dec 11, Chuck Ebbert wrote:
> Why not create a new initcall category for things that must run before
> early userspace?
Why do you want to continue with papering over the root cause?
Pick some janitor, let him write something that implements something
like make style dependencies for
On Mon, Dec 11, 2006 at 02:34:36AM -0800, Andrew Morton wrote:
> There are plenty of drivers in there using subsys_initcall, arch_initcall,
> postcore_initcall, core_initcall and even one pure_initcall.
>
> Heaven knows why. They're drivers :(
> A heck of a lot of things can trigger an
On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
> @@ -115,6 +115,11 @@ extern void setup_arch(char **);
> #define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
> #define late_initcall(fn)__define_initcall("7",fn,7)
> #define late_initcall_sync(fn)
On Mon, 11 Dec 2006 10:22:07 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 11, 2006 at 02:17:18AM -0800, Andrew Morton wrote:
> > I think we should aim to have as many subsystems ready to go as possible -
> > ideally all of them. Right now we can potentially run userspace before
> >
On Mon, 11 Dec 2006 02:17:18 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Said that, I think that pipes should be initialized early.
>
> Judging by the comment there, the only reason we prepare the rootfs prior
> to running initcalls is for firmware. So the sequence
>
> run
On Mon, Dec 11, 2006 at 02:17:18AM -0800, Andrew Morton wrote:
> I think we should aim to have as many subsystems ready to go as possible -
> ideally all of them. Right now we can potentially run userspace before
> AIO, posix-timers, message-queues, BIO, networking, etc are ready to run.
>
> It
On Mon, 11 Dec 2006 10:03:01 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 11, 2006 at 01:47:27AM -0800, Andrew Morton wrote:
> > - populate_rootfs() puts stuff into the filesystem
> >
> > - we then run initcalls.
> >
> > - an initcall runs /sbin/hotplug.
> >
> > We're now running
On Mon, Dec 11, 2006 at 01:47:27AM -0800, Andrew Morton wrote:
> - populate_rootfs() puts stuff into the filesystem
>
> - we then run initcalls.
>
> - an initcall runs /sbin/hotplug.
>
> We're now running userspace before all the initcalls have been executed.
> Hence we're trying to run
On Mon, 11 Dec 2006 09:33:15 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 11, 2006 at 01:25:45AM -0800, Andrew Morton wrote:
> > On Mon, 11 Dec 2006 09:21:30 +
> > Al Viro <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
> > > > On
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 11 Dec 2006 00:55:57 -0800, Andrew Morton wrote:
> > Prevent oops when an app tries to create a pipe while pipefs
> > is not mounted.
>
> That's pretty lame. It means that pipes just won't work, so people who are
> using pipes in their initramfs setups
Al Viro wrote:
> On Mon, Dec 11, 2006 at 03:27:37AM -0500, Chuck Ebbert wrote:
>> Prevent oops when an app tries to create a pipe while pipefs
>> is not mounted.
[]
> That makes no sense at all. pipe_mnt is not created by userland
> mount; it's created by init_pipe_fs() and we'd bloody better
>
On Mon, 11 Dec 2006 09:21:30 +
Al Viro <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
> > On Mon, 11 Dec 2006 00:55:57 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > I think the bug really is the running of populate_rootfs() before
On Mon, Dec 11, 2006 at 01:25:45AM -0800, Andrew Morton wrote:
> On Mon, 11 Dec 2006 09:21:30 +
> Al Viro <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
> > > On Mon, 11 Dec 2006 00:55:57 -0800
> > > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
> On Mon, 11 Dec 2006 00:55:57 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I think the bug really is the running of populate_rootfs() before running
> > the initcalls, in init/main.c:init(). It's just more sensible to
On Mon, 11 Dec 2006 00:55:57 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I think the bug really is the running of populate_rootfs() before running
> the initcalls, in init/main.c:init(). It's just more sensible to start
> running userspace after the initcalls have been run.
On Mon, Dec 11, 2006 at 03:27:37AM -0500, Chuck Ebbert wrote:
> Prevent oops when an app tries to create a pipe while pipefs
> is not mounted.
>
> Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
That makes no sense at all. pipe_mnt is not created by userland
mount; it's created by
On Mon, 11 Dec 2006 03:27:37 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> Prevent oops when an app tries to create a pipe while pipefs
> is not mounted.
>
> Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
>
> --- 2.6.19.1-pre1-32.orig/fs/pipe.c
> +++ 2.6.19.1-pre1-32/fs/pipe.c
> @@ -839,9
On Mon, 11 Dec 2006 03:27:37 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
Signed-off-by: Chuck Ebbert [EMAIL PROTECTED]
--- 2.6.19.1-pre1-32.orig/fs/pipe.c
+++ 2.6.19.1-pre1-32/fs/pipe.c
@@ -839,9 +839,11 @@
On Mon, Dec 11, 2006 at 03:27:37AM -0500, Chuck Ebbert wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
Signed-off-by: Chuck Ebbert [EMAIL PROTECTED]
That makes no sense at all. pipe_mnt is not created by userland
mount; it's created by init_pipe_fs() and
On Mon, 11 Dec 2006 00:55:57 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
I think the bug really is the running of populate_rootfs() before running
the initcalls, in init/main.c:init(). It's just more sensible to start
running userspace after the initcalls have been run. Statically-linked
On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006 00:55:57 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
I think the bug really is the running of populate_rootfs() before running
the initcalls, in init/main.c:init(). It's just more sensible to start
On Mon, Dec 11, 2006 at 01:25:45AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006 09:21:30 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006 00:55:57 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
I think
On Mon, 11 Dec 2006 09:21:30 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006 00:55:57 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
I think the bug really is the running of populate_rootfs() before running
the
In-Reply-To: [EMAIL PROTECTED]
On Mon, 11 Dec 2006 00:55:57 -0800, Andrew Morton wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
That's pretty lame. It means that pipes just won't work, so people who are
using pipes in their initramfs setups will just
Al Viro wrote:
On Mon, Dec 11, 2006 at 03:27:37AM -0500, Chuck Ebbert wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
[]
That makes no sense at all. pipe_mnt is not created by userland
mount; it's created by init_pipe_fs() and we'd bloody better
have it
On Mon, 11 Dec 2006 09:33:15 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 01:25:45AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006 09:21:30 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 01:13:27AM -0800, Andrew Morton wrote:
On Mon, 11 Dec 2006
On Mon, Dec 11, 2006 at 01:47:27AM -0800, Andrew Morton wrote:
- populate_rootfs() puts stuff into the filesystem
- we then run initcalls.
- an initcall runs /sbin/hotplug.
We're now running userspace before all the initcalls have been executed.
Hence we're trying to run userspace when
On Mon, 11 Dec 2006 10:03:01 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 01:47:27AM -0800, Andrew Morton wrote:
- populate_rootfs() puts stuff into the filesystem
- we then run initcalls.
- an initcall runs /sbin/hotplug.
We're now running userspace before all
On Mon, Dec 11, 2006 at 02:17:18AM -0800, Andrew Morton wrote:
I think we should aim to have as many subsystems ready to go as possible -
ideally all of them. Right now we can potentially run userspace before
AIO, posix-timers, message-queues, BIO, networking, etc are ready to run.
It looks
On Mon, 11 Dec 2006 02:17:18 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Said that, I think that pipes should be initialized early.
Judging by the comment there, the only reason we prepare the rootfs prior
to running initcalls is for firmware. So the sequence
run initcalls
On Mon, 11 Dec 2006 10:22:07 +
Al Viro [EMAIL PROTECTED] wrote:
On Mon, Dec 11, 2006 at 02:17:18AM -0800, Andrew Morton wrote:
I think we should aim to have as many subsystems ready to go as possible -
ideally all of them. Right now we can potentially run userspace before
AIO,
On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
@@ -115,6 +115,11 @@ extern void setup_arch(char **);
#define device_initcall_sync(fn) __define_initcall(6s,fn,6s)
#define late_initcall(fn)__define_initcall(7,fn,7)
#define late_initcall_sync(fn)
On Mon, Dec 11, 2006 at 02:34:36AM -0800, Andrew Morton wrote:
There are plenty of drivers in there using subsys_initcall, arch_initcall,
postcore_initcall, core_initcall and even one pure_initcall.
Heaven knows why. They're drivers :(
A heck of a lot of things can trigger an
On Mon, Dec 11, Chuck Ebbert wrote:
Why not create a new initcall category for things that must run before
early userspace?
Why do you want to continue with papering over the root cause?
Pick some janitor, let him write something that implements something
like make style dependencies for
On Mon, Dec 11, 2006 at 11:48:57AM +0100, Olaf Hering wrote:
On Mon, Dec 11, Chuck Ebbert wrote:
Why not create a new initcall category for things that must run before
early userspace?
Why do you want to continue with papering over the root cause?
Pick some janitor, let him write
Andrew Morton wrote:
A heck of a lot of things can trigger an /sbin/hotplug run. It could well
be that Andrew's driver didn't want to run hotplug at all, but the kernel
did it anwyay. But as soon as the script appeared at /sbin/hotplug, and it
happened to use foo|bar: boom.
In fact, many
On Mon, 11 Dec 2006, Chuck Ebbert wrote:
Prevent oops when an app tries to create a pipe while pipefs
is not mounted.
Have you actually seen this, or is this just from looking at code?
Quite frankly, if pipe_mnt is ever NULL, we're dead for lots of other
reasons.
In fact, pipe_mnt can't
On Mon, 11 Dec 2006, Al Viro wrote:
On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
@@ -115,6 +115,11 @@ extern void setup_arch(char **);
#define device_initcall_sync(fn) __define_initcall(6s,fn,6s)
#define late_initcall(fn) __define_initcall(7,fn,7)
On Mon, Dec 11, 2006 at 08:01:40AM -0800, Linus Torvalds wrote:
On Mon, 11 Dec 2006, Al Viro wrote:
On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
@@ -115,6 +115,11 @@ extern void setup_arch(char **);
#define device_initcall_sync(fn) __define_initcall(6s,fn,6s)
On Mon, 11 Dec 2006, Al Viro wrote:
FWIW, I really think that this sort of bugs (oh, I call hotplug,
rootfs is there but kernel is not ready, woe is me) clearly show
that many, _many_ users of hotplug are BS. The reason is simple -
if we have a call of hotplug that early, we have a driver
So it makes perfect sense to say
you won't be getting any notification by anything built-in, until
'device_initcall' (which is the default module_init, of course).
which in the case of certain drivers obviously _does_ mean that they had
better not try to use any early initcalls
On Mon, 11 Dec 2006 08:01:40 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Mon, 11 Dec 2006, Al Viro wrote:
On Mon, Dec 11, 2006 at 02:27:46AM -0800, Andrew Morton wrote:
@@ -115,6 +115,11 @@ extern void setup_arch(char **);
#define device_initcall_sync(fn)
On Mon, Dec 11, 2006 at 06:08:22PM -0800, Andrew Morton wrote:
diff --git a/include/linux/init.h b/include/linux/init.h
index 5eb5d24..5a593a1 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -111,6 +111,7 @@ extern void setup_arch(char **);
#define
On Mon, 11 Dec 2006, Andrew Morton wrote:
Looks like this might break pcmcia which for some reason does firmware
requesting at fs_initcall level (drivers/pcmcia/ds.c).
Ok, that's just strange.
I think it's fine to do init_pcmcia_bus early to make sure that the PCMCIA
bus interface is
56 matches
Mail list logo
