On 16.03.21 18:14, Jan Kara wrote:
>
> So i_lock is supposed to protect i_opflags for writing AFAICT. For reading
> we don't seem to bother in some cases and I agree that is potentially
> problematic. It is *mostly* OK because we initialize i_opflags when loading
> inode into memory / adding it
On Mon 08-03-21 15:05:33, Alexander Lochmann wrote:
> On 05.03.21 17:04, Theodore Ts'o wrote:
> > On Fri, Mar 05, 2021 at 04:35:47PM +0100, Alexander Lochmann wrote:
> > >
> > >
> > > On 05.03.21 16:18, Theodore Ts'o wrote:
> > > > 1) I don't see where i_opflags is being read in ipc/mqueue.c at
On 05.03.21 17:04, Theodore Ts'o wrote:
On Fri, Mar 05, 2021 at 04:35:47PM +0100, Alexander Lochmann wrote:
On 05.03.21 16:18, Theodore Ts'o wrote:
1) I don't see where i_opflags is being read in ipc/mqueue.c at all,
either with or without i_rwsem.
It is read in fs/dcache.c
So why is t
On Fri, Mar 05, 2021 at 04:35:47PM +0100, Alexander Lochmann wrote:
>
>
> On 05.03.21 16:18, Theodore Ts'o wrote:
> > 1) I don't see where i_opflags is being read in ipc/mqueue.c at all,
> > either with or without i_rwsem.
> >
> It is read in fs/dcache.c
So why is this unique to the mqueue ino
On 05.03.21 16:18, Theodore Ts'o wrote:
1) I don't see where i_opflags is being read in ipc/mqueue.c at all,
either with or without i_rwsem.
It is read in fs/dcache.c
2) I'm not sure what this has to do with ext4?
- Ted
Yeah. You're right. That
On Fri, Mar 05, 2021 at 02:10:09PM +0100, Alexander Lochmann wrote:
> Hi folks,
>
> I've stumbled across an interesting locking scheme. It's related to struct
> inode, more precisely it is an mqueue inode.
> Our results show that inode:mqueue.i_opflags is read with i_rwsem being
> hold.
> In d_fla
Hi folks,
I've stumbled across an interesting locking scheme. It's related to
struct inode, more precisely it is an mqueue inode.
Our results show that inode:mqueue.i_opflags is read with i_rwsem being
hold.
In d_flags_for_inode, and do_inode_permission the i_lock is used to read
and write i_o
7 matches
Mail list logo
