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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12ADBCD37B3 for ; Sun, 17 Sep 2023 09:13:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235120AbjIQJNB (ORCPT ); Sun, 17 Sep 2023 05:13:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236037AbjIQJMl (ORCPT ); Sun, 17 Sep 2023 05:12:41 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68F9218B for ; Sun, 17 Sep 2023 02:12:36 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-31fa15f4cc6so3361670f8f.2 for ; Sun, 17 Sep 2023 02:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1694941955; x=1695546755; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=eIzkNF7FeuJCHsWmBBiFl7ckCgevreFCJP37qRY7qOE=; b=FlpXbKpNnSh3pcJE2SYWTQ4c8e4fSYth26+ZWthLMOqlCbIJ/OCZIDmHCZOicAN/QL wJKx2mvChib9ZzTjFkJ/uaFFKx8LqCWy7H07GyyCSgwaIfYSPsPVic+e9/gkBS35/XwI D7153ObsrTChalFzg6rjZzk34TdV8zJcEcgZE0KBzv4W1qvDj1gy0+6qr73RFkFZOjoq Mw0L/6ZB91AljXxIf8HwniXsqnOjz9Nel6JSaSzFv9i4a81UpPNRsUci8PzF8Zhc24ue lEKLu2qX7bam/tuHEiB4FEB6jl/AlFSY6kY+eCB+hHFRmp8b4WKFDdb8qoEqMhS2dBgx GK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694941955; x=1695546755; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eIzkNF7FeuJCHsWmBBiFl7ckCgevreFCJP37qRY7qOE=; b=Tc/Wtl3bbayDvTolLyPeiz9PgtfHc6HDMKKbvuwTdbP13N+2Lk2N0p1OLAQHZ5mnxE TuXde678KfqqOI2G2Hub2xXXPn54d1gIYV3HYTuKWR2izAII8STCtvrp+V8IPIIdvU3s EBlzSc85s4VHOG48WokCMyRkxk41HaWqVIogz51sltLskRVJEd0fSNokB/DVqXKDg13/ zaHIUJbU4+YuVl6ML/7A29hifdq4dczw25skZqoDAVWphJoEikQzgh50frTNPVFNFSDi hEnXGpabXzdPyI3Nv3lwYdnlRoquh1oU2jvtfE2wk8IhwQ8lGulx8vLUUN/+jV3YYGUu k5JA== X-Gm-Message-State: AOJu0YzExunZP6NM18yqWjc6ubH5F0PQwVF7284DCy97zoaO81AkpTji nf98MYiI7S7va6+gmelHPqspzQ== X-Google-Smtp-Source: AGHT+IHMt7kgs7ogFAY35Byv8+iZhOk3KvEHEwDynVxRIqZHEWQP5fSujdsR5FSz8PwRPgBs3OfEUw== X-Received: by 2002:adf:eccc:0:b0:31a:ed75:75df with SMTP id s12-20020adfeccc000000b0031aed7575dfmr5417500wro.15.1694941954772; Sun, 17 Sep 2023 02:12:34 -0700 (PDT) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:4ea0:9945:6800:8739]) by smtp.gmail.com with ESMTPSA id r8-20020a5d4e48000000b0031ad2f9269dsm9099688wrt.40.2023.09.17.02.12.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Sep 2023 02:12:34 -0700 (PDT) From: Bartosz Golaszewski To: Linus Walleij , Andy Shevchenko , Kent Gibson , Alexey Dobriyan , Peter Zijlstra , Linus Torvalds , akpm@linux-foundation.org Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: [PATCH v3 0/2] gpio: sim: improve the usage of __free() Date: Sun, 17 Sep 2023 11:12:23 +0200 Message-Id: <20230917091225.6350-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org From: Bartosz Golaszewski Hi Linus et al, I'm sorry for the noise but v2 was incorrect, this is a fixed version. As discussed here's an improved fix for the invalid usage of __free() in gpio-sim. I based it on your "maybe-sane" suggestion but unfortunately it missed a couple details that make it impossible to avoid a conditional initialization of the managed pointer without repeating the call to fwnode_create_software_node(). What we're doing here is: we're creating the string array for the standard "gpio-line-names" device property. It can look like this: { "foo", "bar", "baz" } In which case lines 0, 1 and 2 are named but it can also look like this: { "foo", NULL, NULL, "bar", NULL, "baz" } Where only lines 0, 3 and 5 have assigned names. So the `has_line_names` boolean set when encountering the first line with a name is there for a reason, namely: it's possible that only the line at offset 0 will have a name, leaving max_offset at 0 but we still need to create an array of size 1 in this case. If the array is created and filled, then it needs to live until a deep copy is completed in fwnode_create_software_node() so it has to be defined at the top of the function. I think this still results in clearer code then if we called `return fwnode_create_software_node();` twice with the same arguments. I also changed the naming to reflect the purpose of the array: it can be sparse so it's not really "number of lines", it's the "size of the array holding the names". The array can be of size 10 but we can only have 3 named lines. To atone for the above, I've added a second patch which changes the other instance of __free() in this driver to be initialized in place. If this is alright for you, please consider applying it directly to your tree for v6.6-rc2. Best regards, Bartosz Golaszewski v2 -> v3: - restore the offset out-of-bounds checks v1 -> v2: - split the line name setting into two parts - add a patch improving the second instance of using __free() Bartosz Golaszewski (2): gpio: sim: fix an invalid __free() usage gpio: sim: initialize a managed pointer when declaring it drivers/gpio/gpio-sim.c | 68 +++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 36 deletions(-) -- 2.39.2