2000-11-20 03:52:30

by Werner Almesberger

[permalink] [raw]
Subject: [PATCH,RFC] initrd vs. BLKFLSBUF

Hi Al,

Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk
that was obtained via initrd. I think the problem is that the effect of
the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is
not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that
seems to solve the problem. Since I'm not quite sure I understand the
reference counting rules there, I would appreciate your comment.

Thanks,
- Werner

---------------------------------- cut here -----------------------------------

--- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
done:
if (infile.f_op->release)
infile.f_op->release(inode, &infile);
+ blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
free_inodes: /* free inodes on error */

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/


2000-11-20 08:09:08

by Jeff Chua

[permalink] [raw]
Subject: Re: [PATCH,RFC] initrd vs. BLKFLSBUF

Werner,

Thanks for fix. Applied the patch and it's working now.

Linus, please add this patch to the kernel source codes for 2.4.0.

Under 2.2.18, it's working fine without the patch.

Thanks,
Jeff
[ [email protected] ]
----- Original Message -----
From: "Werner Almesberger" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, November 20, 2000 11:21 AM
Subject: [PATCH,RFC] initrd vs. BLKFLSBUF


Hi Al,

Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk
that was obtained via initrd. I think the problem is that the effect of
the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is
not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that
seems to solve the problem. Since I'm not quite sure I understand the
reference counting rules there, I would appreciate your comment.

Thanks,
- Werner

---------------------------------- cut
here -----------------------------------

--- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
done:
if (infile.f_op->release)
infile.f_op->release(inode, &infile);
+ blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
free_inodes: /* free inodes on error */

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/


2000-12-11 12:23:23

by Jeff Chua

[permalink] [raw]
Subject: Re: [PATCH,RFC] initrd vs. BLKFLSBUF

I'm posting this again hoping that it'll get incorporated into the kernel.

I've tested the patch against 2.4.0-test12-pre8, and it's working fine.

Thanks,
Jeff
[ [email protected] ]
----- Original Message -----
From: "Werner Almesberger" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, November 20, 2000 11:21 AM
Subject: [PATCH,RFC] initrd vs. BLKFLSBUF


Hi Al,

Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk
that was obtained via initrd. I think the problem is that the effect of
the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is
not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that
seems to solve the problem. Since I'm not quite sure I understand the
reference counting rules there, I would appreciate your comment.

Thanks,
- Werner

---------------------------------- cut
here -----------------------------------

--- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
done:
if (infile.f_op->release)
infile.f_op->release(inode, &infile);
+ blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
free_inodes: /* free inodes on error */

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/


2000-12-11 12:32:04

by Jeff Chua

[permalink] [raw]
Subject: Re: [PATCH,RFC] initrd vs. BLKFLSBUF

I'm posting this again hoping that it'll get incorporated into the kernel.

I've tested the patch against 2.4.0-test12-pre8, and it's working fine.

Thanks,
Jeff
[ [email protected] ]
----- Original Message -----
From: "Werner Almesberger" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, November 20, 2000 11:21 AM
Subject: [PATCH,RFC] initrd vs. BLKFLSBUF


Hi Al,

Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk
that was obtained via initrd. I think the problem is that the effect of
the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is
not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that
seems to solve the problem. Since I'm not quite sure I understand the
reference counting rules there, I would appreciate your comment.

Thanks,
- Werner

---------------------------------- cut
here -----------------------------------

--- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000
@@ -690,6 +690,7 @@
done:
if (infile.f_op->release)
infile.f_op->release(inode, &infile);
+ blkdev_put(out_inode->i_bdev, BDEV_FILE);
set_fs(fs);
return;
free_inodes: /* free inodes on error */

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/



2000-12-11 15:31:45

by Werner Almesberger

[permalink] [raw]
Subject: Re: [PATCH,RFC] initrd vs. BLKFLSBUF

Jeff Chua wrote:
> I'm posting this again hoping that it'll get incorporated into the kernel.

It's already in Alan's tree (e.g. patch-2.4.0test11-ac1.bz2) and should
find its way from there into Linus' tree soon (i.e. probably by test12).

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/