Re: panic: ffs_valloc: dup alloc

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Mar 20, 2010, at 4:50 PM, Steven Bellovin wrote:

> 
> On Mar 20, 2010, at 4:17 PM, David Holland wrote:
> 
>> On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
>>>> That suggests that something is flushing buffers to a device that's
>>>> suspended and it's throwing them away instead of rejecting them or
>>>> panicing.
>>> 
>>> Possibly....
>> 
>> Although it doesn't quite make sense, because in most cases this could
>> only corrupt the fs if the same block was left untouched afterwards
>> for long enough for the (allegedly) clean buffer to be discarded, and
>> that shouldn't cause a panic right after resume. Unless the fs was
>> already broken from a previous suspend, I guess.
>> 
>> Maybe there's suspend code somewhere that writes out and also discards
>> buffers in the hopes of cleaning up for some future suspend-to-disk
>> work? Could be, I guess, but I'd tend to think not. I ought to go look
>> at the code but I don't think I have time for that this weekend. :-|
>> 
>>>> Does stuffing a couple sync calls somewhere before it starts
>>>> suspending devices (wherever that is, I don't know) make the problems
>>>> go away?
>>> 
>>> No -- I've had a sync call in my suspend script for years.  More
>>> precisely, at the moment it's
>>> 
>>>     sync; sleep 1
>>> 
>>> to let things flush.  No joy.
>> 
>> That might not be late enough; I was thinking of inside the kernel.
>> 
>>> Of course, rejecting them wouldn't seem to do any good; what's
>>> needed, I suspect, is for the device to queue them (as usual) but
>>> not fire up the disk when in suspending mode.
>> 
>> Or for the writes to not be issued at all until after resume.
>> 
>> ISTM it must be either the syncer firing at the wrong time or
>> something's gotten out of order in the suspend sequencing.
>> 
> 
> Let me see if I can find my first note on the subject -- it might give a clue 
> about the date of any changes.

Turns out that I sendpr-ed it in September: kern/42104.

                --Steve Bellovin, http://www.cs.columbia.edu/~smb