From patchwork Fri May 4 16:14:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tetsuo Handa X-Patchwork-Id: 10381011 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 15A076038F for ; Fri, 4 May 2018 16:14:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F2907285FD for ; Fri, 4 May 2018 16:14:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E6BB0294E4; Fri, 4 May 2018 16:14:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BFD8285FD for ; Fri, 4 May 2018 16:14:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751326AbeEDQOw (ORCPT ); Fri, 4 May 2018 12:14:52 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:31841 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751196AbeEDQOw (ORCPT ); Fri, 4 May 2018 12:14:52 -0400 Received: from fsav405.sakura.ne.jp (fsav405.sakura.ne.jp [133.242.250.104]) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w44GEe1M005848; Sat, 5 May 2018 01:14:41 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav405.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav405.sakura.ne.jp); Sat, 05 May 2018 01:14:40 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav405.sakura.ne.jp) Received: from AQUA (softbank126099184120.bbtec.net [126.99.184.120]) (authenticated bits=0) by www262.sakura.ne.jp (8.14.5/8.14.5) with ESMTP id w44GEeMd005845; Sat, 5 May 2018 01:14:40 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) To: axboe@kernel.dk, jack@suse.cz, gmazyland@gmail.com Cc: linux-block@vger.kernel.org Subject: [PATCH v2] loop: remember whether sysfs_create_group() succeeded From: Tetsuo Handa References: <3afa1009-c55e-08e2-32b9-49fde1c587c8@kernel.dk> <201805042327.CBF64097.OOVQFtFJFLSHOM@I-love.SAKURA.ne.jp> <6bf461ba-4bd0-6709-1605-b0fccd0f105d@kernel.dk> <201805042340.AIB51569.HOFQOJLFtVFSMO@I-love.SAKURA.ne.jp> In-Reply-To: Message-Id: <201805050114.GDF05771.JVtFOQMLOSFFHO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sat, 5 May 2018 01:14:41 +0900 Mime-Version: 1.0 Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Jens Axboe wrote: > > The loop module ignores sysfs_create_group() failure and pretends that > > LOOP_SET_FD request succeeded. I guess that the author of commit > > ee86273062cbb310 ("loop: add some basic read-only sysfs attributes") > > assumed that it is not a fatal error enough to abort LOOP_SET_FD request. > > > > Do we want to abort LOOP_SET_FD request if sysfs_create_group() failed? > > Probably safer to retain that behavior. OK. > > >> If that's not easily done, then my next suggestion would be to > >> use a loop flag for it, LO_FLAGS_SYSFS_SETUP or something like that. > > > > Yes, that would be possible. > > Let's make that change. Since LO_FLAGS_* are defined in include/uapi/linux/loop.h as userspace visible flags, I feel that using "struct loop_device"->lo_flags for recording whether sysfs entry exists might be strange... Anyway, updated patch is shown below. >From c9897b6387b13b533c32dcc624e12a93f23224d0 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sat, 5 May 2018 00:52:59 +0900 Subject: [PATCH v2] loop: remember whether sysfs_create_group() succeeded syzbot is hitting WARN() triggered by memory allocation fault injection [1] because loop module is calling sysfs_remove_group() when sysfs_create_group() failed. Fix this by remembering whether sysfs_create_group() succeeded. To remember it, userspace visible API flag LO_FLAGS_SYSFS_ENTRY is introduced. This flag indicates that sysfs entries are available, and should be always set if CONFIG_SYSFS=y because sysfs entries will be created unless fault injection prevents it. [1] https://syzkaller.appspot.com/bug?id=3f86c0edf75c86d2633aeb9dd69eccc70bc7e90b Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Jens Axboe --- drivers/block/loop.c | 6 ++++-- include/uapi/linux/loop.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 5d4e316..499eafd 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -951,7 +951,8 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode, loop_update_dio(lo); set_capacity(lo->lo_disk, size); bd_set_size(bdev, size << 9); - loop_sysfs_init(lo); + if (IS_ENABLED(CONFIG_SYSFS) && loop_sysfs_init(lo) == 0) + lo->lo_flags |= LO_FLAGS_SYSFS_ENTRY; /* let user-space know about the new size */ kobject_uevent(&disk_to_dev(bdev->bd_disk)->kobj, KOBJ_CHANGE); @@ -1070,7 +1071,8 @@ static int loop_clr_fd(struct loop_device *lo) invalidate_bdev(bdev); } set_capacity(lo->lo_disk, 0); - loop_sysfs_exit(lo); + if (lo->lo_flags & LO_FLAGS_SYSFS_ENTRY) + loop_sysfs_exit(lo); if (bdev) { bd_set_size(bdev, 0); /* let user-space know about this change */ diff --git a/include/uapi/linux/loop.h b/include/uapi/linux/loop.h index 080a8df..5de1eaa6 100644 --- a/include/uapi/linux/loop.h +++ b/include/uapi/linux/loop.h @@ -23,6 +23,7 @@ enum { LO_FLAGS_AUTOCLEAR = 4, LO_FLAGS_PARTSCAN = 8, LO_FLAGS_DIRECT_IO = 16, + LO_FLAGS_SYSFS_ENTRY = 32, }; #include /* for __kernel_old_dev_t */