Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3347891imm; Fri, 19 Oct 2018 09:07:47 -0700 (PDT) X-Google-Smtp-Source: ACcGV62QOln2W3mRIUQEJdYxX2qDNHh8jWv2uqWYSiqaH9Xwr4oDhBqkyDKuI8RpgXPDEFoP6oSb X-Received: by 2002:a62:a0e:: with SMTP id s14-v6mr34980601pfi.153.1539965267196; Fri, 19 Oct 2018 09:07:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539965267; cv=none; d=google.com; s=arc-20160816; b=szIPt+dT5Ly5VIhKdn6sy2bqrxDFMf5ADnpvK3T9v/5UpkXZXoeoh7y8KWSWaR33Qk KnlUzh4eKydXfTA1XJAgPqa/Ar33ENl4RSCKPy2UNm8i1ojrWFj87yktxxXyy10Z8b2z /oVHvxWpGBeqcmDBffkbeIq4ruvB7tqRqEotxeP5iIGwPxYzJaq8z/lr86JCx/GUB2pn g51wJFzRvuAoB5vjCpIb6r16MqBPKUBTwXn3XUWhE/Wtl6iClyOuNKJ+uy2IJlTyBhZP TJ9t1wkS2jL2DgGweL/GOKxcNIQK4L/OayezieN4hHo05oROtAQuc9vctWz29UDtAm1J 0Y1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0VNOS2qTxnqGlq3kG5cZnRkajXfEDdZuL6Pf7ENMFjY=; b=D5SZTdPYskdN9hNI6s6egozUHN0HwCW6p/gwyfcfmws6Ci5hSigNzHABuR3HzWSh77 /EdE6CjrhipSDHvgnAYDaElMOZEzTrKhBd/749DtKMazURtqf5sWqVLhv/FjboNkRS28 9RVVDT0BiDNZAm+GHg/26ri+qV6QLgTh3I9ApNtp6TkhQDzBBKyeqeu7cCtc42UV2Urf 0WOVPKEA7uYLXnyahLqoUAwrrPM5Osc4HN4ja4ExdcRLphJyOUCg3tRnkXbxlZj5AV3N CvtlqHdCBVvGLNEvm0vL3qhNnZmZdZ65vsR7M1MpRTohsSIvjA+BTgx0jXDdbwsstPb5 P/dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="WNTMENG/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k9-v6si23612795plt.144.2018.10.19.09.07.31; Fri, 19 Oct 2018 09:07:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="WNTMENG/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727832AbeJTANX (ORCPT + 99 others); Fri, 19 Oct 2018 20:13:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:57442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727289AbeJTANX (ORCPT ); Fri, 19 Oct 2018 20:13:23 -0400 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 40CC02087A; Fri, 19 Oct 2018 16:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539965198; bh=j3uplFitsOvsTR4G3hhmUQEIP1JLMzK0uNBbPUSk4hQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WNTMENG/S5yDn2dTPeXKTZlSO4pDX8APQuXF81c4Rf4LejvbB2QGiZXKUfRUvb+aV mI81w2zcZXkS7WUH2oNpDKbxfCTHVYTeLwxqq+g52evn+4rlUjQSJYJJQKj/pG9m7L Ya7BcrKict5c2Rt1HAfkMvDiBOAg1H8Npu+ouCvk= Received: by mail-qt1-f175.google.com with SMTP id u34-v6so38863306qth.3; Fri, 19 Oct 2018 09:06:38 -0700 (PDT) X-Gm-Message-State: ABuFfogBPIdvzdW5yfgzjzmIU1dxUwXZe22Nmt/Pcys7Gm3eU25ne8K8 HI6AHf2QgwQnRRqpPngwbBUkiIFe/CzajYaLfA== X-Received: by 2002:aed:3ec2:: with SMTP id o2-v6mr33937861qtf.26.1539965197390; Fri, 19 Oct 2018 09:06:37 -0700 (PDT) MIME-Version: 1.0 References: <1539736466-28638-1-git-send-email-frowand.list@gmail.com> <20181018193216.GA9971@bogus> <2f99d700-6276-cfa4-8878-4eb161126330@gmail.com> In-Reply-To: <2f99d700-6276-cfa4-8878-4eb161126330@gmail.com> From: Rob Herring Date: Fri, 19 Oct 2018 11:06:25 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] of: overlay: user space synchronization To: Frank Rowand Cc: Pantelis Antoniou , Pantelis Antoniou , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Geert Uytterhoeven , Alan Tull Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 18, 2018 at 7:06 PM Frank Rowand wrote: > > On 10/18/18 12:32, Rob Herring wrote: > > On Tue, Oct 16, 2018 at 05:34:26PM -0700, frowand.list@gmail.com wrote: > >> From: Frank Rowand > >> > >> When an overlay is applied or removed, the live devicetree visible in > >> /proc/device-tree/, aka /sys/firmware/devicetree/base/, reflects the > >> changes. There is no method for user space to determine whether the > >> live devicetree was modified by overlay actions. > > > > Because userspace has no way to modify the DT and the ways the kernel > > can do modifications is limited. > > > > Do you have an actually need for this outside of testing/development? > > I do not know if anyone uses /proc/device-tree for anything outside of > testing/development. If we believe that there is no other use of > /proc/device-tree we can simply document that there is no expectation > that accessors will see a consistent, unchanging /proc/device-tree. I didn't mean whether /proc/device-tree is used outside of testing. It is. The question is whether any users care if there are changes happening. If so what is the use case? kexec used to be one of the main users, but I think it has switched over to the exported FDT which matches what the kernel was originally passed. > > That would be a much smaller patch. > > > >> Provide a sysfs file, /sys/firmware/devicetree/tree_version, to allow > >> user space to determine if the live devicetree has remained unchanged > >> while a series of one or more accesses of /proc/device-tree/ occur. > >> > >> The use of both (1) dynamic devicetree modifications and (2) overlay > >> apply and removal are not supported during the same boot cycle. Thus > >> non-overlay dynamic modifications are not reflected in the value of > >> tree_version. > > > > I'd prefer to see some sort of information on overlays exported and user > > space can check if that changed. IIRC, Pantelis had a series to do that > > along with a kill switch to prevent further modifications. At least some > > of that series only had minor issues to fix. > > The kill switch addresses a different concern, which was from the security > community. The kill switch is on my todo list. Yes, but there could be other uses. It's not a big step from wanting to know if the DT has changed to wanting to control it changing or not. Perhaps the kill switch needs 2 levels: a temporary freeze and a permanent freeze. In any case, they don't seem completely unrelated and I don't really want to see userspace ABI added bit by bit. > I don't remember exactly what info the overlay information export patch > provided. I'll have to go find it and re-read it. > > > > Also, shouldn't we get uevents if the tree changes? Maybe that's not > > Yes (off the top of my head). But a shell script accessing /proc/device-tree > is not going to get uevents. No, but userspace can get them. Accessible from a shell script is not a requirement of kernel interfaces. Rob