Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2548509imm; Thu, 18 Oct 2018 17:07:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV635ZQux5j04cAownBjS0hDLlB6Th+ivxEw9EU6Ti2owG0BmzBTCH9fcEtSkyak9HP7o2DqM X-Received: by 2002:a62:5b43:: with SMTP id p64-v6mr33151333pfb.122.1539907665158; Thu, 18 Oct 2018 17:07:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539907665; cv=none; d=google.com; s=arc-20160816; b=qb8+JEUkXHJytqyRIJumk1ccMm6iPbJHZFnODQ/Ju1YYIxagdcD+GIGgb+lm6djPCb SyJQfbfHtfNB064B1YAtzgyKZ5XTLZZysSfa0z+smaLFcbf0SHXPsAIYXVumihRN+krX OVgVJ1CRHNbN//OXnI65gcVlpIQN3qs/x723LY5KV3lx8oeMxMKiU6pTQaj/7nOzGs4m 1IKP/DGRi1c0Z2oIEl+MfoUutaD/HZDZlg7QAvKwC5ZsRVwlTHNZeR/N+2cXwAbtCa3T 9jJhvLi5asfBVeNHfp7mkMyWXcsXZy1ty55P18AebhDsl0GBEoAfsxV5jyv41PY22Qcw ag2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=hzSmIaAW2uKSQKBoPXgSJO+38CKDhJSh/7BFDbl+FK4=; b=iCTRMsUXuNzpOLUs/geiik4r0BK9d0YLo1+nWAHxO4K+R4WzNqcyZRaso+hDS9yNj/ uW1Md96taUJGFg0jGHlTZbcovSaAYbP879/xlJHNmGKz1QmfcA9vEqWhEulEGdm32D69 VJdUIULXpCyfrfYA1WmdzJSozhqIpVpnPkPp7ybXmDPCoyeA4kehWqNS1O6LYPFNrtzF INlANNkcyRmoPCZZ+bcIAXGwyrKctaI+G8o4HdoWZITBniwqX8c57FBrdBS0d/S05xkz 1/yUdWSnhwgr/yPxeIpch1w8oEwGEZ/qcIo+I/Uy+EK2SRCY34HdlafNAhC3oDVHmOQV zDaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Def385J9; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5-v6si22462651pgf.565.2018.10.18.17.07.29; Thu, 18 Oct 2018 17:07:45 -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=@gmail.com header.s=20161025 header.b=Def385J9; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727076AbeJSIKF (ORCPT + 99 others); Fri, 19 Oct 2018 04:10:05 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:40624 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725934AbeJSIKE (ORCPT ); Fri, 19 Oct 2018 04:10:04 -0400 Received: by mail-pg1-f193.google.com with SMTP id n31-v6so14941574pgm.7; Thu, 18 Oct 2018 17:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hzSmIaAW2uKSQKBoPXgSJO+38CKDhJSh/7BFDbl+FK4=; b=Def385J9UNyd/klynrfA9FMk2Hij0g4CahUxF31JxRX2UOtq6V8zUg17nXh4nzIg9L m+HM2OJNIJu8U5KrJwJXzATju8HbbIgBpu4ox1omtYcDYjXZAmNPW9r0L/ssUkl9Ut95 K1BY79nj69+EefXCRQdmwpDb5795FCflxl73VZDyLvFQOA0zgOTJz1VXrAM2ev4o2Tjo sHW9UFx8X0Jc+LobqJx1HYEAKwYkeOG40lMMJAMoQZXf4mb9Aiz4zwONu6DLE0mZlye0 4DKDGfaZBKSVGDkyyp8jGlpwaKh8EOVYIfKutYJNTvCPyo85t1vhAkv6Ivm+7tNJ1UQ6 4Asw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=hzSmIaAW2uKSQKBoPXgSJO+38CKDhJSh/7BFDbl+FK4=; b=oZZaQEU5EoUjN7Yt8EkSMFZv6UfVk0kr32zafCIwSqF7e/8zdpi1h04bGRvPwELWoC MWy1aQ+1eLfbEpEOeLD9M51O4PHAA15sahF2Hy4mV/GdioM0x6OL9eLtQpgMw3nMuOXJ Em8nMyYXBR1D8+J4prW1AHZ+JC4DfFpj0aO8KdGqvrZUwQ00KhmJZi5+i3ej+AQVzMUK f9jQFwBNOWI/yhjek+VpsVU8hY5EHynYjDOLfJy7CUBIRHXZ4pdLTQjO0zLX7qJTFyHS cQp+Est6ofqDxl7U10bNB8IGggJOpTTgdqaXI8elp1T7pJ/dLn/kWHjkUz+xn7AuqYWZ VAAg== X-Gm-Message-State: ABuFfojgq3o3m8y6/U3+hZ4rz1Q8xS7DQxRbBZcp7Q5jZ4y+BQARNEN4 zoq2eh8eUZr6Z9YxOB7CaPc= X-Received: by 2002:a62:1112:: with SMTP id z18-v6mr32468915pfi.200.1539907597999; Thu, 18 Oct 2018 17:06:37 -0700 (PDT) Received: from [192.168.1.70] (c-24-6-192-50.hsd1.ca.comcast.net. [24.6.192.50]) by smtp.gmail.com with ESMTPSA id y144-v6sm32543312pfb.81.2018.10.18.17.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 17:06:36 -0700 (PDT) Subject: Re: [PATCH v3] of: overlay: user space synchronization To: Rob Herring Cc: pantelis.antoniou@konsulko.com, Pantelis Antoniou , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, geert@linux-m68k.org, Alan Tull References: <1539736466-28638-1-git-send-email-frowand.list@gmail.com> <20181018193216.GA9971@bogus> From: Frank Rowand Message-ID: <2f99d700-6276-cfa4-8878-4eb161126330@gmail.com> Date: Thu, 18 Oct 2018 17:06:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181018193216.GA9971@bogus> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. 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. > guaranteed, but I'd bet we can't handle cases where we don't get events. > A property added to an existing node comes to mind.> > Rob >