From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BF9D470EB5 for ; Wed, 22 Jul 2026 19:09:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784747372; cv=none; b=lqFDgfaBXGnYj3KkBFujFSPTAqxCyIVGBorni1HrrUsPaVAhXiJ4kJCbUOH1LCOs74hXpy6A2fxld11hPreLOwtRukNf38XGVSQQ4swEVDSde2cXoQj70HlDWvPZzKDNxoSBjhKZXC3f35S3afDjq5mX0RA2CLlCUdDfc4EcpTg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784747372; c=relaxed/simple; bh=p4raCd1confxRNlp3M3uyqGsNSt1XxUovtON5e9BL0M=; h=Content-Type:Date:Message-Id:From:To:Cc:Subject:In-Reply-To: References:MIME-Version; b=LbOnMFT3Yk8Sz3vXH9BFXmrbY33XBozDTAv3MTIe9x+ylkAiZI/bdPEdxkIs8iXUKb1+by9tAUXtlPADTiQ4fUyz/Lrt+63Xo7digaKXZWFv0JXorcckoHCz5E3ZJ1H3fOgfh/OyeOoGpolCO38dUfqaV9wVVXrVBGn2K2NSRUQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=REa0wJWE; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="REa0wJWE" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-38dd55ad76cso5546039a91.1 for ; Wed, 22 Jul 2026 12:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1784747370; x=1785352170; darn=vger.kernel.org; h=mime-version:references:in-reply-to:content-transfer-encoding :subject:cc:to:from:message-id:date:content-type:from:to:cc:subject :date:message-id:reply-to:content-type; bh=anF0nP/HcLCiIU6NqI+XBEAlEYdw+ekpN6PK94U5YWE=; b=REa0wJWE0ga3apZdPb1ZPkrN4qCEnEPocy/S+ZN1zgcF0IHhDTfGJ9XOFHaPl4TQQP huqfHdPtFHwqhYirTfuJMSk+Mt9A0QX6trckBPUxIpB/Szc1kgyrYobe+oYldCMrXa6A 0pPnqQnVQcsVHzFUBWLOoCsxSayrh6fiG8XSBg8/iFDbGruozPv7RRoRB1wI9RZg/iEj 6K3Uz7lijAnGDzZ5vobWrP/6W+A07vacv0xBljC5cMtChONJ/3enEKIHkHz6sRBYey/3 Y/ewgEqHrtd24Xab+nOzf38WWMBGSc/Ctay06ZV8YFdjBDqGIaIX4Qf8os3LD8dSS+4G F+dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784747370; x=1785352170; h=mime-version:references:in-reply-to:content-transfer-encoding :subject:cc:to:from:message-id:date:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=anF0nP/HcLCiIU6NqI+XBEAlEYdw+ekpN6PK94U5YWE=; b=H3gqE+2mm8xACo21kcxvOu8I+0slozu/vCJ28mjTXb5a0UmD0cHQztOVY/OWt+82Hz AjLU/xiQOlI+T+VW56OgQ7fok/zK4u0TJEgzmmPWYUXfGpFF9exRxKhSKXAdbKpdZFrD QtFvZo8uuVwhHl0jnQc6hKscDf5bMYoQ5mNrYjaCAFENPP0fWoMRIgbOFuI008GEGnyF VH2nH6fwSTnzDUjomodUNc0wWlh4J/uNDu3HvCd4A+Jmly4EGdozBx2EqZ5D4wVnRaMd BOPDO3r9TTTj+U7LFBrYC6XogfxUi39Ek70G/nQ5c+bC0YudOLRk4CSEMuRnM8BYQx5s BuKQ== X-Forwarded-Encrypted: i=1; AHgh+RpOp4nUGnWC622zArXfIRAFZ4XHImnw80eh74rF9VEKEj2pqDdj7hfZnycy9LN23CaHCV0nTus+efiHs9Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/fNWRjmW7z4NDvCEK/AZuHlIRVL6Jj556OGhuS600+kycqEip VafCaArPeB4uXGmbB66DbhZ4EW94Nli3tEM3latTdYZBOvhkmy2oTa+02UjsgseNsv4= X-Gm-Gg: AR+sD13g8E4T6l/eOntpdIJs9PRpJR8Hlovdh1c5feF6OuhVAbZ1Z0rfg5UDIVJ/pgl iL5xUURui2ImOyWHkOggRa+RfBihdKTlsE4Ql2bngVfxQPR5EfRr361wTim+gxqNpQrITDlh/XK 5suqAx6H/AY1z7lLHNwFfjZuHC4n2yFq8YqJPDF16QT+r6jijmf/BCYkvYisCcFR0pMX/ipmHHf jxgnHnhXO9UatIVqvdk92NhCADen9OY78FKmNhpo3aqZ8h4PtVx0yb1dJOUNHRLx32ZxIOjT2GF 2XzkoWCTH5Y1bZhnALAObyU31QY7Aq2W9XggokGPZhxzp8J2LLV3jm2b6qyuuZbdYyrrKLimgoL IJ2bTdAM+1KNhQ8uq4j7YyUackHH2ZFf5jois1dE8cdxHOiXBlu5Ol+vh/cFXclfCf382OjIOMh ib5g== X-Received: by 2002:a17:90b:1fd0:b0:387:d9cc:7dc3 with SMTP id 98e67ed59e1d1-38ea3942072mr5969464a91.21.1784747370543; Wed, 22 Jul 2026 12:09:30 -0700 (PDT) Received: from localhost ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13d130a87e9sm8040518c88.11.2026.07.22.12.09.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 12:09:29 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 Date: Wed, 22 Jul 2026 12:09:29 -0700 Message-Id: From: "Abdurrahman Hussain" To: "Krzysztof Kozlowski" Cc: , , , Subject: Re: [PATCH v4 1/6] of: resolve alias-prefixed paths under devtree_lock Content-Transfer-Encoding: quoted-printable In-Reply-To: <20260722-noisy-husky-of-security-6dd93c@quoll> References: <20260721-nh-of-alias-overlay-v4-0-8ad097e31e36@nexthop.ai> <20260721-nh-of-alias-overlay-v4-1-8ad097e31e36@nexthop.ai> <20260722-noisy-husky-of-security-6dd93c@quoll> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed Jul 22, 2026 at 12:30 AM PDT, Krzysztof Kozlowski wrote: > > While here, validate the value's shape before handing it to > > of_find_node_by_path(): /aliases contents can now come from overlays > > Can it? Not at this point in the series -- patches 2-5 are what make /aliases writable at runtime. The message got ahead of the series; I'll reword it to stand alone. > All this looks like AI written. The tooling is disclosed in the Assisted-by trailer. I'll cut the prose down in the reroll. > > + raw_spin_lock_irqsave(&devtree_lock, flags); > > Since when do we lock looping over for_each_property_of_node()? > > Do I understand correctly your proposal: you want to add > raw_spin_lock_irqsave() over every piece of code having for_each_XXX > OF-loop? No. You're right that the walk doesn't need the lock: removed properties move to the node's deadprops list and keep their ->next, so a walker holding a node reference never steps into freed memory. That's why every other for_each_XXX user is fine lock-free, and I shouldn't have pulled the loop under the lock. What does need pairing is the of_aliases pointer load. Patch 2 adds a reconfig notifier that clears of_aliases and drops the reference it holds when the node is detached -- overlays can create and destroy /aliases from that point on. A reader that loads the bare pointer without taking its own reference under the same lock can have the node (and its deadprops) freed under it mid-walk. I'll reroll with the lock narrowed to the pointer load plus of_node_get(), and the property walk lock-free as everywhere else. Thanks, Abdurrahman