From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966107AbdEOPXA (ORCPT ); Mon, 15 May 2017 11:23:00 -0400 Received: from b.ns.miles-group.at ([95.130.255.144]:44724 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S966004AbdEOPW6 (ORCPT ); Mon, 15 May 2017 11:22:58 -0400 Subject: Re: [PATCH] ubifs: Fix inode leak in xattr code To: dedekind1@gmail.com, linux-mtd@lists.infradead.org References: <1494858005-18439-1-git-send-email-richard@nod.at> <1494860034.18055.17.camel@gmail.com> Cc: linux-kernel@vger.kernel.org, adrian.hunter@intel.com, stable@vger.kernel.org From: Richard Weinberger Message-ID: Date: Mon, 15 May 2017 17:22:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1494860034.18055.17.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Artem, Am 15.05.2017 um 16:53 schrieb Artem Bityutskiy: > On Mon, 2017-05-15 at 16:20 +0200, Richard Weinberger wrote: >> To solve this problem, set i_nlink for all xattr inodes to 0, such >> that >> the iput() in the UBIFS xattr code makes the temporary inode vanish >> immediately. > > What if there is iget right after iput? With this patch, will we need > to go all the way to the slow media instead of just getting having the > inode from the inode cache? Hmm, why would we go down to the slow media? Since the xattr was just looked up there is a high chance that the TNC will still contain the node. A new inode needs to be allocated, though. Alternatively we could add a iget_locked/drop_nlink/iput sequence to ubifs_tnc_remove_ino(). But that will make unlink() much slower for files that contain xattrs. Thanks, //richard