[PATCH] Fix sync. in inode_has_no_xattr()

07: fdput:38 06: vfs_write:560 05: __vfs_write:512 04: new_sync_write:500 03: blkdev_write_iter:1977 02: __generic_file_write_iter:2897 01: file_remove_privs:1818 00: inode_has_no_xattr:3163 Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf Spinczyk) Signed-off-by: Alexander Lochmann

[PATCH] Fix sync. in blkdev_write_iter() acessing i_flags

: inode_has_no_xattr:3163 If S_NOSEC is *not* set, i_rwsem is acquired around __generic_file_write_iter(). Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf Spinczyk) Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- fs/block_dev.c | 12 1 file changed, 12

Re: [PATCH] Fix sync. in blkdev_write_iter() acessing i_flags

On 07.12.18 18:58, Al Viro wrote: > On Fri, Dec 07, 2018 at 05:10:15PM +0100, Alexander Lochmann wrote: >> >> inode.i_flags might be altered without proper >> synchronisation when the inode belongs to devtmpfs. >> blkdev_write_iter() starts writing via __generic_file

Re: [PATCH] Fix sync. in inode_has_no_xattr()

suggestion, I'm not sure which inode to use: In blkdev_write_iter() there is the "bd_inode = bdev_file_inode(file)". file_remove_privs() uses "inode = file_inode(file)" as a parameter for inode_has_no_xattr(). So, do file->f_mapping->host and f->f_inode refer to t

[PATCH] Abort file_remove_privs() for non-reg. files

: inode_has_no_xattr:3163 Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf Spinczyk) Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- fs/inode.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 35d2108d567c..682088190413

Re: [v2] Updated locking documentation for transaction_t

Thanks, Ted, for your feedback! I'll submit a modified version. - Alex On 07.04.19 18:52, Theodore Ts'o wrote: > On Mon, Mar 18, 2019 at 07:42:37PM +0100, Alexander Lochmann wrote: >> /*t >> - * Where in the log does this transaction's commit start? [no lo

[PATCH v3] Updated locking documentation for transaction_t

We used LockDoc to derive locking rules for each member of struct transaction_t. Based on those results, we extended the existing documentation by more members of struct transaction_t, and updated the existing documentation. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier

[PATCH v3] Updated locking documentation for transaction_t

Some members of transaction_t are allowed to be read without any lock being held if accessed from the correct context. We used LockDoc's findings to determine those members. Each member of them is marked with a short comment: "no lock needed for jbd2 thread". Signed-off-by: Ale

[PATCH 1/2] Updated locking documentation for transaction_t

uot;. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include/linux/jbd2.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h index 99d3cd051ac3..18f77d9b1745 100644 --- a/include/linux/jbd2.h +++ b/include/lin

[PATCH 1/2] Updated locking documentation for transaction_t

uot;. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include/linux/jbd2.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h index 99d3cd051ac3..18f77d9b1745 100644 --- a/include/linux/jbd2.h +++ b/include/lin

[PATCH 2/2] Updated locking documentation for journal_t

uot;. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include/linux/jbd2.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h index 18f77d9b1745..4dca33a063dd 100644 --- a/include/linux/jbd2.h +++ b/

[PATCH] KCOV: Introduced tracing unique covered PCs

store every fourth byte of the text segment. In contrast to KCOV_MODE_TRACE_PC, the shared buffer cannot overflow. Thus, all executed PCs are recorded. Signed-off-by: Alexander Lochmann --- Documentation/dev-tools/kcov.rst | 80 include/linux/kcov.h | 4

[PATCH v2] Updated locking documentation for journal_t

uot;. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier Reviewed-by: Jan Kara --- include/linux/jbd2.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h index 18f77d9b1745..4dca33a063dd 100644 --- a/includ

Re: [PATCH 1/2] Updated locking documentation for transaction_t

Alex -- Technische Universität Dortmund Alexander LochmannPGP 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 OpenPGP_signature Description: OpenPGP digital signature

[PATCH v2] Updated locking documentation for transaction_t

Some members of transaction_t are allowed to be read without any lock being held if accessed from the correct context. We used LockDoc's findings to determine those members. Each member of them is marked with a short comment: "no lock needed for jbd2 thread". Signed-off-by: Ale

[PATCH] Updated locking documentation for journal_head

LockDoc's results show that t_list_lock has been replaced by j_list_lock for b_next_transaction, b_tnext, and b_tprev. We, therefore, updated the documentation accordingly. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include/linux/journal-head.h | 4 ++-- 1

[PATCH v2] Updated locking documentation for journal_head

LockDoc's results show that t_list_lock has been replaced by j_list_lock for b_next_transaction, b_tnext, and b_tprev. We, therefore, updated the documentation accordingly. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier Reviewed-by: Jan Kara --- include/linux/journal-h

Re: [PATCH] Introduced new tracing mode KCOV_MODE_UNIQUE.

On 22.03.21 13:17, Miguel Ojeda wrote: > Hi Alexander, > > On Sun, Mar 21, 2021 at 8:14 PM Alexander Lochmann > wrote: >> >> diff --git a/Documentation/dev-tools/kcov.rst >> b/Documentation/dev-tools/kcov.rst >> index d2c4c27e1702..e105ffe6b6e3 100

Re: [PATCH] Introduced new tracing mode KCOV_MODE_UNIQUE.

ck_irqrestore(&kcov->lock, flags); >> @@ -515,6 +525,8 @@ static int kcov_get_mode(unsigned long arg) >> { >> if (arg == KCOV_TRACE_PC) >> return KCOV_MODE_TRACE_PC; >> + else if (arg == KCOV_UNIQUE_PC) >> + r

[RFC] inode.i_opflags - Usage of two different locking schemes

aces leading to those accesses, and the locks that were actually held. Regards, Alex -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556116 h

Re: [RFC] inode.i_opflags - Usage of two different locking schemes

're right. That was my fault. Sry. I should have sent it to linux-kernel@... only. - Alex -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556

[PATCH] Introduced new tracing mode KCOV_MODE_UNIQUE.

contrast to KCOV_MODE_TRACE_PC, the shared buffer cannot overflow. Thus, all executed PCs are recorded. Signed-off-by: Alexander Lochmann --- Documentation/dev-tools/kcov.rst | 80 +++ include/linux/kcov.h | 12 ++-- include/uapi/linux/kcov.h| 10

Re: [PATCH] KCOV: Introduced tracing unique covered PCs

ould try to add an additional pointer parameter for mode. I > think after inlining the compiler should be able to regestrize it. > Should kcov->mode be written directly to that ptr? Otherwise, it must be written to the already present variable mode, and than copied to the ptr (if not NULL). - Alex -- Alexander LochmannPGP key: 0xBC3EF6FD Heiliger Weg 72 phone: +49.231.28053964 D-44141 Dortmund mobile: +49.151.15738323

Re: [PATCH 1/2] Updated locking documentation for transaction_t

nse to ignore all memory accesses to a transaction_t (or parts of it) that happen in the commit phase. They deliberately ignore the locking policy, and would confuse our approach. Is the commit phase performed by jbd2_journal_commit_transaction()? We would add this function to our blacklist for trans

Re: [RFC] inode.i_opflags - Usage of two different locking schemes

gt; 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 LochmannPGP key: 0xBC

[PATCHv3] Introduced new tracing mode KCOV_MODE_UNIQUE.

contrast to KCOV_MODE_TRACE_PC, the shared buffer cannot overflow. Thus, all executed PCs are recorded. Signed-off-by: Alexander Lochmann --- Documentation/dev-tools/kcov.rst | 79 + include/linux/kcov.h | 12 ++-- include/uapi/linux/kcov.h| 10

Re: [PATCH v2] Updated locking documentation for journal_t

Does this patch look good to you? Might it be ready to be merged? - Alex On 11.02.21 10:51, Alexander Lochmann wrote: > Some members of transaction_t are allowed to be read without > any lock being held if consistency doesn't matter. > Based on LockDoc's findings, we e

Re: [PATCH v3] Updated locking documentation for transaction_t

Does this patch look good to you either? - Alex On 11.02.21 18:14, Alexander Lochmann wrote: > Some members of transaction_t are allowed to be read without > any lock being held if accessed from the correct context. > We used LockDoc's findings to determine those members. > Ea

Re: [PATCH] KCOV: Introduced tracing unique covered PCs

Can I enforce inlining? I'm using GCC 9.3 on Debian Testing. - Alex -- Alexander LochmannPGP key: 0xBC3EF6FD Heiliger Weg 72 phone: +49.231.28053964 D-44141 Dortmund mobile: +49.151.15738323

Re: [PATCH v3] Updated locking documentation for transaction_t

On 03.12.20 15:04, Theodore Y. Ts'o wrote: On Thu, Oct 15, 2020 at 03:26:28PM +0200, Alexander Lochmann wrote: Hi folks, I've updated the lock documentation according to our finding for transaction_t. Does this patch look good to you? I updated the annotations to match with the l

Re: [PATCH] KCOV: Introduced tracing unique covered PCs

return KCOV_MODE_UNIQUE_PC; > > As far as I understand, users can first do KCOV_INIT_UNIQUE and then > enable KCOV_TRACE_PC, or vice versa. > It looks somewhat strange. Is it intentional? I'll fix that. It's not possible to > specify buffer size for KCOV_INIT_UNIQUE, so most likely the buffer > will be either too large or too small for a trace. No, the buffer will be calculated by KCOV_INIT_UNIQUE based on the size of the text segment. - Alex -- Alexander LochmannPGP key: 0xBC3EF6FD Heiliger Weg 72 phone: +49.231.28053964 D-44141 Dortmund mobile: +49.151.15738323

Re: [RFC] inode.i_opflags - Usage of two different locking schemes

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/dcach

[PATCH v2] Updated locking documentation for transaction_t

We used LockDoc to derive locking rules for each member of struct transaction_t. Based on those results, we extended the existing documentation by more members of struct inode, and updated the existing documentation. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include

Re: [PATCH] Abort file_remove_privs() for non-reg. files

Hello Al, Meanwhile, have you had the opportunity to review our patch? Regards, Alex On 11.01.19 16:42, Alexander Lochmann wrote: > Hello Al, > > Have you had the opportunity to review our patch? > > Cheers, > Alex > > On 17.12.18 09:28, Jan Kara wrote: >> On Fr

[PATCH 1/1] Updated locking documentation for struct journal_t

We used LockDoc to derive locking rules for each member of struct journal_t. Based on those results, we extended the existing documentation by more members of struct inode, and updated the existing documentation. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- include

[PATCH 1/1] Updated locking documentation for struct inode

We used LockDoc to derive locking rules for each member of struct inode. Based on those results, we extended the existing documentation by more members of struct inode, and updated the existing documentation. Signed-off-by: Alexander Lochmann Signed-off-by: Horst Schirmeier --- fs/inode.c

Re: [PATCH] Abort file_remove_privs() for non-reg. files

Hello Al, Have you had the opportunity to review our patch? Cheers, Alex On 17.12.18 09:28, Jan Kara wrote: > On Fri 14-12-18 11:55:52, Alexander Lochmann wrote: >> >> file_remove_privs() might be called for non-regular files, e.g. >> blkdev inode. There is no reason to

[x86] BUG()/BUG_ON() macros cannot be disabled

developer wants it. It undefines the respective x86 variants, and defines both macros as 'empty' macros. Regards, Alex -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dor

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

Am 25.09.2018 um 14:06 schrieb Arnd Bergmann: > On Tue, Sep 25, 2018 at 1:35 PM Alexander Lochmann > wrote: >> >> Hi Arnd, >> >> I recently tried to disable the BUG macros on x86-32. I disabled the >> config item in 'General Setup -> Configure stand

Re: [x86] BUG()/BUG_ON() macros cannot be disabled

now what the purpose of BUG()/BUG_ON() is, I would not consider the above example as valid C code Defining BUG as an endless loop to overcome GCC warnings about not returning a value is a dirty hack for me. - Alex -- Technische Universität Dortmund Alexander LochmannPGP

Non-zero preemption count on voluntary preemptive kernel

een acquired. The fourth column is the preemption count, as returned by preemption_count(), after acquiring the lock. The last column tells how often this happens. I attached my kernel config as well. Can you please tell why this happens? Have I missed something? Might this be a bug? Thanks! Regards, Alex --

[RFC] perf record: missing buildid for callstack modules -- again

rkaround for it? Thanks in advance! Cheers, Alex P.S.: Pls put me in CC, because I'm not subscribed to the mailinglist. -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund

[PATCH v3] Updated locking documentation for transaction_t

Hi folks, I've updated the lock documentation according to our finding for transaction_t. Does this patch look good to you? Cheers, Alex commit 13ac907c45c5da7d691f6e10972de5e56e0072c6 Author: Alexander Lochmann Date: Thu Oct 15 15:24:52 2020 +0200 Updated locking documentatio

Re: [PATCH v3] Updated locking documentation for transaction_t

Hi Ted, Have you had the chance to review the most recent version of the patch? Does it look reasonable to you? Cheers, Alex On 08.04.19 10:35, Alexander Lochmann wrote: > We used LockDoc to derive locking rules for each member > of struct transaction_t. > Based on those results, we