* [RFC] inode.i_opflags - Usage of two different locking schemes [not found] <f63dd495-defb-adc4-aa91-6aacd7f441c7@tu-dortmund.de> @ 2021-03-05 13:10 ` Alexander Lochmann 2021-03-05 15:18 ` Theodore Ts'o 0 siblings, 1 reply; 7+ messages in thread From: Alexander Lochmann @ 2021-03-05 13:10 UTC (permalink / raw) To: Horst Schirmeier, Jan Kara, Theodore Ts'o, Jan Kara, linux-ext4, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 939 bytes --] 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_opflags. Is this a real locking scheme? Is a lock needed to access i_opflags at all? What is the magic behind this contradiction? I've put the report of the counterexamples on our webserver: https://ess.cs.tu-dortmund.de/lockdoc-bugs/cex-inode-mqueue.html. It contains the stacktraces leading to those accesses, and the locks that were actually held. Regards, Alex -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-05 13:10 ` [RFC] inode.i_opflags - Usage of two different locking schemes Alexander Lochmann @ 2021-03-05 15:18 ` Theodore Ts'o 2021-03-05 15:35 ` Alexander Lochmann 0 siblings, 1 reply; 7+ messages in thread From: Theodore Ts'o @ 2021-03-05 15:18 UTC (permalink / raw) To: Alexander Lochmann Cc: Horst Schirmeier, Jan Kara, Jan Kara, linux-ext4, linux-kernel 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_flags_for_inode, and do_inode_permission the i_lock is used to read and > write i_opflags. > Is this a real locking scheme? Is a lock needed to access i_opflags at all? > What is the magic behind this contradiction? > > I've put the report of the counterexamples on our webserver: > https://ess.cs.tu-dortmund.de/lockdoc-bugs/cex-inode-mqueue.html. > It contains the stacktraces leading to those accesses, and the locks that > were actually held. 1) I don't see where i_opflags is being read in ipc/mqueue.c at all, either with or without i_rwsem. 2) I'm not sure what this has to do with ext4? - Ted ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-05 15:18 ` Theodore Ts'o @ 2021-03-05 15:35 ` Alexander Lochmann 2021-03-05 16:04 ` Theodore Ts'o 0 siblings, 1 reply; 7+ messages in thread From: Alexander Lochmann @ 2021-03-05 15:35 UTC (permalink / raw) To: Theodore Ts'o Cc: Horst Schirmeier, Jan Kara, Jan Kara, linux-ext4, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 643 bytes --] 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 was my fault. Sry. I should have sent it to linux-kernel@... only. - Alex -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-05 15:35 ` Alexander Lochmann @ 2021-03-05 16:04 ` Theodore Ts'o 2021-03-08 14:05 ` Alexander Lochmann 0 siblings, 1 reply; 7+ messages in thread From: Theodore Ts'o @ 2021-03-05 16:04 UTC (permalink / raw) To: Alexander Lochmann Cc: Horst Schirmeier, Jan Kara, Jan Kara, linux-ext4, linux-kernel 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 inode then? It might be helpful to have explicit call stacks in the e-mail, in text form, when you resend to LKML. That's because the HTML file is ***huge*** (1.7Meg), and I'm having trouble with my browser properly rendering it. In any case, the html claims to be showing the counter examples and I'm still stuck on the *example*? Cheers, - Ted ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-05 16:04 ` Theodore Ts'o @ 2021-03-08 14:05 ` Alexander Lochmann 2021-03-16 17:14 ` Jan Kara 0 siblings, 1 reply; 7+ messages in thread From: Alexander Lochmann @ 2021-03-08 14:05 UTC (permalink / raw) To: Theodore Ts'o Cc: Horst Schirmeier, Jan Kara, Jan Kara, linux-ext4, linux-kernel [-- Attachment #1.1: Type: text/plain, Size: 1512 bytes --] 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 this unique to the mqueue inode then? It might be helpful > to have explicit call stacks in the e-mail, in text form, when you > resend to LKML. It is unique to mqeue inode, because the control flow goes through ipc/mqueue.c where almost always the i_rwsem is taken. Hence, we see more memory accesses to an mqueue inode with the i_rwsem. The i_lock is less often hold compared to the i_rwsem. We conclude the i_rwsem is needed. So it might not be a contradiction at all. It rather could be a flaw in our approach. :-/ Besides from our current discussion: Does the i_lock protect i_opflags for both reading and writing? Cheers, Alex > > That's because the HTML file is ***huge*** (1.7Meg), and I'm having > trouble with my browser properly rendering it. In any case, the html > claims to be showing the counter examples and I'm still stuck on the > *example*? > > Cheers, > > - Ted > -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 840 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-08 14:05 ` Alexander Lochmann @ 2021-03-16 17:14 ` Jan Kara 2021-03-26 16:37 ` Alexander Lochmann 0 siblings, 1 reply; 7+ messages in thread From: Jan Kara @ 2021-03-16 17:14 UTC (permalink / raw) To: Alexander Lochmann Cc: Theodore Ts'o, Horst Schirmeier, Jan Kara, Jan Kara, linux-ext4, linux-kernel 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 all, > > > > either with or without i_rwsem. > > > > > > > It is read in fs/dcache.c > > > > So why is this unique to the mqueue inode then? It might be helpful > > to have explicit call stacks in the e-mail, in text form, when you > > resend to LKML. > It is unique to mqeue inode, because the control flow goes through > ipc/mqueue.c where almost always the i_rwsem is taken. > Hence, we see more memory accesses to an mqueue inode with the i_rwsem. > The i_lock is less often hold compared to the i_rwsem. > We conclude the i_rwsem is needed. So it might not be a contradiction at > all. It rather could be a flaw in our approach. :-/ > > Besides from our current discussion: > Does the i_lock protect i_opflags for both reading and writing? 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 to dcache. But sometimes we also update them while the inode is alive. Now this is fine for the particular flag we update but in theory, if the compiler wants to screw us and stores temporarily some nonsensical value in i_opflags we'd have a problem. This is mostly a theoretical issue but eventually we probably want to fix this. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] inode.i_opflags - Usage of two different locking schemes 2021-03-16 17:14 ` Jan Kara @ 2021-03-26 16:37 ` Alexander Lochmann 0 siblings, 0 replies; 7+ messages in thread From: Alexander Lochmann @ 2021-03-26 16:37 UTC (permalink / raw) To: Jan Kara Cc: Theodore Ts'o, Horst Schirmeier, Jan Kara, linux-ext4, linux-kernel 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 to dcache. But sometimes we also update them > while the inode is alive. Now this is fine for the particular flag we > update but in theory, if the compiler wants to screw us and stores > temporarily some nonsensical value in i_opflags we'd have a problem. This > is mostly a theoretical issue but eventually we probably want to fix this. > > Honza > Thx for the detailed explanation. :-) - Alex -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-03-26 16:38 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <f63dd495-defb-adc4-aa91-6aacd7f441c7@tu-dortmund.de> 2021-03-05 13:10 ` [RFC] inode.i_opflags - Usage of two different locking schemes Alexander Lochmann 2021-03-05 15:18 ` Theodore Ts'o 2021-03-05 15:35 ` Alexander Lochmann 2021-03-05 16:04 ` Theodore Ts'o 2021-03-08 14:05 ` Alexander Lochmann 2021-03-16 17:14 ` Jan Kara 2021-03-26 16:37 ` Alexander Lochmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).