From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D6DB7B for ; Wed, 4 Jan 2023 00:08:50 +0000 (UTC) Received: from letrec.thunk.org (host-67-21-23-146.mtnsat.com [67.21.23.146] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 30408IRA015473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Jan 2023 19:08:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1672790909; bh=ALtAqJM3Wx45sHnWFvBnJn73zqSfwhn12OmzEU3j3nE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XvZ/szbp4LO2MJek2jxvKd9zSrTRq4/ah2n0S0d0hsxl/gubg6CZ71ddRUPxTQ79s stC5q+/e7FYCiBf91Uq3FtlQrIlebABfKK+fNVpCl+7lCXavKmQz4UmAc4IrrqET0g KOiGoo8JUk2H5CLaFHAe4Oaz+B8hqYQQCwslED34tYPI6R6Rsegogx268XoK23ii4b gp0kG6HtJRqFnGySACT+wiZ3yEv1UTe+oGqSEgbF5n4I/O4P/b55c9bDhtAeurCgTf Jih/kW3x3mdCpjmWHZm1KTNC8FqjAiMPG1qBXfBJfpfVC3nxrWvSHIZ5/nXq6kJ1wa Js7LLSz3GkZcw== Received: by letrec.thunk.org (Postfix, from userid 15806) id C4C478C0C2E; Tue, 3 Jan 2023 19:08:05 -0500 (EST) Date: Tue, 3 Jan 2023 19:08:05 -0500 From: "Theodore Ts'o" To: Aleksandr Nogikh Cc: syzbot , adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com, syzkaller-bugs@googlegroups.com, trix@redhat.com Subject: Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (2) Message-ID: References: <000000000000e6c7b005f0e90bf1@google.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jan 03, 2023 at 12:22:53PM +0100, Aleksandr Nogikh wrote: > Hi Ted, > > Syzkaller already tries to avoid such situations, but in this > particular case, it has corrupted the mount options[1] and did not > recognize the problem. Though, as I understand, this string was > nevertheless valid to the kernel. Otherwise it would have aborted the > mount early (?). > > [1] grpjquota=Jnoinit_itable(errors=remount-ro,minixdf,jqfmt=vfsv0,usrjquota=." Yes, it's considered valid with the name of the journaled group quota file being "Jnoinit_itable(errors=remount-ro". Which is very odd, but in theory, if that file existed, quotaon would have tried to find that file and used it as the group quota. (Old-style quota files, which we still support because (a) there might be RHEL users using system setups that haven't been updated since the RHEL3/RHEL4 days and (b) there are still stackoverflow answers and other FAQ posts on the web telling people how to enable quota using these ancient schemes, are passed into kernel, but aren't actually used by the kernel; instead the userspace quota tools parse either /etc/mtab or /proc/mounts to find the relevant mount option and then try to use the named file as the user or group quota file.) > I've sent a PR that should make the syzkaller logic more robust to > such broken options strings: > https://github.com/google/syzkaller/pull/3604 Thanks for fixing this so promptly! - Ted