kanonenvogel....@gmail.com wrote: > > On 08 Apr 2015, at 02:31, Philip Guenther <guent...@gmail.com> wrote: > > > On Tue, Apr 7, 2015 at 3:57 PM, Kanonenvogel <kanonenvogel....@gmail.com> > > wrote: > >> I have idea to modify falloc() function and related logic. > >> Now, after successful faclloc call, we have half-initialized struct file > >> object, protected by FIF_LARVAL flag. > >> I want to initialise struct file object within falloc() and then put it to > >> fd_ofiles array and filehead list. This modification > >> permits to avoid half-initialization state and remove FIF_LARVAL flag and > >> related logic. > > > > The hard case is blocking opens of fifos, as the underlying operation > > involves a change visible to another process and that therefore cannot > > be rolled back. > > > > > > Philip Guenther > Ok, I understood. > And what about make struct file more smp friendly? For example, make > operations under > f_iflags and f_flags atomic?
This can help, but not always. The atomic functions are quite expensive on some architectures, so we don't want to just use them everywhere. Also, this only helps if you're sure that the code reading the flag will do so in an smp safe way. In many cases, the reading code will also need to acquire a lock in order to correctly do something after reading the flag. From the diff context, it looks like most of this code will definitely already have some other lock.
