From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9A859C433EF for ; Mon, 29 Nov 2021 11:39:57 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4J2k0q4vZbz3cQg for ; Mon, 29 Nov 2021 22:39:55 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=j7IepB0c; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::22f; helo=mail-lj1-x22f.google.com; envelope-from=digetx@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=j7IepB0c; dkim-atps=neutral Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4J2jv92gZMz305t for ; Mon, 29 Nov 2021 22:34:59 +1100 (AEDT) Received: by mail-lj1-x22f.google.com with SMTP id k2so33856261lji.4 for ; Mon, 29 Nov 2021 03:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=euaa0MK3qpl38vu/xm/JZntaVOCHcXyS5pdHcr9Cv9Y=; b=j7IepB0c7QsF+gZGn8sLWlXDCQr83Yhq9Uwq9fJmgvQdhWWCer0J3Db/gwAG0Blu3V KLIiDLWANtPW2sX+O/m2jQqBDLC+4NfkDAxYnlnBfxi7qlePYrZZysw0Kj4NFPMagEe7 5Z58UnljUl1PUrtNNqQtNaR8rjEOAOjAptz9aZ81TzHnOGVzQL+Ka518l0o45nrM05c1 wTSb3kazkFWdVLhzdtamDwO56fb5XsgOF41m+pkkrOCbpYLS/NmBUtznRV2wcvObV+eX /QUCocD7Th3AP/6bIoc90HuBDrH/5Le5nNAAFps88ziv0187Td+CIqcDZxoQmDkSEFJt ILjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=euaa0MK3qpl38vu/xm/JZntaVOCHcXyS5pdHcr9Cv9Y=; b=egsOthLqzKxmY2vaYuxv3XAT5JIuqI4gwhqRKr6DBZIOmq6QaY8C1PZDMPZudWn+8R 1WkQjKhRcly/nLHl+hvPqGN3hAQUEbcmXacwLPbKNvK9axy/45yNorqdUrigaJsDEH/P xHk5PSGIUDzMdcyVLkSUbh6k2nIOJhRnyZv/kVfypKo0GSE+TfS8Ol+UnHOtVYKoYSFt Wb+HJzUoxOn5/u4nLrBm4/sLSn/+RdPrYeJ+DHPFgTznNsxJjdcQyaxrkQ9Hw85Ywia1 OtfmEoLDmjoFba5yKlT4nwWS1JuF4e8NnKTaB67sikrRjhcUWT4QlTHkpy7hkrt2afUn hI/w== X-Gm-Message-State: AOAM530mXrPNk4yS4wcpMQB9fcbp8w9KZXBnbNoBtDZ0tAcdxbAc/jpr ItFywTVHCBpci7N6xqlQtEk= X-Google-Smtp-Source: ABdhPJzVpycz41Q2saZagDnrHTPX3H5Cn8S9UMBEs5Q4UAjlx4ArmiP2PAHXWXd2FxMxn0TZfV9KEQ== X-Received: by 2002:a2e:814b:: with SMTP id t11mr47973901ljg.171.1638185691187; Mon, 29 Nov 2021 03:34:51 -0800 (PST) Received: from [192.168.2.145] (94-29-46-111.dynamic.spd-mgts.ru. [94.29.46.111]) by smtp.googlemail.com with ESMTPSA id n2sm131579ljq.30.2021.11.29.03.34.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Nov 2021 03:34:50 -0800 (PST) Subject: Re: [PATCH v4 05/25] reboot: Warn if restart handler has duplicated priority To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= References: <20211126180101.27818-1-digetx@gmail.com> <20211126180101.27818-6-digetx@gmail.com> <033ddf2a-6223-1a82-ec64-30f17c891f67@gmail.com> From: Dmitry Osipenko Message-ID: <091321ea-4919-0579-88a8-23d05871575d@gmail.com> Date: Mon, 29 Nov 2021 14:34:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 29 Nov 2021 22:39:17 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Rich Felker , linux-ia64@vger.kernel.org, Santosh Shilimkar , "Rafael J. Wysocki" , Boris Ostrovsky , Linus Walleij , Dave Hansen , Liam Girdwood , "James E.J. Bottomley" , Thierry Reding , Paul Mackerras , Pavel Machek , "H. Peter Anvin" , linux-riscv@lists.infradead.org, Vincent Chen , Will Deacon , Greg Ungerer , Stefano Stabellini , alankao@andestech.com, Yoshinori Sato , Krzysztof Kozlowski , linux-sh@vger.kernel.org, Helge Deller , x86@kernel.org, Russell King , linux-csky@vger.kernel.org, Jonathan Hunter , linux-acpi@vger.kernel.org, Ingo Molnar , Geert Uytterhoeven , Catalin Marinas , xen-devel@lists.xenproject.org, linux-mips@vger.kernel.org, Guenter Roeck , Len Brown , Albert Ou , Lee Jones , linux-m68k@lists.linux-m68k.org, Mark Brown , Borislav Petkov , Greentime Hu , Paul Walmsley , linux-tegra@vger.kernel.org, Thomas Gleixner , Andy Shevchenko , linux-arm-kernel@lists.infradead.org, Juergen Gross , Thomas Bogendoerfer , Daniel Lezcano , linux-parisc@vger.kernel.org, linux-pm@vger.kernel.org, Sebastian Reichel , linux-kernel@vger.kernel.org, "K . C . Kuen-Chern Lin" , Palmer Dabbelt , Philipp Zabel , Guo Ren , Andrew Morton , linuxppc-dev@lists.ozlabs.org, Joshua Thompson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 29.11.2021 03:26, Michał Mirosław пишет: > On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote: >> 28.11.2021 03:28, Michał Mirosław пишет: >>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote: >>>> Add sanity check which ensures that there are no two restart handlers >>>> registered with the same priority. Normally it's a direct sign of a >>>> problem if two handlers use the same priority. >>> >>> The patch doesn't ensure the property that there are no duplicated-priority >>> entries on the chain. >> >> It's not the exact point of this patch. >> >>> I'd rather see a atomic_notifier_chain_register_unique() that returns >>> -EBUSY or something istead of adding an entry with duplicate priority. >>> That way it would need only one list traversal unless you want to >>> register the duplicate anyway (then you would call the older >>> atomic_notifier_chain_register() after reporting the error). >> >> The point of this patch is to warn developers about the problem that >> needs to be fixed. We already have such troubling drivers in mainline. >> >> It's not critical to register different handlers with a duplicated >> priorities, but such cases really need to be corrected. We shouldn't >> break users' machines during transition to the new API, meanwhile >> developers should take action of fixing theirs drivers. >> >>> (Or you could return > 0 when a duplicate is registered in >>> atomic_notifier_chain_register() if the callers are prepared >>> for that. I don't really like this way, though.) >> >> I had a similar thought at some point before and decided that I'm not in >> favor of this approach. It's nicer to have a dedicated function that >> verifies the uniqueness, IMO. > > I don't like the part that it traverses the list second time to check > the uniqueness. But actually you could avoid that if > notifier_chain_register() would always add equal-priority entries in > reverse order: > > static int notifier_chain_register(struct notifier_block **nl, > struct notifier_block *n) > { > while ((*nl) != NULL) { > if (unlikely((*nl) == n)) { > WARN(1, "double register detected"); > return 0; > } > - if (n->priority > (*nl)->priority) > + if (n->priority >= (*nl)->priority) > break; > nl = &((*nl)->next); > } > n->next = *nl; > rcu_assign_pointer(*nl, n); > return 0; > } > > Then the check for uniqueness after adding would be: > > WARN(nb->next && nb->priority == nb->next->priority); We can't just change the registration order because invocation order of the call chain depends on the registration order and some of current users may rely on that order. I'm pretty sure that changing the order will have unfortunate consequences.