Opened 2 years ago

Closed 9 months ago

#13555 closed bug (fixed)

Destroying ramdisk without unmounting first causes KDL

Reported by: waddlesplash Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Not sure what component to file this under.

If one creates a RAMdisk and initializes with BFS...

ramdisk create -s 1gb
mkfs -q -t bfs /dev/disk/virtual/ram/0/raw RAMses
mountvolume RAMses

and then attempts to delete it without unmounting first

ramdisk delete 0

there is an instant KDL (inside the BFS driver, of course.)

It looks like the BFS driver does not have the chance to fully deinitialize before the disk is destroyed. Manually unmounting and then deleting the ramdisk works just fine.

Attachments (2)

ticket-13555-KDL-hrev52357-x86_gcc2.txt (3.9 KB ) - added by fbrosson 12 months ago.
ticket-13555-KDL-hrev52357-x86_64.txt (4.1 KB ) - added by fbrosson 12 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 by waddlesplash, 2 years ago

(I'm experimenting with using a ramdisk for building ports on the slave machines to speed up stuff, but I'm a bit wary of doing so when an improperly executed reboot could cause a KDL...)

If someone could take a look at this, or possibly point me in the right direction so that I could attempt a fix (I've no idea where to begin), I'd very much appreciate it.

comment:2 by fbrosson, 12 months ago

IMHO this bug should be fixed before R1/beta1.
Forgetting to unmount a volume before calling ramdisk delete <n>can happen to anyone.
Users hitting this bug in a beta release will be very upset.
We don't want users to go away for this reason.
This bug should not be too hard to fix for a kernel developer who already knows where to look.

Last edited 12 months ago by fbrosson (previous) (diff)

comment:3 by pulkomandy, 12 months ago

ramdisk are not a common thing for users to do. And, it's a beta, there will be bugs, many of them more embarassing than this one.

This bug should not be too hard to fix for a kernel developer who already knows where to look.

What do you know? Patches welcome if it's easy for you ;)

where to look: src/add-ons/kernel/drivers/disk/virual/ram_disk, probably?

There isn't even a log of the KDL in the ticket, that would make it easier to investigate (I don't feel like crashing my own system to grab it).

comment:4 by fbrosson, 12 months ago

The 2 logs were obtained with these commands:

~> ramdisk create -s 32mb
RAM disk device created as "/dev/disk/virtual/ram/0/raw"
~> mkfs -q -t bfs /dev/disk/virtual/ram/0/raw ramwork
DiskDeviceJobQueue::Execute(): executing job: Q28BPrivate13InitializeJob
~> mountvolume ramwork
Volume `ramwork' mounted successfully at '/ramwork'.
~> ramdisk delete 0

comment:5 by waddlesplash, 9 months ago

Resolution: fixed
Status: newclosed

Ha, another one that was fixed in hrev52646.

Note: See TracTickets for help on using tickets.