From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38807C48BE0 for ; Fri, 11 Jun 2021 07:24:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 21CB9613B4 for ; Fri, 11 Jun 2021 07:24:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229540AbhFKH0e (ORCPT ); Fri, 11 Jun 2021 03:26:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:42736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230179AbhFKH0c (ORCPT ); Fri, 11 Jun 2021 03:26:32 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 10AC2610F8; Fri, 11 Jun 2021 07:24:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623396274; bh=eKKhPnUkL4pgYuDAKY7Rx51nKIGr0JtWZHxxxfchKKA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=diO1/dqMKjm0S0mCvngI8WWtm2PEe4ws1RRn5OxyP5vnL7OBFXwq/uIhFaZqj55VN BTZ1rOzgvK4XvTNr1xXuOYqxMWRYkGw+t4sDlISksRYITYGk3g8N/tIt5QErYRDPFV moq2bT05CxN26MQJlvwtTNDSlvD2A6NQ2tJBCPxA= Date: Fri, 11 Jun 2021 09:24:32 +0200 From: Greg KH To: Amir Goldstein Cc: Matthew Bobrowski , Jan Kara , linux-fsdevel Subject: Re: [PATCH] fanotify: fix copy_event_to_user() fid error clean up Message-ID: References: <1ef8ae9100101eb1a91763c516c2e9a3a3b112bd.1623376346.git.repnop@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Jun 11, 2021 at 10:04:06AM +0300, Amir Goldstein wrote: > On Fri, Jun 11, 2021 at 6:32 AM Matthew Bobrowski wrote: > > > > Ensure that clean up is performed on the allocated file descriptor and > > struct file object in the event that an error is encountered while copying > > fid info objects. Currently, we return directly to the caller when an error > > is experienced in the fid info copying helper, which isn't ideal given that > > the listener process could be left with a dangling file descriptor in their > > fdtable. > > > > Fixes: 44d705b0370b1 ("fanotify: report name info for FAN_DIR_MODIFY event") > > Fixes: 5e469c830fdb5 ("fanotify: copy event fid info to user") > > Link: https://lore.kernel.org/linux-fsdevel/YMKv1U7tNPK955ho@google.com/T/#m15361cd6399dad4396aad650de25dbf6b312288e > > > > This newline should not be here. > > > Signed-off-by: Matthew Bobrowski > > --- > > > > Hey Amir/Jan, > > > > I wasn't 100% sure what specific commit hash I should be referencing in the > > fix tags, so please let me know if that needs to be changed. > > Trick question. > There are two LTS kernels where those fixes are relevant 5.4.y and 5.10.y > (Patch would be picked up for latest stable anyway) > The first Fixes: suggests that the patch should be applied to 5.10+ > and the second Fixes: suggests that the patch should be applied to 5.4+ > > In theory, you could have split this to two patches, one auto applied to 5.4+ > and the other auto applied to +5.10. > > In practice, this patch would not auto apply to 5.4.y cleanly even if you split > it and also, it's arguably not that critical to worth the effort, so I would > keep the first Fixes: tag and drop the second to avoid the noise of the > stable bots trying to apply the patch. > > If you want to do a service to the 5.4.y downstream community, > you can send a backport patch directly to stable list *after* this patch > is applied to master. > > > > > Should we also be CC'ing so this gets backported? > > > > Yes and no. > Actually CC-ing the stable list is not needed, so don't do it. > Cc: tag in the commit message is somewhat redundant to Fixes: tag > these days, but it doesn't hurt to be explicit about intentions. > Specifying: > Cc: # v5.10+ > > Could help as a hint in case the Fixes: tags is for an old commit, but > you know that the patch would not apply before 5.10 and you think it > is not worth the trouble (as in this case). > > But if you do specify stable kernel version hint, try not to get it wrong > like I did :-/ > https://lore.kernel.org/linux-fsdevel/20210608122829.GI5562@quack2.suse.cz/ > > CC-ing Greg in case my understanding of the stable kernel patch > candidate analysis process is wrong. Nope, that's right, and splitting this up would have been great, but we can deal with it. thanks, greg k-h