Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2693275ybt; Tue, 16 Jun 2020 12:31:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyAqcL+8PZGuL8F8M75hSkMrI0xRWMHfQOVdWwL+Sau2eEGW1ufVFzRTfmK26DV4AHb2p3x X-Received: by 2002:a17:906:aec3:: with SMTP id me3mr4185580ejb.94.1592335867873; Tue, 16 Jun 2020 12:31:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592335867; cv=none; d=google.com; s=arc-20160816; b=Y+zGTDTGLuewuMygbx0nboVr89n4yptSYAMGUQC8VthXONHXjzigPVGf4cWRgl5oZN OTQBpN5y20H3yCeZ4bTKoFQPmAwYPro3T5kUfxqziSTrS4/9/AJh1vFqAZHc23rvMUoF dkL5j9ey9vIuSZ+WQqKb5OIwsusR+krNie5f5BrjIGUL9VtyZxukIoWA1ti6Bq+AZ8uK /6/w02+6uuslcIo/6r3Lh/rn9DmZn0erCsc7A/kFlXJC0jeri5B5TtYwykxfvjHJ53zo Fi1d4NhBm+Mh9RdeID/9971H37bbK1YPxZ3tL3eSv4q122/XNeCvmJJJxvRUl2opUi8k geTA== 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=G+QuAOUfD+yaHMOx7JS6V2Ec/laXvrlFy0R9vzQGqF4=; b=kHLK27+TNmxn0NVgmhkR8OMMTeQ4tlrXGLTQ0h5173mXyBjO4lP5ls2bwd1idtvycG 3681h7NcZQqV6VAU37jjctw588UkFT8iHuPPEgJR9rYmTDS/6FPwt/8oMy/zbQ8dG2Az aC/wr3xL28cbMg5hd0NHZh6gN2qli4uCNwkjyaP5g//8NTNswWHNWmamUrKxSGOlxitL bsBlM9FL9inSwj0NQg4d/C6tNqkfHWTog7wum4l0JNizk0SkNMZcuRKodp7T/47t4vWl s+q6Hx7LE+7qUl/FSTPA673Dz/0g6NKGfLMBRky6rqv9BrcazfZgjDBDXx4GQExVskfx bOYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QOMab6ZB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q21si11064788ejo.586.2020.06.16.12.30.43; Tue, 16 Jun 2020 12:31:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=QOMab6ZB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730997AbgFPT2S (ORCPT + 99 others); Tue, 16 Jun 2020 15:28:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730955AbgFPT2Q (ORCPT ); Tue, 16 Jun 2020 15:28:16 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8EC0C0613ED for ; Tue, 16 Jun 2020 12:28:15 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id e4so24996908ljn.4 for ; Tue, 16 Jun 2020 12:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G+QuAOUfD+yaHMOx7JS6V2Ec/laXvrlFy0R9vzQGqF4=; b=QOMab6ZBai8eX39llL4QAiuIVWOQ0kfvL9ywteJNjgzhCzjyOqdlLEs34RuWRfNLLY UBmJ+sjmxHSY9KClbzPYRcmHfIbDr3RgcQIUrbh/HgB4x65p5TjwXtES2J8FIy5PzqLb qNhgVYP39gDxMPl9bQhhUq4S3zMv9UfF/pmETt8VJF4G41Qcz/1zK2PnlCpJF0fz/S6h PxHy+BSAWFuylkqNZeMw7xFvJ8qR/7v1dKWfEPia1fKfpNNvfy691K7fCJ3W9iR5AH/V gFeKsPsrdm5Ge3TmLS1y0qxW2m4XjgJOTWFoy9c831CRjVEIM34ATLROHfUGg4Z8jDHa f9Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G+QuAOUfD+yaHMOx7JS6V2Ec/laXvrlFy0R9vzQGqF4=; b=pYDCnw8GGlNNxayv6F1FnjFZdcT7FNw2N+eM47Tah7NFQ7/hY+tOam0gkC4xh/eMIh 7ngMzHOUOSkY/TYfLfgD0MF7jzdRRSAfwNNRmqU57sQiTmCiq5sbcvuHdvj/RDICowV8 j50oyWByaI4qKrPHbmp85O5dabPgolD1WBq+QtZCfm53ZAwz+AtXm6NJzGulEsU8Dq5R 6Jlr2Q3RyhfITW+SQqGgJgIT2Ua5CsMv50EgcAx7GkEBGMkdbaVpT1/jdvzSgxebeQmM GkoPfayZZ1BEhMcZixMtbpvIDIe3MW1U3KW2MrRDV8aR8sgcIqjFfREagSBPq5veTg/R R2kA== X-Gm-Message-State: AOAM533QZW8rjmNTMKFn1x1JZZ0c5hAv74n9P0+9FILA4quFSXPqCLak KhGZ20ERNaimNzZ3nEFnOwKGfO5B2Rag8tXzhGVfkw== X-Received: by 2002:a2e:908f:: with SMTP id l15mr1993656ljg.307.1592335693925; Tue, 16 Jun 2020 12:28:13 -0700 (PDT) MIME-Version: 1.0 References: <20200616011742.138975-1-rajatja@google.com> <20200616011742.138975-4-rajatja@google.com> <20200616073249.GB30385@infradead.org> In-Reply-To: <20200616073249.GB30385@infradead.org> From: Rajat Jain Date: Tue, 16 Jun 2020 12:27:35 -0700 Message-ID: Subject: Re: [PATCH 4/4] pci: export untrusted attribute in sysfs To: Christoph Hellwig Cc: David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , iommu@lists.linux-foundation.org, Linux Kernel Mailing List , linux-pci , linux-acpi@vger.kernel.org, Raj Ashok , "Krishnakumar, Lalithambika" , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Rajat Jain , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , Greg Kroah-Hartman , "Oliver O'Halloran" 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 Tue, Jun 16, 2020 at 12:32 AM Christoph Hellwig wrote: > > On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain via iommu wrote: > > This is needed to allow the userspace to determine when an untrusted > > device has been added, and thus allowing it to bind the driver manually > > to it, if it so wishes. This is being done as part of the approach > > discussed at https://lkml.org/lkml/2020/6/9/1331 > > Please move the attribute to struct device instead of further > entrenching it in PCIe. Need clarification. The flag "untrusted" is currently a part of pci_dev struct, and is populated within the PCI subsystem. 1) Is your suggestion to move this flag as well as the attribute to device core (in "struct device")? This would allow other buses to populate/use this flag if they want. By default it'll be set to 0 for all devices (PCI subsystem will populate it based on platform info, like it does today). OR 2) Are you suggesting to keep the "untrusted" flag within PCI, but attach the sysfs attribute to the base device? (&pci_dev->dev)? Thanks, Rajat > I'm starting to grow tired of saying this > every other week while you guys are all moving into the entirely > wrong direction.