On Thu, Sep 20, 2012 at 11:48:32PM +0000, Luck, Tony wrote: > > True, but the lock is used to protect pstore->buf, I doubt that > > any backend will actually want to grab it, no? > > The lock is doing double duty to protect the buffer, and the back-end driver. > > But even if we split it into two (one for the buffer, taken by pstore, and one > internal to the backend to protect interaction with the f/w). Ifwe ignore the > fact that we can't get the lock that protects the buffer means it is very > likely > that we corrupt the previous record that was being written by clobbering the > buffer with the data for this new record. > > I'd prefer to maximize the chances that the earlier record gets written.
Sure, I applied the original patch. Btw, do you expect that backends protect themselves from concurrent ->write calls, or pstore guarantees to protect backends? Because the latter is not always possible, for example in tracing: we won't able to grab locks at all (but not all backends can do tracing anyway -- they must do things atomically). Plus, sometimes having the global lock is not "efficient", backends know better: they might have separate locks per message type. And my plan was to get rid of the fact that backends touch pstore->buf directly. Backends would always receive anonymous 'buf' pointer (we already have write_buf callback that does exactly this), and thus it would be backends' worry to protect against concurrency. In this scheme, pstore's console code won't need to grab locks at all: we'll just pass console string to the backend directly. And backends, if they can't do writes atomically, will grab their own locks. 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/
