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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/