Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Tomasz Chmielewski wrote: Al Borchers wrote: Thomas Chmielewski wrote: These all unpleasant tasks could be avoided if it was possible to have a "fallback" device. For example, consider this hypothetical command line: root=/dev/sdb1,/dev/sda1 Here is a patch to do this, though it sounds like you might have other solutions. This patch is for 2.6.18.1--thanks to Ed Falk for updating my original 2.6.11 patch. If people are interested I can update and test this on the current kernel. It was tested on 2.6.11. Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to do it this way than to do it with initramfs (although not as flexible). I will look do it, but I will be out next week so it may take a while. -- Al I tried your patch against 2.6.19, with some minor changes (as it wouldn't apply), but it didn't work for me (perhaps I just screwed something). - 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: kernel cmdline: root=/dev/sdb1,/dev/sda1 "fallback"?
Thomas Chmielewski wrote:
> These all unpleasant tasks could be avoided if it was possible to have a
> "fallback" device. For example, consider this hypothetical command line:
>
> root=/dev/sdb1,/dev/sda1
Here is a patch to do this, though it sounds like you might have other
solutions.
This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
2.6.11 patch. If people are interested I can update and test this on
the current kernel. It was tested on 2.6.11.
Please CC me with any comments.
-- Al
diff -uprN linux-2.6.18.1/init/do_mounts.c comma_root/init/do_mounts.c
--- linux-2.6.18.1/init/do_mounts.c 2006-10-13 20:34:03.0 -0700
+++ comma_root/init/do_mounts.c 2006-11-17 16:22:14.0 -0800
@@ -280,8 +280,9 @@ static int __init do_mount_root(char *na
return 0;
}
-void __init mount_block_root(char *name, int flags)
+static int __init mount_block_root_try(char *name, int flags)
{
+ int err;
char *fs_names = __getname();
char *p;
char b[BDEVNAME_SIZE];
@@ -289,7 +290,7 @@ void __init mount_block_root(char *name,
get_fs_names(fs_names);
retry:
for (p = fs_names; *p; p += strlen(p)+1) {
- int err = do_mount_root(name, p, flags, root_mount_data);
+ err = do_mount_root(name, p, flags, root_mount_data);
switch (err) {
case 0:
goto out;
@@ -307,19 +308,33 @@ retry:
printk("VFS: Cannot open root device \"%s\" or %s\n",
root_device_name, b);
printk("Please append a correct \"root=\" boot option\n");
-
- panic("VFS: Unable to mount root fs on %s", b);
}
printk("No filesystem could mount root, tried: ");
for (p = fs_names; *p; p += strlen(p)+1)
printk(" %s", p);
printk("\n");
- panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
+
+ err = -1;
out:
putname(fs_names);
+ return err;
}
-
+
+static inline void __init mount_block_root_fail(void)
+{
+ char b[BDEVNAME_SIZE];
+
+ panic("VFS: Unable to mount root fs on %s", __bdevname(ROOT_DEV, b));
+}
+
+void __init mount_block_root(char *name, int flags)
+{
+ if (mount_block_root_try(name, flags) != 0)
+ mount_block_root_fail();
+}
+
+
#ifdef CONFIG_ROOT_NFS
static int __init mount_nfs_root(void)
{
@@ -363,12 +378,12 @@ void __init change_floppy(char *fmt, ...
}
#endif
-void __init mount_root(void)
+static int __init mount_root_try(void)
{
#ifdef CONFIG_ROOT_NFS
if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
if (mount_nfs_root())
- return;
+ return 0;
printk(KERN_ERR "VFS: Unable to mount root fs via NFS, trying
floppy.\n");
ROOT_DEV = Root_FD0;
@@ -387,7 +402,18 @@ void __init mount_root(void)
}
#endif
create_dev("/dev/root", ROOT_DEV);
- mount_block_root("/dev/root", root_mountflags);
+ return mount_block_root_try("/dev/root", root_mountflags);
+}
+
+static inline void __init mount_root_fail(void)
+{
+ mount_block_root_fail();
+}
+
+void __init mount_root(void)
+{
+ if (mount_root_try() != 0)
+ mount_root_fail();
}
/*
@@ -396,6 +422,7 @@ void __init mount_root(void)
void __init prepare_namespace(void)
{
int is_floppy;
+ char *p,*pnext;
if (root_delay) {
printk(KERN_INFO "Waiting %dsec before mounting root
device...\n",
@@ -405,27 +432,36 @@ void __init prepare_namespace(void)
md_run_setup();
- if (saved_root_name[0]) {
- root_device_name = saved_root_name;
+ for (p=saved_root_name; p && *p; p=pnext) {
+ pnext = strchr(p, ',');
+ if (pnext)
+ *pnext++ = '\0';
+ root_device_name = p;
if (!strncmp(root_device_name, "mtd", 3)) {
mount_block_root(root_device_name, root_mountflags);
goto out;
}
ROOT_DEV = name_to_dev_t(root_device_name);
+ if (ROOT_DEV == (dev_t)0)
+ continue;
if (strncmp(root_device_name, "/dev/", 5) == 0)
root_device_name += 5;
- }
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
- if (initrd_load())
- goto out;
+ if (initrd_load())
+ goto out;
- if (is_floppy && rd_doload && rd_load_disk(0))
- ROOT_DEV = Root_RAM0;
+ if (is_floppy && rd_doload && rd_load_disk(0))
+ ROOT_DEV = Root_RAM0;
- mount_root();
+ if (mount_root_try() == 0)
+ goto out;
+
+ }
+
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 fallback?
Thomas Chmielewski wrote:
These all unpleasant tasks could be avoided if it was possible to have a
fallback device. For example, consider this hypothetical command line:
root=/dev/sdb1,/dev/sda1
Here is a patch to do this, though it sounds like you might have other
solutions.
This patch is for 2.6.18.1--thanks to Ed Falk for updating my original
2.6.11 patch. If people are interested I can update and test this on
the current kernel. It was tested on 2.6.11.
Please CC me with any comments.
-- Al
diff -uprN linux-2.6.18.1/init/do_mounts.c comma_root/init/do_mounts.c
--- linux-2.6.18.1/init/do_mounts.c 2006-10-13 20:34:03.0 -0700
+++ comma_root/init/do_mounts.c 2006-11-17 16:22:14.0 -0800
@@ -280,8 +280,9 @@ static int __init do_mount_root(char *na
return 0;
}
-void __init mount_block_root(char *name, int flags)
+static int __init mount_block_root_try(char *name, int flags)
{
+ int err;
char *fs_names = __getname();
char *p;
char b[BDEVNAME_SIZE];
@@ -289,7 +290,7 @@ void __init mount_block_root(char *name,
get_fs_names(fs_names);
retry:
for (p = fs_names; *p; p += strlen(p)+1) {
- int err = do_mount_root(name, p, flags, root_mount_data);
+ err = do_mount_root(name, p, flags, root_mount_data);
switch (err) {
case 0:
goto out;
@@ -307,19 +308,33 @@ retry:
printk(VFS: Cannot open root device \%s\ or %s\n,
root_device_name, b);
printk(Please append a correct \root=\ boot option\n);
-
- panic(VFS: Unable to mount root fs on %s, b);
}
printk(No filesystem could mount root, tried: );
for (p = fs_names; *p; p += strlen(p)+1)
printk( %s, p);
printk(\n);
- panic(VFS: Unable to mount root fs on %s, __bdevname(ROOT_DEV, b));
+
+ err = -1;
out:
putname(fs_names);
+ return err;
}
-
+
+static inline void __init mount_block_root_fail(void)
+{
+ char b[BDEVNAME_SIZE];
+
+ panic(VFS: Unable to mount root fs on %s, __bdevname(ROOT_DEV, b));
+}
+
+void __init mount_block_root(char *name, int flags)
+{
+ if (mount_block_root_try(name, flags) != 0)
+ mount_block_root_fail();
+}
+
+
#ifdef CONFIG_ROOT_NFS
static int __init mount_nfs_root(void)
{
@@ -363,12 +378,12 @@ void __init change_floppy(char *fmt, ...
}
#endif
-void __init mount_root(void)
+static int __init mount_root_try(void)
{
#ifdef CONFIG_ROOT_NFS
if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
if (mount_nfs_root())
- return;
+ return 0;
printk(KERN_ERR VFS: Unable to mount root fs via NFS, trying
floppy.\n);
ROOT_DEV = Root_FD0;
@@ -387,7 +402,18 @@ void __init mount_root(void)
}
#endif
create_dev(/dev/root, ROOT_DEV);
- mount_block_root(/dev/root, root_mountflags);
+ return mount_block_root_try(/dev/root, root_mountflags);
+}
+
+static inline void __init mount_root_fail(void)
+{
+ mount_block_root_fail();
+}
+
+void __init mount_root(void)
+{
+ if (mount_root_try() != 0)
+ mount_root_fail();
}
/*
@@ -396,6 +422,7 @@ void __init mount_root(void)
void __init prepare_namespace(void)
{
int is_floppy;
+ char *p,*pnext;
if (root_delay) {
printk(KERN_INFO Waiting %dsec before mounting root
device...\n,
@@ -405,27 +432,36 @@ void __init prepare_namespace(void)
md_run_setup();
- if (saved_root_name[0]) {
- root_device_name = saved_root_name;
+ for (p=saved_root_name; p *p; p=pnext) {
+ pnext = strchr(p, ',');
+ if (pnext)
+ *pnext++ = '\0';
+ root_device_name = p;
if (!strncmp(root_device_name, mtd, 3)) {
mount_block_root(root_device_name, root_mountflags);
goto out;
}
ROOT_DEV = name_to_dev_t(root_device_name);
+ if (ROOT_DEV == (dev_t)0)
+ continue;
if (strncmp(root_device_name, /dev/, 5) == 0)
root_device_name += 5;
- }
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
- if (initrd_load())
- goto out;
+ if (initrd_load())
+ goto out;
- if (is_floppy rd_doload rd_load_disk(0))
- ROOT_DEV = Root_RAM0;
+ if (is_floppy rd_doload rd_load_disk(0))
+ ROOT_DEV = Root_RAM0;
- mount_root();
+ if (mount_root_try() == 0)
+ goto out;
+
+ }
+ mount_root_fail();
out:
+
Re: kernel cmdline: root=/dev/sdb1,/dev/sda1 fallback?
Tomasz Chmielewski wrote: Al Borchers wrote: Thomas Chmielewski wrote: These all unpleasant tasks could be avoided if it was possible to have a fallback device. For example, consider this hypothetical command line: root=/dev/sdb1,/dev/sda1 Here is a patch to do this, though it sounds like you might have other solutions. This patch is for 2.6.18.1--thanks to Ed Falk for updating my original 2.6.11 patch. If people are interested I can update and test this on the current kernel. It was tested on 2.6.11. Yes, I'd be interested in a patch against a 2.6.19. It is way simpler to do it this way than to do it with initramfs (although not as flexible). I will look do it, but I will be out next week so it may take a while. -- Al I tried your patch against 2.6.19, with some minor changes (as it wouldn't apply), but it didn't work for me (perhaps I just screwed something). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add wait_event_*_lock() functions
On Thursday 10 February 2005 9:39 am, Nishanth Aravamudan wrote: >> It came up on IRC that the wait_cond*() functions from >> usb/serial/gadget.c could be useful in other parts of the kernel. Does >> the following patch make sense towards this? Sure, if people want to use these. I did not push them because they seemed a bit "heavy weight", but the construct is useful and general. The docs should explain that the purpose is to wait atomically on a complex condition, and that the usage pattern is to hold the lock when using the wait_event_* functions or when changing any variable that might affect the condition and waking up the waiting processes. -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] add wait_event_*_lock() functions
On Thursday 10 February 2005 9:39 am, Nishanth Aravamudan wrote: It came up on IRC that the wait_cond*() functions from usb/serial/gadget.c could be useful in other parts of the kernel. Does the following patch make sense towards this? Sure, if people want to use these. I did not push them because they seemed a bit heavy weight, but the construct is useful and general. The docs should explain that the purpose is to wait atomically on a complex condition, and that the usage pattern is to hold the lock when using the wait_event_* functions or when changing any variable that might affect the condition and waking up the waiting processes. -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: > Add an 'owner' field to the objects we are using. Then we can lock the tty > and the ldisc from the tyy_io code rather than in serial.c and friends. This > removes the unload during open/close races we currently have in serial.c > > Take a look at videodev.c for a fairly clear example. Andrew Morton wrote: > I have a work-in-non-progress here which addresses a few of > these things. It would be good if someone could review it > and finish it off... I will take a look. -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: > So I stuck my justify this change to Ted hat on. And failed. > > For one the cleanest way to handle all the locking is to propogate the other > locking fix styles into both the ldisc and serial drivers. At least for 2.4 If I understand you right, the plan is to leave tty_open unchanged (it calls driver close on failed driver open) and try to fix ldisc and serial driver races as much as possible. Correct? Where is an example of the "other locking fix styles" that you and Ted want to apply to the serial drivers? > The advantage of doing that is that modules that do play with use counts will > not do anything worse than they do now, and will remain fully compatible. Leaving tty_open unchanged does have compatibility going for it. > The ldisc race is also real and completely unfixed right now. I would be interested to try to figure this out and fix it--can you give me more of an idea of what the problem is? -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: So I stuck my justify this change to Ted hat on. And failed. For one the cleanest way to handle all the locking is to propogate the other locking fix styles into both the ldisc and serial drivers. At least for 2.4 If I understand you right, the plan is to leave tty_open unchanged (it calls driver close on failed driver open) and try to fix ldisc and serial driver races as much as possible. Correct? Where is an example of the other locking fix styles that you and Ted want to apply to the serial drivers? The advantage of doing that is that modules that do play with use counts will not do anything worse than they do now, and will remain fully compatible. Leaving tty_open unchanged does have compatibility going for it. The ldisc race is also real and completely unfixed right now. I would be interested to try to figure this out and fix it--can you give me more of an idea of what the problem is? -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: Add an 'owner' field to the objects we are using. Then we can lock the tty and the ldisc from the tyy_io code rather than in serial.c and friends. This removes the unload during open/close races we currently have in serial.c Take a look at videodev.c for a fairly clear example. Andrew Morton wrote: I have a work-in-non-progress here which addresses a few of these things. It would be good if someone could review it and finish it off... I will take a look. -- Al - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: > It has to be changed, the race is basically unfixable any other way. I didn't > lightly make that change I agree. The patch seems like the correct solution. What will it take to get the patch in the 2.4.x kernels? Do we need someone to go through the serial drivers and fix their open/close routines to work with this patch? Peter and I can take some time to do that--if that would help. -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Maciej, Ted -- Maciej's patch to tty_io.c from lkml 2/22/01 http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1049.html has been incorporated in RH 7.1's kernel (for example) but not in the main 2.4.x kernels. This presents two different interfaces for serial drivers, and it is awkward to detect and support both interfaces. The change breaks some drivers from Digi International, for example. In Maciej's patch, if a driver open is interrupted the driver close IS NOT called. In the 2.4.x series the close IS called. A serial driver needs to know whether close is going to be called or not after an interrupted open, so it can do clean up--like DEC_MOD_USE_COUNT-- appropriately. Suppose the driver open calls INC_MOD_USE_COUNT, sleeps for the port to get carrier, then gets interrupted. If the open calls DEC_MOD_USE_COUNT after the interrupt, the use count will be right under Maciej's patch but too low on 2.4.x. If the open does not call DEC_MOD_USE_COUNT after an interrupt, instead deferring that for the close, then the use count will be too high under Maciej's patch, but right under 2.4.x. This is particularly a problem if there is another outstanding open on the port--in that case you can end up with zero use count (and a closed port!) while the port is open or a non-zero use count when no one has the port open. Personally, I think Maciej's patch is correct and interrupted opens should clean up after themselves--however, this is a different interface than presented by the tty subsystem up to now, and will require changes in some serial drivers. Ted can you get this patch in the kernel or ban it as interface breaking heresy? It would be much nicer for us device driver writers to have just one interface to support. Thanks, -- Al Borchers, Peter Berger PS. James Puzzo at Digi first pointed out this problem to us. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Maciej, Ted -- Maciej's patch to tty_io.c from lkml 2/22/01 http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1049.html has been incorporated in RH 7.1's kernel (for example) but not in the main 2.4.x kernels. This presents two different interfaces for serial drivers, and it is awkward to detect and support both interfaces. The change breaks some drivers from Digi International, for example. In Maciej's patch, if a driver open is interrupted the driver close IS NOT called. In the 2.4.x series the close IS called. A serial driver needs to know whether close is going to be called or not after an interrupted open, so it can do clean up--like DEC_MOD_USE_COUNT-- appropriately. Suppose the driver open calls INC_MOD_USE_COUNT, sleeps for the port to get carrier, then gets interrupted. If the open calls DEC_MOD_USE_COUNT after the interrupt, the use count will be right under Maciej's patch but too low on 2.4.x. If the open does not call DEC_MOD_USE_COUNT after an interrupt, instead deferring that for the close, then the use count will be too high under Maciej's patch, but right under 2.4.x. This is particularly a problem if there is another outstanding open on the port--in that case you can end up with zero use count (and a closed port!) while the port is open or a non-zero use count when no one has the port open. Personally, I think Maciej's patch is correct and interrupted opens should clean up after themselves--however, this is a different interface than presented by the tty subsystem up to now, and will require changes in some serial drivers. Ted can you get this patch in the kernel or ban it as interface breaking heresy? It would be much nicer for us device driver writers to have just one interface to support. Thanks, -- Al Borchers, Peter Berger PS. James Puzzo at Digi first pointed out this problem to us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0, 2.2.18: A critical problem with tty_io.c
Alan Cox wrote: It has to be changed, the race is basically unfixable any other way. I didn't lightly make that change I agree. The patch seems like the correct solution. What will it take to get the patch in the 2.4.x kernels? Do we need someone to go through the serial drivers and fix their open/close routines to work with this patch? Peter and I can take some time to do that--if that would help. -- Al - 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/
