On Wed, 19 Sep 2012, Linus Torvalds wrote: > That does look simpler, and avoiding the lock is a good idea. Since we > don't support lseek() (or pread/pwrite) on that thing anyway, there's > no way to keep the fd open and just re-use it to read the data over > and over, so populating it at open time sounds like a good solution > with no real downsides. >
Yeah, my patch is functionally the same as what we currently have with the only exception being that it isn't racy. I'm wondering if that's what we really want, though, since the data read from the file will remain persistent as long as it is opened. That obviously happens in my patch because we allocate and copy the buffer at open(), but also happens implicitly with the old code precisely because it's a non-seekable file and *ppos == 0 only once (when not racy). So if the API for these xen files is to remain persistent after open() as it currently does, then my patch solves the issue. However, if the API wants to allow to only open() once and then read the spinlock_stats data continuously, then we'll need the mutex: allocate the file->private_data buffer once at open() for the maximum allowable size and then copy to the buffer from xen's spinlock_stats under the protection of the mutex to read(). Konrad? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
