Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp74076pxh; Thu, 7 Apr 2022 14:23:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxf1EpM2J3wt8yw3BYMKhDjpJq85b8uZgDfhxTXQH6b13+dJ8yvp4XpBTIkZOtGjz9Aaq7E X-Received: by 2002:a17:903:20d:b0:154:8227:a389 with SMTP id r13-20020a170903020d00b001548227a389mr16183821plh.142.1649366618491; Thu, 07 Apr 2022 14:23:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649366618; cv=none; d=google.com; s=arc-20160816; b=Z/vXeRLApO1kNQknjkjjjwQc/o5a1tYvg7eVQiakmdbkzoVCoYE3JXV0Lkw1o1AOUH UIqngPW1DbeM72vbn7C3xZ8xRjAiJVw6a5KDut1WaopVznYaB2dOe45MTghcRzysESWv VyR73p8cFxMdYBcBzHUNl60tgT4oRKoeyA+h1dMrDqpij+5YAc9AN5L+wQFTvUNBU2Tg 2SED3eVTE1wJnV6ThJS2hf02Ohp9P0rq2RLUP0rXZQbYV13s/lKieidtUVsyq0qSfeme SsZ1szKv3UOWyUR2J2anPlrfRrOKCVi+Dy0ioto/AmJ9l39kqVTR3nHC6tK+4H/ASNWs Mnyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=tii6bmJW9q55jraQmqHw5/idP+ltcE2ABPemNM804dw=; b=eokTtJRNfAxjetgC/ouB2VoM3EazifeRdeIcPW4++p24CzeoA4RSMz28+HlYzAk912 haI/8WUZtVY2Okx5esxQyNjQmTp1fji9zazc53cquyvmzI7TAFVsjvHBvBF6rNFoD/+f vYbwChB9O13TqNNiotF6j9d1tsAyQ3NxKGaHJn4qIdQSFsbkncdLvRS420nlORm8M/HP YUQAF7xZVFHXMKOvMBrw4HUmlrSguNuIpzaTbUI2CCeNvx//rnxuXxYSN2R/OGCFK1il Tp1Nl7hgjHMNuRZUBtrOV4q3QcetNvUsSXrcVmQVuBS5MpTBiS2NcRfQ4W7VTk5PbJQM fpXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=d8NY3NEz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d21-20020aa78e55000000b004fa842a4794si18346059pfr.214.2022.04.07.14.23.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 14:23:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=d8NY3NEz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 89DDF48C244; Thu, 7 Apr 2022 13:16:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237265AbiDGJKJ (ORCPT + 99 others); Thu, 7 Apr 2022 05:10:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236975AbiDGJKG (ORCPT ); Thu, 7 Apr 2022 05:10:06 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 34EAD12C9C1 for ; Thu, 7 Apr 2022 02:08:07 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id w18so5576441edi.13 for ; Thu, 07 Apr 2022 02:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=tii6bmJW9q55jraQmqHw5/idP+ltcE2ABPemNM804dw=; b=d8NY3NEzkBkOOnx/540Vv7+vhzPjQIzJR7MP2cGJi36CjQNjQxQZe9D0NcJm3aLrUU 7wHgNikyxzQlxUvrhu/bEjik7VXhE7Dod+c64jjBDTCbwdHcxgmEXtdXh07U3cEZ/1V7 SmGZfZQBtkjZSr1TrudQYHmWhY7b5sJUOH4GY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=tii6bmJW9q55jraQmqHw5/idP+ltcE2ABPemNM804dw=; b=qpeRgXf5lEu+3/wlSM9QFDGwK7kgCUQs2SpSjhGdxMpkzNS3OOPMBtOps4xd4h3gy1 LBvThndT5FDZH3qOAQB28oHL771hskVcw9SeeQ3CWBuBVSczN4s4GA8ocqhwX9ufZj5Z W9lDnIWNZHD9ibHMGQbxsCQFAqzIFqswzxobuLB1aI6GkkAhOGtY0lphJaChWDoB2brS /w1Ol2cT5464NJeW8Msf6YNQSA8Ci+eV2djUVcaGpWZXb+LK8E3gbSiJdNdYeJUjp146 JAvC1AARJvO9+FEEpwEIpkmyDys7ZQjm4hDdJt04aK6lEqk5lGHivd5bzViEn44a4btb 19bQ== X-Gm-Message-State: AOAM530oIQrDos1vDiWU2LVCpk46Hu+fw1LdZ17KKGZpnjAaOfzwuJCo R9yuDz4dSdtf6IUlyRmZlPLsnQ== X-Received: by 2002:a05:6402:34cf:b0:419:75b1:99ad with SMTP id w15-20020a05640234cf00b0041975b199admr13137536edc.228.1649322485763; Thu, 07 Apr 2022 02:08:05 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id ds5-20020a170907724500b006df8f39dadesm7470308ejc.218.2022.04.07.02.08.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 02:08:05 -0700 (PDT) Date: Thu, 7 Apr 2022 11:08:03 +0200 From: Daniel Vetter To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , Daniel Vetter , Alex Deucher , Geert Uytterhoeven , Guenter Roeck , Helge Deller , Sam Ravnborg , Xiyu Yang , Zhen Lei , Zheyu Ma , linux-fbdev@vger.kernel.org Subject: Re: [RESEND RFC PATCH 3/5] fbdev: Restart conflicting fb removal loop when unregistering devices Message-ID: Mail-Followup-To: Javier Martinez Canillas , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , Alex Deucher , Geert Uytterhoeven , Guenter Roeck , Helge Deller , Sam Ravnborg , Xiyu Yang , Zhen Lei , Zheyu Ma , linux-fbdev@vger.kernel.org References: <20220406213919.600294-1-javierm@redhat.com> <20220406213919.600294-4-javierm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220406213919.600294-4-javierm@redhat.com> X-Operating-System: Linux phenom 5.10.0-8-amd64 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 06, 2022 at 11:39:17PM +0200, Javier Martinez Canillas wrote: > Drivers that want to remove registered conflicting framebuffers prior to > register their own framebuffer, calls remove_conflicting_framebuffers(). > > This function takes the registration_lock mutex, to prevent a races when > drivers register framebuffer devices. But if a conflicting framebuffer > device is found, the underlaying platform device is unregistered and this > will lead to the platform driver .remove callback to be called, which in > turn will call to the unregister_framebuffer() that takes the same lock. > > To prevent this, a struct fb_info.forced_out field was used as indication > to unregister_framebuffer() whether the mutex has to be grabbed or not. > > A cleaner solution is to drop the lock before platform_device_unregister() > so unregister_framebuffer() can take it when called from the fbdev driver, > and just grab the lock again after the device has been registered and do > a removal loop restart. > > Since the framebuffer devices will already be removed, the loop would just > finish when no more conflicting framebuffers are found. > > Suggested-by: Daniel Vetter > Signed-off-by: Javier Martinez Canillas It's always entertaining with these things since they can go boom in funny ways, but need to a least try :-) Recursive locks are just a bit too evil. Reviewed-by: Daniel Vetter > --- > > drivers/video/fbdev/core/fbmem.c | 21 ++++++++++++++------- > include/linux/fb.h | 1 - > 2 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c > index b585339509b0..c1bfb8df9cba 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1555,6 +1555,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a, > { > int i; > > +restart_removal: > /* check all firmware fbs and kick off if the base addr overlaps */ > for_each_registered_fb(i) { > struct apertures_struct *gen_aper; > @@ -1582,8 +1583,18 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a, > * fix would add code to remove the device from the system. > */ > if (dev_is_platform(device)) { > - registered_fb[i]->forced_out = true; > + /* > + * Drop the lock since the driver will call to the > + * unregister_framebuffer() function that takes it. > + */ > + mutex_unlock(®istration_lock); > platform_device_unregister(to_platform_device(device)); > + mutex_lock(®istration_lock); > + /* > + * Restart the removal now that the platform device > + * has been unregistered and its associated fb gone. > + */ > + goto restart_removal; > } else { > pr_warn("fb%d: cannot remove device\n", i); > do_unregister_framebuffer(registered_fb[i]); > @@ -1917,13 +1928,9 @@ EXPORT_SYMBOL(register_framebuffer); > void > unregister_framebuffer(struct fb_info *fb_info) > { > - bool forced_out = fb_info->forced_out; > - > - if (!forced_out) > - mutex_lock(®istration_lock); > + mutex_lock(®istration_lock); > do_unregister_framebuffer(fb_info); > - if (!forced_out) > - mutex_unlock(®istration_lock); > + mutex_unlock(®istration_lock); > } > EXPORT_SYMBOL(unregister_framebuffer); > > diff --git a/include/linux/fb.h b/include/linux/fb.h > index 39baa9a70779..f1e0cd751b06 100644 > --- a/include/linux/fb.h > +++ b/include/linux/fb.h > @@ -503,7 +503,6 @@ struct fb_info { > } *apertures; > > bool skip_vt_switch; /* no VT switch on suspend/resume required */ > - bool forced_out; /* set when being removed by another driver */ > }; > > static inline struct apertures_struct *alloc_apertures(unsigned int max_num) { > -- > 2.35.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch