diff for duplicates of <1506649980.5691.100.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 306e127..3f6a5e3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,7 +11,7 @@ On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote: > Umm. You already have an explicit invalidation model, where you > invalidate after a write has occurred. -Invalidating after each write would be horrible performance. Only +Invalidating after each write would be horrible performance. ?Only after all the changes are made, after the file close, is the file integrity status invalidated and the file hash re-calculated and written out. @@ -24,7 +24,7 @@ file integrity invalidation. > the actual appraisal. The locking issue isn't with validating the file hash, but with the -setxattr, chmod, chown syscalls. Each of these syscalls takes the +setxattr, chmod, chown syscalls. ?Each of these syscalls takes the i_rwsem exclusively before IMA (or EVM) is called. In ima_file_free(), the locking would be: @@ -37,7 +37,7 @@ unlock iint->mutex In setxattr, chmod, chown syscalls, IMA (and EVM) are called after the -i_rwsem is already taken. So the locking would be: +i_rwsem is already taken. ?So the locking would be: lock: i_rwsem lock: iint->mutex @@ -48,7 +48,7 @@ unlock: i_rwsem Perhaps now the problem is clearer? Mimi - +? > So make the appraisal itself use a semaphore ("only one appraisal at a time"). > @@ -90,4 +90,9 @@ Mimi > No? > > Linus -> +> + +-- +To unsubscribe from this list: send the line "unsubscribe linux-security-module" in +the body of a message to majordomo at vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 61c70fa..39d5a39 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,18 +4,10 @@ "ref\0CA+55aFy-kDL5jQb0q2gHkcmhAwMatEf8YPx8Gh=yGp_VMoVxQA@mail.gmail.com\0" "ref\01506643967.5691.46.camel@linux.vnet.ibm.com\0" "ref\0CA+55aFxqpTbC=sZXrbJ0x1OD-UA1NkejuR_s5LCazp+7yzvi3Q@mail.gmail.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[RFC PATCH 3/3] fs: detect that the i_rwsem has already been taken exclusively\0" "Date\0Thu, 28 Sep 2017 21:53:00 -0400\0" - "To\0Linus Torvalds <torvalds@linux-foundation.org>\0" - "Cc\0Dave Chinner <david@fromorbit.com>" - LSM List <linux-security-module@vger.kernel.org> - linux-fsdevel <linux-fsdevel@vger.kernel.org> - linux-integrity@vger.kernel.org - Christoph Hellwig <hch@infradead.org> - Linux Kernel Mailing List <linux-kernel@vger.kernel.org> - Jan Kara <jack@suse.cz> - " Theodore Ts'o <tytso@mit.edu>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote:\n" @@ -31,7 +23,7 @@ "> Umm. You already have an explicit invalidation model, where you\n" "> invalidate after a write has occurred.\n" "\n" - "Invalidating after each write would be horrible performance. Only\n" + "Invalidating after each write would be horrible performance. ?Only\n" "after all the changes are made, after the file close, is the file\n" "integrity status invalidated and the file hash re-calculated and\n" "written out.\n" @@ -44,7 +36,7 @@ "> the actual appraisal.\n" "\n" "The locking issue isn't with validating the file hash, but with the\n" - "setxattr, chmod, chown syscalls. Each of these syscalls takes the\n" + "setxattr, chmod, chown syscalls. ?Each of these syscalls takes the\n" "i_rwsem exclusively before IMA (or EVM) is called.\n" "\n" "In ima_file_free(), the locking would be:\n" @@ -57,7 +49,7 @@ "\n" "\n" "In setxattr, chmod, chown syscalls, IMA (and EVM) are called after the\n" - "i_rwsem is already taken. So the locking would be:\n" + "i_rwsem is already taken. ?So the locking would be:\n" "\n" "lock: i_rwsem\n" "lock: iint->mutex\n" @@ -68,7 +60,7 @@ "Perhaps now the problem is clearer?\n" "\n" "Mimi\n" - " \n" + "?\n" "\n" "> So make the appraisal itself use a semaphore (\"only one appraisal at a time\").\n" "> \n" @@ -110,6 +102,11 @@ "> No?\n" "> \n" "> Linus\n" - > + "> \n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -084d46e63263d747862caf820116d0f6f6d5a4c09cfd39b6a3e1f7d9eb00b09c +5eeaa98226779acee3c88ac9937f9624664410f7b93cc85f8f0af7aab7ea4b12
diff --git a/a/1.txt b/N2/1.txt index 306e127..c5a1a4d 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -11,7 +11,7 @@ On Thu, 2017-09-28 at 17:33 -0700, Linus Torvalds wrote: > Umm. You already have an explicit invalidation model, where you > invalidate after a write has occurred. -Invalidating after each write would be horrible performance. Only +Invalidating after each write would be horrible performance. Only after all the changes are made, after the file close, is the file integrity status invalidated and the file hash re-calculated and written out. @@ -24,7 +24,7 @@ file integrity invalidation. > the actual appraisal. The locking issue isn't with validating the file hash, but with the -setxattr, chmod, chown syscalls. Each of these syscalls takes the +setxattr, chmod, chown syscalls. Each of these syscalls takes the i_rwsem exclusively before IMA (or EVM) is called. In ima_file_free(), the locking would be: @@ -37,7 +37,7 @@ unlock iint->mutex In setxattr, chmod, chown syscalls, IMA (and EVM) are called after the -i_rwsem is already taken. So the locking would be: +i_rwsem is already taken. So the locking would be: lock: i_rwsem lock: iint->mutex @@ -48,7 +48,7 @@ unlock: i_rwsem Perhaps now the problem is clearer? Mimi - + > So make the appraisal itself use a semaphore ("only one appraisal at a time"). > diff --git a/a/content_digest b/N2/content_digest index 61c70fa..cbc38c2 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -31,7 +31,7 @@ "> Umm. You already have an explicit invalidation model, where you\n" "> invalidate after a write has occurred.\n" "\n" - "Invalidating after each write would be horrible performance. Only\n" + "Invalidating after each write would be horrible performance. \302\240Only\n" "after all the changes are made, after the file close, is the file\n" "integrity status invalidated and the file hash re-calculated and\n" "written out.\n" @@ -44,7 +44,7 @@ "> the actual appraisal.\n" "\n" "The locking issue isn't with validating the file hash, but with the\n" - "setxattr, chmod, chown syscalls. Each of these syscalls takes the\n" + "setxattr, chmod, chown syscalls. \302\240Each of these syscalls takes the\n" "i_rwsem exclusively before IMA (or EVM) is called.\n" "\n" "In ima_file_free(), the locking would be:\n" @@ -57,7 +57,7 @@ "\n" "\n" "In setxattr, chmod, chown syscalls, IMA (and EVM) are called after the\n" - "i_rwsem is already taken. So the locking would be:\n" + "i_rwsem is already taken. \302\240So the locking would be:\n" "\n" "lock: i_rwsem\n" "lock: iint->mutex\n" @@ -68,7 +68,7 @@ "Perhaps now the problem is clearer?\n" "\n" "Mimi\n" - " \n" + "\302\240\n" "\n" "> So make the appraisal itself use a semaphore (\"only one appraisal at a time\").\n" "> \n" @@ -112,4 +112,4 @@ "> Linus\n" > -084d46e63263d747862caf820116d0f6f6d5a4c09cfd39b6a3e1f7d9eb00b09c +091e5a113171734b165bf1a4258d6eba19f6c38784f1ee7d9f5ec1d5d1b78a13
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.