On Thu, 2012-01-05 at 12:19 -0500, Mimi Zohar wrote: > On Thu, 2012-01-05 at 08:54 -0800, Greg KH wrote: > > On Wed, Jan 04, 2012 at 11:17:12PM -0500, Mimi Zohar wrote: > > > On Wed, 2012-01-04 at 18:06 -0800, Greg KH wrote: > > > > On Wed, Jan 04, 2012 at 04:46:38PM -0800, Andrew Morton wrote: > > > > > On Wed, 04 Jan 2012 19:33:49 -0500 > > > > > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > On Wed, 2012-01-04 at 15:28 -0800, Andrew Morton wrote: > > > > > > > On Thu, 22 Dec 2011 08:26:30 -0500 > > > > > > > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > On Thu, 2011-12-22 at 12:54 +0200, Dmitry Kasatkin wrote: > > > > > > > > > When a file is truncated with truncate()/ftruncate() and then closed, > > > > > > > > > iversion is not updated. This patch uses ATTR_SIZE flag as an indication > > > > > > > > > to increment iversion. > > > > > > > > > > > > > > > > > > Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@xxxxxxxxx> > > > > > > > > > > > > > > > > Acked-by: Mimi Zohar <zohar@xxxxxxxxxx> > > > > > > > > (Stable should be cc'ed on this patch.) > > > > > > > > > > > > > > why? > > > > > > > > > > > > Why backported? > > > > > > > > > > Yes. If you want to submit the patch to the -stable maintainer then > > > > > you should explain to him why the fix is important enough to warrant > > > > > doing that. That involves explaining the user-visible effects of > > > > > the bug. > > > > > > > > > > > The IMA measurement list could be incomplete. > > > > > > > > > > In more detail than this. Maybe he knows what the above sentence > > > > > means, but I sure don't. > > > > > > > > Nope, I don't either :) > > > > > > On fput(), i_version is used to detect and flag files that have changed > > > and need to be re-measured in the IMA measurement policy. When a file > > > is truncated with truncate()/ftruncate() and then closed, i_version is > > > not updated. As a result, although the file has changed, it will not be > > > re-measured and added to the IMA measurement list on subsequent access. > > > > And what am I supposed to do with this? > > > > Please, go read Documentation/stable_kernel_rules.txt for how to > > properly submit patches to the stable kernel tree. The information here > > needs to be in the patch changelog itself, not in some random email > > thread that will get lost instantly into my email-archive-from-hell > > after I am done reading this. > > > > greg k-h > > Yes, I've read Documentation/stable_kernel_rules.txt and think this > patch meets the criteria for being backported. > > As far as I'm aware, this patch hasn't been upstreamed yet and is > waiting for someone, besides myself, to Ack it. Once Acked, either > Dmitry or I can send a pull request with an updated patch description. > Should this patch go in via the security tree? If it hasn't been upstreamed yet, just make sure you put cc: stable@xxxxxxxxxx In the signoffs of the patch you're sending upstream and the backport will occur automatically when the patch is finally upstreamed. James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
