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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39544C4345F for ; Fri, 19 Apr 2024 18:06:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD6386B0098; Fri, 19 Apr 2024 14:06:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5FC76B0099; Fri, 19 Apr 2024 14:06:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D8D76B009A; Fri, 19 Apr 2024 14:06:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6B1ED6B0098 for ; Fri, 19 Apr 2024 14:06:50 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2894EA1608 for ; Fri, 19 Apr 2024 18:06:50 +0000 (UTC) X-FDA: 82027062180.18.7148F1A Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf08.hostedemail.com (Postfix) with ESMTP id E51A5160014 for ; Fri, 19 Apr 2024 18:06:47 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713550008; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8QdIYONhHRjSd6kq3Jm3Y+G6H+2jmIzOJKqMnvosVBY=; b=JQ+rZq9dg93ygwAzL1RCDkRLJ/M81Nt7yaBr+Eer5+em5ommyu2VX6BSrJXeOr+SbpYI/j Wu1HK10KKayiPicXiP0/0RnQu5tt8VXyhw5t67OOZqo1n9op0Det2H6rDUfcYVrdDoXTeB NI+tbPptvu9L75vWR3oRG2iZBGDNJiw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713550008; a=rsa-sha256; cv=none; b=iHfrVIUh+P4ofM4NksWuFTmz/pu95kkr4uvMPyxsLW57TzZ7kZnmcsN37SrjcSHtLNWgvl EDQCxKIRFFqXharhWw3h8ZYCUOB00RlzjnXsqu2AS6z5sYJMJwbVxtr1ly0gWJsL/7bDve I7eyvV44aPFRT6OUA9CwiZ5tmnsMCNY= Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VLjGG1Ljkz6JBHw; Sat, 20 Apr 2024 02:04:38 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 50007140447; Sat, 20 Apr 2024 02:06:44 +0800 (CST) Received: from localhost (10.122.247.231) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 19 Apr 2024 19:06:43 +0100 Date: Fri, 19 Apr 2024 19:06:42 +0100 From: Jonathan Cameron To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH v8 06/10] ACPICA: Add __free() based cleanup function for acpi_put_table Message-ID: <20240419190642.00005ee7@huawei.com> In-Reply-To: <20240419164720.1765-7-shiju.jose@huawei.com> References: <20240419164720.1765-1-shiju.jose@huawei.com> <20240419164720.1765-7-shiju.jose@huawei.com> Organization: Huawei Technologies R&D (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.247.231] X-ClientProxiedBy: lhrpeml500001.china.huawei.com (7.191.163.213) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Stat-Signature: b558kf55hquirppf4sh7ehia1rffk5sw X-Rspamd-Queue-Id: E51A5160014 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1713550007-137676 X-HE-Meta: U2FsdGVkX19As/AvcWKleUcZ2SxjL8UC0NsZFN2GhPFBfxpj2Rm7RZh03iuMSzhi0rthaLUOsPMB/sbGrNIhzvqBQ6qNiqIYnikxQRsPuk50Ec5R+PsrVTezWx+Oerg2p9zlLeKQA7UTMX7R12NXxy/2w2sC3PmMoIQhHrDsUZhMzdKoC75ERnvmt7hwwIFqrUUoyo6HzBvmgsfuQRe0lDiRfCBGQlr8SuCwVxlsXsoRlVDLXw9tUSq06LCAKrrvBJ6BFO0+HFi79kD7bnd+O7Pca5unSH/6UHyHLAXWsM6qqWG+SaaCh83xGsEkLkc+3MwQtuMUsblQ6AGcfokjcY/4XUnh03l5l2zZKC9s2MWV4toDyzzQDn9y38FKkrKPH7qPeDFenspz7DDO1NZHeQZpmRg7uFmjpCDLP/Q/JAer75qenD/XYkyr3qhue/u0TfGky4WuIxlXupC8zgrYGbQROlExSry7C9mlh9CLzv5/mj2Keu5+pIYGcRgUaVeriopO3NA/edlTfI/bG+wpGykU7XbFc7Wd/TbZkH6l/SJJGhdx6MxSe/thFvcItuMGTPK1miHkwqsQFT6YNd+AYkjMU/qDe085iAuok1aZL3l8F9zRE6Ry9WQ2+Lf/b3DMMvIt9sAr3BElivz0LMlgPekXb7cGFOxlA7fL9OGPURH8fLTAdySlQ9bJm6FB6pmVE9oebTzKeJFUGmFawM41Ns8v0eSnOjxpAqH01rtUoZrW0++sayMA1OD9+pddKkL+SUNCrVEB8qloX2bEo3mmefI2zvWA5D6TYT0xkC1TRSxcOW6JKP9FamgjCb6p+lvhsFnFNkqyUR+KO26T4CXMPS0cYt3irwfEPuNVv27X6kyONk5gqMollXForYxGCr7T6Uki+0FQh5rdoA1xMkB/BCQ/BaGYKAPkg7fYBAYo9Xpdd1G1zG/NQ7cVU6Ex6HzjXi22XyA8BqsZZUHClBk 3Dw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 20 Apr 2024 00:47:15 +0800 wrote: > From: Jonathan Cameron > > Add __free() based cleanup function for acpi_put_table. > > Signed-off-by: Jonathan Cameron > Signed-off-by: Shiju Jose > --- Reviewing (and rejecting) my own patch time ;( I was thinking this would be useful more widely but hadn't looked as closely as I should have done. Sorry Shiju for sending you down a bad path. > include/acpi/acpixf.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h > index 3d90716f9522..fc64d903a703 100644 > --- a/include/acpi/acpixf.h > +++ b/include/acpi/acpixf.h > @@ -492,6 +492,8 @@ ACPI_EXTERNAL_RETURN_STATUS(acpi_status > **out_table)) > ACPI_EXTERNAL_RETURN_VOID(void acpi_put_table(struct acpi_table_header *table)) > > +DEFINE_FREE(acpi_put_table, struct acpi_table_header *, if (!IS_ERR_OR_NULL(_T)) acpi_put_table(_T)) This is reliant on acpi_get_table2() in patch 8 / below being used as acpi_get_table() doesn't return the table. Maybe we are better off treating acpi_get_table() / acpi_put_table() as if it were a conditional lock? Or change the 93 instances of acpi_get_table to deal with it returning a copy of the table handle pointer That would bring it inline with many other get functions in the kernel + make our life easier using tooling like this. +static struct acpi_table_header *acpi_get_table2(acpi_string signature, + u32 instance) +{ + struct acpi_table_header *header = NULL; + acpi_status status = acpi_get_table(signature, instance, &header); + + if (ACPI_FAILURE(status)) + return ERR_PTR(-EINVAL); + + return header; +} So that we could do things like: + struct acpi_table_header *pAcpiTable __free(acpi_put_table) = + acpi_get_table2("RAS2", 0); and avoid having to call acpi_put_table() in error paths etc. The snag is that acpi_get_table() is from acpica (via this wrapper) so any modification would be a little messy. Also a number of cases use the status value via const char *msg = acpi_format_exception(status); Which we'd need to return via some path (a parameter probably). We 'could' do that but the advantages of this are getting eroded. Upshot, this is messier than I thought, so we probably shouldn't do it. The code in ras2 can be done reasonably neatly an outer wrapper function that gets the table and an inner one that deals with the actual processing of the entries. Pity as there are some messy bits of code this would tidy up. In most of those a helper function also works. Jonathan p.s. Whilst looking at this I noticed that acpi_has_watchdog() if it succeeds doesn't put the wdat table which seems suspicious as a side effect. > + > ACPI_EXTERNAL_RETURN_STATUS(acpi_status > acpi_get_table_by_index(u32 table_index, > struct acpi_table_header