Skip to contentSkip to conversation

Can't free the ramdisk (initrd, pivot_root)

DISCUSSION H. Peter Anvin 2 participants 3 messages Apr 15, 2001 – Apr 16, 2001

lore
Share & tools
lore
#0 lore raw

Hello friends,

I am trying the following setup, and it works beautifully, *except* that I don't seem to be able to free the ramdisk memory at the end. This is using the 2.4.3 stock kernel:

I load an initrd in "non-initrd" mode:

label single
kernel vmlinuz
append initrd=initrd.gz root=/dev/ram0 init=/linuxrc single

The initrd sets up a ramfs which is intended to become the root filesystem, and then calls pivot_root:

[....]
umount /proc

# At this point, all that is mounted is /ram and /ram/usr

# Switch roots and run init
cd /ram
pivot_root /ram /ram/initrd
exec /sbin/init "$@"

(And yes, the /ram/initrd mount point directory does exist.)

This successfully runs init, and I can umount /initrd in the new setup, but I cannot then destroy the ramdisk contents by calling ioctl([/dev/ram0], BLKFLSBUF, 0) -- it always returns EBUSY. What is holding this ramdisk busy, especially since I could successfully umount the filesystem? Seems like a bug to me.

-hpa

Signature · 3 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
#1 lore raw
Quoted 4 lines · H. Peter Anvin

Hello friends,

I am trying the following setup, and it works beautifully, *except* that I don't seem to be able to free the ramdisk memory at the end.

Heh, sounds familiar, I was in exactly the same situation a month ago. I meant to post something about it, but kept forgetting.

Quoted 5 lines

This successfully runs init, and I can umount /initrd in the new setup, but I cannot then destroy the ramdisk contents by calling ioctl([/dev/ram0], BLKFLSBUF, 0) -- it always returns EBUSY. What is holding this ramdisk busy, especially since I could successfully umount the filesystem? Seems like a bug to me.

Indeed it is. This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):

@@ -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 */

has been in Alan's tree since some time in November (it first appeared in the 2.4.0test11ac1 Change Log).

Another ramdisk gotcha that also still exists is that cramfs still seems to be hosing the ramdisk superblock if it's compiled into the kernel. I had to not only switch to romfs for my initrd, but also compile cramfs support out of the kernel. There was a big discussion about this exact problem back in January, but none of the suggested fixes seem to have been incorporated.

Scott

Signature · 5 lines
=============================================================================
Scott Murray                                        email: [email protected]
http://www.spiteful.org (coming soon)                 ICQ: 10602428
-----------------------------------------------------------------------------
     "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"
#2 lore raw
In reply to H. Peter Anvin
Followup to:  <[email protected]>
By author:    Scott Murray <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 3 lines

Indeed it is. This fix for drivers/block/rd.c (excerpted from 2.4.3-ac6):

This did the trick. I bounced the patch to Linus, too.

-hpa

Signature · 3 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt