From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Weinberger Subject: Re: Intentionally corrupted vfat fs causing BUG Date: Mon, 13 Oct 2014 16:36:10 +0200 Message-ID: <543BE35A.50205@nod.at> References: <20141010205706.GJ27150@sli.dy.fi> <87h9z97aoh.fsf@devron.myhome.or.jp> <8761fo7667.fsf@devron.myhome.or.jp> <543B8BC7.1040501@nod.at> <87y4sk5pul.fsf@devron.myhome.or.jp> <543B8FA7.9000106@nod.at> <87r3yc5oqt.fsf@devron.myhome.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Cc: Sami Liedes , linux-fsdevel , Al Viro To: OGAWA Hirofumi Return-path: Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100AbaJMOgM (ORCPT ); Mon, 13 Oct 2014 10:36:12 -0400 In-Reply-To: <87r3yc5oqt.fsf@devron.myhome.or.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Am 13.10.2014 um 10:59 schrieb OGAWA Hirofumi: >> The question is how long these limits will stay... >> User namespaces uncovered already a pile of issues wrt. to mounting. > > Well, anyway, I don't object like that simple patch. > > My worry is, I feel we need something like online-fsck finally if we > tackled fully to avoid issues (I still didn't analyze about this issue > seriously and fully), and measurable overheads. > > And I myself have interest to online/runtime-fsck (i.e. detect and fix) > though, I don't have interest to make it generic operations, and I would > not have interest to tackle for all FSes... At the end of the day we have to treat every filesystem provided by the user as user input and must not trust it. Thanks, //richard