Re: Stop scheduler on panic

on 14/11/2011 15:08 Kostik Belousov said the following:
> On Mon, Nov 14, 2011 at 12:06:48PM +0200, Andriy Gapon wrote:
>> On a more serious note:
>> - some code in my latest version of the patch was contributed by or was based
>> on the code or ideas contributed by jhb and mdf (so that attributions are not
>> lost)

Oops, forgot the most recent and quite big contribution from Attilio.

> Please provide me with proper attribution for contributors and testers.

My memory has faded a bit, so let's make it simple.
In cooperation with:	attilio, avg, jhb, kib, mdf
Tested by:		avg,
			Eugene Grosbein <eugen_at_grosbein.net>,
			gnn,
			Steven Hartland <killing_at_multiplay.co.uk>,
			glebius,
			kib
[strike out obvious/unnecessary]

>> - there was a concern about how sync-on-panic would work
>>
>> About the latter, I have never really tested it. mdf has suggested to
>> move the sync-on-panic code to a place after we ensure that there is
>> only one CPU in panic(), but before we stop other CPUs.
> sync_on_panic is incompatible with the patch. I argue that it provides
> non-zero chance of damaging good filesystems even if panic was unrelated
> to the fs/bio/device layer. As an example, consider the case when other
> CPU was modifying in-memory representation of the metadata, and panic
> happen on this CPU. If you write half-changed block back, you make more
> damage to the filesystem then if you do not. The half-backed sync spoils
> any journaling or SU consistency guarantees.

Not sure how this is different from what we have right now (without the patch).
Perhaps I misunderstand what you say, but, just in case, the proposal was to do
sync-on-panic before stopping other CPUs.

> The issues of multithreading nature of our storage subsystem are secondary.
> 
> The user who sets either tunable shall know what he does.

That has always been the case.
and apparently there are people who still want this option to exist.

>> I think that I've already sent you a list of the early testers for
>> various WIP versions of the patch.
> I do not have the list.

Included above.

> BTW, if you want, feel free to handle the commit youself. You definitely
> spent much more efforts on the stuff and deserve the credit.
> 
> I was promised in private that a review will be provided during this
> weekend.

Unfortunately too little time and spare mind capacity to do the commit now.
I do not care much about the credit (or commit-o-meter) as long as we get
functionality in.  It was/is a collective effort in any case.
Besides I won't be able to handle any potential regression reports in a
sufficiently speedy manner.

-- 
Andriy Gapon