lkml.org 
[lkml]   [2012]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] pstore: avoid recursive spinlocks in the oops_in_progress case
On Thu, Sep 20, 2012 at 11:09:36PM +0000, Luck, Tony wrote:
> > Mm... why break?
>
> We don't know what the back-end driver will do if we allow another call
> while a previous one is still in progress. It might end up corrupting the
> backing non-volatile storage and losing some previously saved records.

True, but the lock is used to protect pstore->buf, I doubt that
any backend will actually want to grab it, no?

Since it is pstore that is handing the buffer to backend, it is
pstore's worry to do proper locking.

> Existing drivers (ERST and EFI) are dependent on f/w ... so things might
> work on some platforms, yet be horribly bad on others.
>
> The patch as it was written converts a deadlock (hang) case into a "lose
> this log, but keep going" case. Which seems to be an improvement without
> taking any risks about what the backend will do.

But why backends should (or want/will want to) grab this lock?..

If a backend needs its own locking in ->write callback, then it'll
have to use its own lock, I guess.

Thanks,
Anton.


\
 
 \ /
  Last update: 2012-09-21 02:01    [W:0.059 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site