On Sun, 16 Jan 2000, Andrea Arcangeli wrote:
> On Sat, 15 Jan 2000, Alexander Viro wrote:
>
> >Folks, looks like we have a funny failure mode: we invalidate buffers only
> >upon close(), right? Well, going through the partition table happens
>
> There's no point in calling invalidate buffers on close in first place.
>
> >without open(). So consider the following scenario:
> > we insmod the driver foo.
> > it reads partition table for /dev/foo, doing it via bread() and
> >populating the page cache.
> > we rmmod it.
> > change the disk.
> > insmod again.
> > oops, we got stale buffer_heads.
>
> A good driver won't have any problem. A good driver should call
> check_disk_change() as first thing on each open/read/write/partition-table
> read.
Good driver should not do partition-table reads in the first place.
Period. And frankly, the more I'm looking through that code the more I
believe that _any_ nontrivial conventions will be broken/misunderstood/
forgotten/not propagated by 10-20 percents of drivers. The fewer things
we have to leave for driver, the less fuckups we will get. If you don't
believe me - look through the drivers and compare.
> >Options: short-term one - do invalidation in cleanup_module() (some
> >drivers do, some don't); possibly better variant - don't bother with
> >buffer cache in partition parsing. For now I'ld go for the former -
> >implementing the latter will not change interface, so it can be done more
> >or less at leisure... Comments?
>
> destroy_buffers in cleanup_module should be called anyway.
Probably. Most likely by unregister_disk() (will go in the next chunk).
Again, I don't believe that driver writers will care to trace the policy.
No offence to anybody, but it _just_ _does_ _not_ _happen_. And I don't
give a damn for any theories - leaving the common stuff to drivers we are
inviting the Fuckup Fairy. Even for the stuff in the main tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:14 EST