Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Huh, I modify the contents of a branch out from under a union mount just about every day. In fact, that's the only way I ever modify it.
I have yet to see a single oops or data loss problem.
Surely there must be more to triggering this problem.
Posted Jan 11, 2007 9:50 UTC (Thu) by dlang (✭ supporter ✭, #313)
in both cases the filesystem on top doesn't know about the changes below it and can be (fatally) surprised when it finds them.
later messages in the thread indicate that the warning is (somewhat) intentially overstateing the risk of an oops (rather then going into many pages of quickly obsolete details of what will fail)
I suspect that you get away with it by the fact that you are doing read-only on the result.
Posted Jan 13, 2007 0:33 UTC (Sat) by giraffedata (subscriber, #1954)
later messages in the thread indicate that the warning is (somewhat) intentionally overstating the risk of an oops
Do you mean the warning is a lie and it is not in fact possible by design to oops the kernel by modifying an underlying filesystem?
Because that's the only way it's sensible. You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the kernel, the kernel is robust to whatever bits it might read from it at any time.
Posted Jan 13, 2007 4:52 UTC (Sat) by raven667 (subscriber, #5198)
You cannot oops the kernel by writing to /dev/hda1 while an ext3 filesystem on /dev/
hda1 is mounted. You can trash unlimited amounts of data, but as the filesystem is external to the
kernel, the kernel is robust to whatever bits it might read from it at any time.
That seems like how it should be but I doubt that this is true. In fact I
believe one of the major fixes in 18.104.22.168 is CVE-2006-5823 a problem where a corrupte cramfs
could OOPS the kernel. This same kind of think can, has and will continue to happen in the
filesystem, USB, network, Firewire, block device and other subsystems where bogus data from a
piece of hardware isn't sufficiently checked before being used and causes an OOPS (with potential
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds