Message ID | 20230308063628.15233-1-tiwai@suse.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp174395wrd; Tue, 7 Mar 2023 22:49:16 -0800 (PST) X-Google-Smtp-Source: AK7set9BjFfeoXPVpgV2X6a2ip+ezWBk1jGDQwQ/zoHjj6KK/sKzS4UVCPLgWiFcq9VxzhF0TUKp X-Received: by 2002:a17:906:730d:b0:8b1:3193:4874 with SMTP id di13-20020a170906730d00b008b131934874mr21443392ejc.46.1678258156803; Tue, 07 Mar 2023 22:49:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678258156; cv=none; d=google.com; s=arc-20160816; b=K17ubtJLvJY8PUlD4uQ1wT/KvuoqZWhHc4fwBdKxaJNcVpQRDt7CCabHecEMiGRuBp Q0ururLcgJWqzGUS+2bergArnRmJW8yBdVZRoPTZ3BX11y9DkZXhIajTKoqZWF1ZUE04 rB3lucX33uS29KoU0mKiXs2yVWmMHfgUHggqaoU8r+1YLdeoKJHdAYT5ci3MHyP6vKnR 9FFsibeLj7Sm2Nn8S7kLN3d3VUew0n0+0lU6/99eArDjLGet11pnB4sskEQEurr7Msk3 O2T3ZP5agUN3n/kT6UhED+hsE6Fc+yNBcWzFjQXctiZZSof4FZi/iaYWojn1eq7Qm/FV U58w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=3h4YnW3SI7kDxrFZgy/I5e5nc2hFg1fRCOVnjuFOR5s=; b=SWXfGVxItPR+UNGE0ax044sgR6Vd3p2KI3GpFkhlogbTxvj4Zdu3DU5zmfBji4ztEP HbbBd/d+L5zOdNjuoyClPmAF0r1etr3mlgBYvrN+jLbUiqKyTaPPr41Xb/IBlAp+QXTm jzT4fPkq/QZzqw0jNoDSc9zoF1BRkiBMCZIRlfvjQJn2V9JFpwUBviWHNfVSdYhM+Sj3 3crYwmL++lEluB4k5VDh94xCkk6zfiZrY94M8NVr1Nu6ZwflFUIZiXIKeP/StZsmFeQP Pm/O4asJgsxLkPcetcAmaABa725bTRRWH70bJzd5Qokc+cK/6Qqj2m0ne17rMtqb9oaU Rc8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=fPX9DEKv; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gv25-20020a170906f11900b008bd2a964b93si12154439ejb.300.2023.03.07.22.48.53; Tue, 07 Mar 2023 22:49:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=fPX9DEKv; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229901AbjCHGgn (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Wed, 8 Mar 2023 01:36:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229906AbjCHGgj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 8 Mar 2023 01:36:39 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 457B6A028D; Tue, 7 Mar 2023 22:36:36 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A06F41FE35; Wed, 8 Mar 2023 06:36:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1678257395; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=3h4YnW3SI7kDxrFZgy/I5e5nc2hFg1fRCOVnjuFOR5s=; b=fPX9DEKvn90FUOVp/Nv3gfbbh9B0O41ZMRb4O3Fv4ncTlmPR7N6fR52LcDXL5UzEw8FCw+ ZxvkABlDnarvk1eb7sucVSPkIAnd2If61vC8AYCQW6N9GnvFDYfjouDA7zv17THJImep25 AzaiG/xDCfvhVrtefyhH8j+MS3auWJ4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1678257395; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=3h4YnW3SI7kDxrFZgy/I5e5nc2hFg1fRCOVnjuFOR5s=; b=+TNtLndF9vaeJXeXb0MPUjA9YGoTL4KAFoltv1+Za7Mws6lphC72cM7RAphviMU1t6S83B iVC4m3m8XBB+uMCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 754621348D; Wed, 8 Mar 2023 06:36:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id wsflG/MsCGS/WgAAMHmgww (envelope-from <tiwai@suse.de>); Wed, 08 Mar 2023 06:36:35 +0000 From: Takashi Iwai <tiwai@suse.de> To: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Patrik Jakobsson <pjakobsson@suse.de>, Helge Deller <deller@gmx.de>, Miko Larsson <mikoxyzzz@gmail.com> Subject: [PATCH] fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release() Date: Wed, 8 Mar 2023 07:36:28 +0100 Message-Id: <20230308063628.15233-1-tiwai@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759781225260571618?= X-GMAIL-MSGID: =?utf-8?q?1759781225260571618?= |
Series |
fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()
|
|
Commit Message
Takashi Iwai
March 8, 2023, 6:36 a.m. UTC
The recent fix for the deferred I/O by the commit
3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
caused a regression when the same fb device is opened/closed while
it's being used. It resulted in a frozen screen even if something
is redrawn there after the close. The breakage is because the patch
was made under a wrong assumption of a single open; in the current
code, fb_deferred_io_release() cleans up the page mapping of the
pageref list and it calls cancel_delayed_work_sync() unconditionally,
where both are no correct behavior for multiple opens.
This patch adds a refcount for the opens of the device, and applies
the cleanup only when all files get closed.
Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/video/fbdev/core/fb_defio.c | 16 +++++++++++++---
include/linux/fb.h | 1 +
2 files changed, 14 insertions(+), 3 deletions(-)
Comments
On Wed, Mar 8, 2023 at 7:36 AM Takashi Iwai <tiwai@suse.de> wrote: > > The recent fix for the deferred I/O by the commit > 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > caused a regression when the same fb device is opened/closed while > it's being used. It resulted in a frozen screen even if something > is redrawn there after the close. The breakage is because the patch > was made under a wrong assumption of a single open; in the current > code, fb_deferred_io_release() cleans up the page mapping of the > pageref list and it calls cancel_delayed_work_sync() unconditionally, > where both are no correct behavior for multiple opens. > > This patch adds a refcount for the opens of the device, and applies > the cleanup only when all files get closed. > > Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > Cc: <stable@vger.kernel.org> > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/video/fbdev/core/fb_defio.c | 16 +++++++++++++--- > include/linux/fb.h | 1 + > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c > index aa5f059d0222..9dcec9e020b6 100644 > --- a/drivers/video/fbdev/core/fb_defio.c > +++ b/drivers/video/fbdev/core/fb_defio.c > @@ -305,17 +305,19 @@ void fb_deferred_io_open(struct fb_info *info, > struct inode *inode, > struct file *file) > { > + struct fb_deferred_io *fbdefio = info->fbdefio; > + > file->f_mapping->a_ops = &fb_deferred_io_aops; > + fbdefio->opens++; > } > EXPORT_SYMBOL_GPL(fb_deferred_io_open); > > -void fb_deferred_io_release(struct fb_info *info) > +static void fb_deferred_io_release_internal(struct fb_info *info) Maybe a better name would be fb_deferred_io_lastclose() to be more in line with DRM? > { > struct fb_deferred_io *fbdefio = info->fbdefio; > struct page *page; > int i; > > - BUG_ON(!fbdefio); Should the BUG_ON be put back into fb_deferred_io_release()? > cancel_delayed_work_sync(&info->deferred_work); > > /* clear out the mapping that we setup */ > @@ -324,13 +326,21 @@ void fb_deferred_io_release(struct fb_info *info) > page->mapping = NULL; > } > } > + > +void fb_deferred_io_release(struct fb_info *info) > +{ > + struct fb_deferred_io *fbdefio = info->fbdefio; > + > + if (!--fbdefio->opens) > + fb_deferred_io_release_internal(info); I think this can race so we need locking. > +} > EXPORT_SYMBOL_GPL(fb_deferred_io_release); > > void fb_deferred_io_cleanup(struct fb_info *info) > { > struct fb_deferred_io *fbdefio = info->fbdefio; > > - fb_deferred_io_release(info); > + fb_deferred_io_release_internal(info); > > kvfree(info->pagerefs); > mutex_destroy(&fbdefio->lock); > diff --git a/include/linux/fb.h b/include/linux/fb.h > index d8d20514ea05..29674a29d1c4 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -212,6 +212,7 @@ struct fb_deferred_io { > /* delay between mkwrite and deferred handler */ > unsigned long delay; > bool sort_pagereflist; /* sort pagelist by offset */ > + int opens; /* number of opened files */ I would prefer the name num_opens (or open_count as in DRM) instead of opens since it can be interpreted as a verb. Also, don't we need it to be atomic_t? > struct mutex lock; /* mutex that protects the pageref list */ > struct list_head pagereflist; /* list of pagerefs for touched pages */ > /* callback */ > -- > 2.35.3 >
On Wed, 08 Mar 2023 10:08:24 +0100, Patrik Jakobsson wrote: > > On Wed, Mar 8, 2023 at 7:36 AM Takashi Iwai <tiwai@suse.de> wrote: > > > > The recent fix for the deferred I/O by the commit > > 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > > caused a regression when the same fb device is opened/closed while > > it's being used. It resulted in a frozen screen even if something > > is redrawn there after the close. The breakage is because the patch > > was made under a wrong assumption of a single open; in the current > > code, fb_deferred_io_release() cleans up the page mapping of the > > pageref list and it calls cancel_delayed_work_sync() unconditionally, > > where both are no correct behavior for multiple opens. > > > > This patch adds a refcount for the opens of the device, and applies > > the cleanup only when all files get closed. > > > > Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > --- > > drivers/video/fbdev/core/fb_defio.c | 16 +++++++++++++--- > > include/linux/fb.h | 1 + > > 2 files changed, 14 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c > > index aa5f059d0222..9dcec9e020b6 100644 > > --- a/drivers/video/fbdev/core/fb_defio.c > > +++ b/drivers/video/fbdev/core/fb_defio.c > > @@ -305,17 +305,19 @@ void fb_deferred_io_open(struct fb_info *info, > > struct inode *inode, > > struct file *file) > > { > > + struct fb_deferred_io *fbdefio = info->fbdefio; > > + > > file->f_mapping->a_ops = &fb_deferred_io_aops; > > + fbdefio->opens++; > > } > > EXPORT_SYMBOL_GPL(fb_deferred_io_open); > > > > -void fb_deferred_io_release(struct fb_info *info) > > +static void fb_deferred_io_release_internal(struct fb_info *info) > > Maybe a better name would be fb_deferred_io_lastclose() to be more in > line with DRM? Sounds good. > > { > > struct fb_deferred_io *fbdefio = info->fbdefio; > > struct page *page; > > int i; > > > > - BUG_ON(!fbdefio); > > Should the BUG_ON be put back into fb_deferred_io_release()? It can be, but honestly speaking, such a BUG_ON() is utterly useless. It should be WARN_ON() and return, if the sanity check is inevitably needed. > > cancel_delayed_work_sync(&info->deferred_work); > > > > /* clear out the mapping that we setup */ > > @@ -324,13 +326,21 @@ void fb_deferred_io_release(struct fb_info *info) > > page->mapping = NULL; > > } > > } > > + > > +void fb_deferred_io_release(struct fb_info *info) > > +{ > > + struct fb_deferred_io *fbdefio = info->fbdefio; > > + > > + if (!--fbdefio->opens) > > + fb_deferred_io_release_internal(info); > > I think this can race so we need locking. This one is fine, as it's always called inside the fb lock in the caller side. Maybe worth to comment in the code. > > +} > > EXPORT_SYMBOL_GPL(fb_deferred_io_release); > > > > void fb_deferred_io_cleanup(struct fb_info *info) > > { > > struct fb_deferred_io *fbdefio = info->fbdefio; > > > > - fb_deferred_io_release(info); > > + fb_deferred_io_release_internal(info); > > > > kvfree(info->pagerefs); > > mutex_destroy(&fbdefio->lock); > > diff --git a/include/linux/fb.h b/include/linux/fb.h > > index d8d20514ea05..29674a29d1c4 100644 > > --- a/include/linux/fb.h > > +++ b/include/linux/fb.h > > @@ -212,6 +212,7 @@ struct fb_deferred_io { > > /* delay between mkwrite and deferred handler */ > > unsigned long delay; > > bool sort_pagereflist; /* sort pagelist by offset */ > > + int opens; /* number of opened files */ > > I would prefer the name num_opens (or open_count as in DRM) instead of > opens since it can be interpreted as a verb. I don't mind either way. I'd choose the latter. > Also, don't we need it to be atomic_t? It's always in the fb lock, so that should be fine with the standard int. thanks, Takashi
On Wed, Mar 8, 2023 at 10:14 AM Takashi Iwai <tiwai@suse.de> wrote: > > On Wed, 08 Mar 2023 10:08:24 +0100, > Patrik Jakobsson wrote: > > > > On Wed, Mar 8, 2023 at 7:36 AM Takashi Iwai <tiwai@suse.de> wrote: > > > > > > The recent fix for the deferred I/O by the commit > > > 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > > > caused a regression when the same fb device is opened/closed while > > > it's being used. It resulted in a frozen screen even if something > > > is redrawn there after the close. The breakage is because the patch > > > was made under a wrong assumption of a single open; in the current > > > code, fb_deferred_io_release() cleans up the page mapping of the > > > pageref list and it calls cancel_delayed_work_sync() unconditionally, > > > where both are no correct behavior for multiple opens. > > > > > > This patch adds a refcount for the opens of the device, and applies > > > the cleanup only when all files get closed. > > > > > > Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices") > > > Cc: <stable@vger.kernel.org> > > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > > > --- > > > drivers/video/fbdev/core/fb_defio.c | 16 +++++++++++++--- > > > include/linux/fb.h | 1 + > > > 2 files changed, 14 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c > > > index aa5f059d0222..9dcec9e020b6 100644 > > > --- a/drivers/video/fbdev/core/fb_defio.c > > > +++ b/drivers/video/fbdev/core/fb_defio.c > > > @@ -305,17 +305,19 @@ void fb_deferred_io_open(struct fb_info *info, > > > struct inode *inode, > > > struct file *file) > > > { > > > + struct fb_deferred_io *fbdefio = info->fbdefio; > > > + > > > file->f_mapping->a_ops = &fb_deferred_io_aops; > > > + fbdefio->opens++; > > > } > > > EXPORT_SYMBOL_GPL(fb_deferred_io_open); > > > > > > -void fb_deferred_io_release(struct fb_info *info) > > > +static void fb_deferred_io_release_internal(struct fb_info *info) > > > > Maybe a better name would be fb_deferred_io_lastclose() to be more in > > line with DRM? > > Sounds good. > > > > { > > > struct fb_deferred_io *fbdefio = info->fbdefio; > > > struct page *page; > > > int i; > > > > > > - BUG_ON(!fbdefio); > > > > Should the BUG_ON be put back into fb_deferred_io_release()? > > It can be, but honestly speaking, such a BUG_ON() is utterly useless. > It should be WARN_ON() and return, if the sanity check is inevitably > needed. I agree. It's rather pointless since it's already checked in fb_release(). > > > > cancel_delayed_work_sync(&info->deferred_work); > > > > > > /* clear out the mapping that we setup */ > > > @@ -324,13 +326,21 @@ void fb_deferred_io_release(struct fb_info *info) > > > page->mapping = NULL; > > > } > > > } > > > + > > > +void fb_deferred_io_release(struct fb_info *info) > > > +{ > > > + struct fb_deferred_io *fbdefio = info->fbdefio; > > > + > > > + if (!--fbdefio->opens) > > > + fb_deferred_io_release_internal(info); > > > > I think this can race so we need locking. > > This one is fine, as it's always called inside the fb lock in the > caller side. Maybe worth to comment in the code. Ah, yes, fb_release() locks around everything. Then we are fine. A comment would be nice. > > > > +} > > > EXPORT_SYMBOL_GPL(fb_deferred_io_release); > > > > > > void fb_deferred_io_cleanup(struct fb_info *info) > > > { > > > struct fb_deferred_io *fbdefio = info->fbdefio; > > > > > > - fb_deferred_io_release(info); > > > + fb_deferred_io_release_internal(info); > > > > > > kvfree(info->pagerefs); > > > mutex_destroy(&fbdefio->lock); > > > diff --git a/include/linux/fb.h b/include/linux/fb.h > > > index d8d20514ea05..29674a29d1c4 100644 > > > --- a/include/linux/fb.h > > > +++ b/include/linux/fb.h > > > @@ -212,6 +212,7 @@ struct fb_deferred_io { > > > /* delay between mkwrite and deferred handler */ > > > unsigned long delay; > > > bool sort_pagereflist; /* sort pagelist by offset */ > > > + int opens; /* number of opened files */ > > > > I would prefer the name num_opens (or open_count as in DRM) instead of > > opens since it can be interpreted as a verb. > > I don't mind either way. I'd choose the latter. > > > Also, don't we need it to be atomic_t? > > It's always in the fb lock, so that should be fine with the standard > int. Yes > > > thanks, > > Takashi
Hi Takashi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.3-rc1 next-20230308]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Takashi-Iwai/fbdev-Fix-incorrect-page-mapping-clearance-at-fb_deferred_io_release/20230308-143749
patch link: https://lore.kernel.org/r/20230308063628.15233-1-tiwai%40suse.de
patch subject: [PATCH] fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20230308/202303081843.yyoyPjaN-lkp@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
# https://github.com/intel-lab-lkp/linux/commit/fe94468e5ddd91231f1624559f861fb8110163c3
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Takashi-Iwai/fbdev-Fix-incorrect-page-mapping-clearance-at-fb_deferred_io_release/20230308-143749
git checkout fe94468e5ddd91231f1624559f861fb8110163c3
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/video/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303081843.yyoyPjaN-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/video/fbdev/core/fb_defio.c: In function 'fb_deferred_io_release_internal':
>> drivers/video/fbdev/core/fb_defio.c:317:32: warning: unused variable 'fbdefio' [-Wunused-variable]
317 | struct fb_deferred_io *fbdefio = info->fbdefio;
| ^~~~~~~
vim +/fbdefio +317 drivers/video/fbdev/core/fb_defio.c
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 314
fe94468e5ddd912 drivers/video/fbdev/core/fb_defio.c Takashi Iwai 2023-03-08 315 static void fb_deferred_io_release_internal(struct fb_info *info)
60b59beafba875a drivers/video/fb_defio.c Jaya Kumar 2007-05-08 316 {
60b59beafba875a drivers/video/fb_defio.c Jaya Kumar 2007-05-08 @317 struct fb_deferred_io *fbdefio = info->fbdefio;
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 318 struct page *page;
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 319 int i;
60b59beafba875a drivers/video/fb_defio.c Jaya Kumar 2007-05-08 320
181b74ef794e198 drivers/video/fb_defio.c Tejun Heo 2011-06-15 321 cancel_delayed_work_sync(&info->deferred_work);
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 322
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 323 /* clear out the mapping that we setup */
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 324 for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 325 page = fb_deferred_io_page(info, i);
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 326 page->mapping = NULL;
0b78f8bcf4951af drivers/video/fbdev/core/fb_defio.c Matthew Wilcox 2021-06-01 327 }
3efc61d95259956 drivers/video/fbdev/core/fb_defio.c Takashi Iwai 2023-01-29 328 }
fe94468e5ddd912 drivers/video/fbdev/core/fb_defio.c Takashi Iwai 2023-03-08 329
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c index aa5f059d0222..9dcec9e020b6 100644 --- a/drivers/video/fbdev/core/fb_defio.c +++ b/drivers/video/fbdev/core/fb_defio.c @@ -305,17 +305,19 @@ void fb_deferred_io_open(struct fb_info *info, struct inode *inode, struct file *file) { + struct fb_deferred_io *fbdefio = info->fbdefio; + file->f_mapping->a_ops = &fb_deferred_io_aops; + fbdefio->opens++; } EXPORT_SYMBOL_GPL(fb_deferred_io_open); -void fb_deferred_io_release(struct fb_info *info) +static void fb_deferred_io_release_internal(struct fb_info *info) { struct fb_deferred_io *fbdefio = info->fbdefio; struct page *page; int i; - BUG_ON(!fbdefio); cancel_delayed_work_sync(&info->deferred_work); /* clear out the mapping that we setup */ @@ -324,13 +326,21 @@ void fb_deferred_io_release(struct fb_info *info) page->mapping = NULL; } } + +void fb_deferred_io_release(struct fb_info *info) +{ + struct fb_deferred_io *fbdefio = info->fbdefio; + + if (!--fbdefio->opens) + fb_deferred_io_release_internal(info); +} EXPORT_SYMBOL_GPL(fb_deferred_io_release); void fb_deferred_io_cleanup(struct fb_info *info) { struct fb_deferred_io *fbdefio = info->fbdefio; - fb_deferred_io_release(info); + fb_deferred_io_release_internal(info); kvfree(info->pagerefs); mutex_destroy(&fbdefio->lock); diff --git a/include/linux/fb.h b/include/linux/fb.h index d8d20514ea05..29674a29d1c4 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -212,6 +212,7 @@ struct fb_deferred_io { /* delay between mkwrite and deferred handler */ unsigned long delay; bool sort_pagereflist; /* sort pagelist by offset */ + int opens; /* number of opened files */ struct mutex lock; /* mutex that protects the pageref list */ struct list_head pagereflist; /* list of pagerefs for touched pages */ /* callback */