Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp11246508ybi; Thu, 25 Jul 2019 12:38:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJgXMXJgyjzkLKQMOuZA35E0DsLL+wsLqm/yQKz6giyt6ftt06wbM93fBhi0zaufFN4YxS X-Received: by 2002:a17:90a:26ea:: with SMTP id m97mr94581677pje.59.1564083498828; Thu, 25 Jul 2019 12:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564083498; cv=none; d=google.com; s=arc-20160816; b=wDzVjwfDOpWGm1eaPPw8ttciUlAHHaTdNrmEhVwesfWULSBs3GC6Ua2CypsEjisjNI /qmCFK7H1BKlqL4tWNZ60ragSENbSd7kRj6c/tnu3dczk6gV7AEEGRhDLqEpxbOz8gZM mRDzumuz3+FI3a00B24jHpeFuLL1u6T/XxiNCpWQwDSzTsbdN95Zs+ynH8ZLc/YdxnSn 2i4T12vlm2E4MXGklH9fY/suZL/VXEp+GG89FlSwrijqovgQc+tczAc1x0tDUkMdhCGX J7qeX/4o9pdrf/NUTcygS3SxnUi6FaFv3gUDj+PaRafGbYvic/UBrmugwTdgnturNmg/ hUzQ== 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; bh=bRrEPEVgexSO2qJ+xF9O3stEIjJPqaaPVCD0SdqrQlc=; b=Cn8Zvyy85LMf+2+42yb/2O2RyJAePhNX03esCNjUpVunuaN2gatlzYnfPHw6u7IJW5 u53wk0KSCbZybyUqlJ2vpTfgp/avX8q8qRhSnnSo8LW7itZINd7GxROtKq1ifOW6rljr 7t/cKZy0fehoGfUYEjUqguKZkLrgvMgrxr2ClcKpGnIKDJ40yGOQJ7KSthj12LivMFBS epAu1+juUK1oi8GqLnuzPdyeOR+lG878bg1rP6TQn6FF1/+tNAThzWPVABzNqI4sbl+u rTahfDC86gUKBgYzCo1TgMb3TIcxPooVcteI58zMdTWpefbLC5GPOYR3oaONDfOPIjtA f5Bg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q38si2467262pgk.63.2019.07.25.12.38.03; Thu, 25 Jul 2019 12:38:18 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726479AbfGYThS (ORCPT + 99 others); Thu, 25 Jul 2019 15:37:18 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:41066 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726177AbfGYThR (ORCPT ); Thu, 25 Jul 2019 15:37:17 -0400 Received: by mail-ot1-f67.google.com with SMTP id o101so52854476ota.8; Thu, 25 Jul 2019 12:37:17 -0700 (PDT) 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=bRrEPEVgexSO2qJ+xF9O3stEIjJPqaaPVCD0SdqrQlc=; b=SzzCyXiRNMP1N7slHOmSIjmirJZq0/SQSw320vDtStVJePkzFcEjrJe+mVSye8yAbA UwCpIAUADMP8/NNbqcnUPBC24p7EhRX3KUrBJ9ZFeki4GDTEms9FWTdnF9LWdyvZ1d0N HeGOBE0P0WmnXw1bGPcXO1LmzkzRCUjmLPxi6AWXLtKSxl2b4uYLOdGDq2QR6Vqd4cMP /y9+ISJDb5n2ZQIucrVO0Imv/OXaLWiqv9gYIYUy9TqkALc/hCqRujnPIvfJVM+BwZwh 7f3WzeIdD3HJwmLKsepG0MXP1s2tNAdHoLwXckgUPe+NQ8cDHD3z6pDYZKEgw4SXgX0N gGNA== X-Gm-Message-State: APjAAAWB/w1ehXI/hosYWPXZ7g483oR7sSO+rQ2p7qJ2cchSQ7zcbKDE QjkFtI9ds6yIgfLBgrEQusY= X-Received: by 2002:a9d:7a4e:: with SMTP id z14mr40017650otm.258.1564083436737; Thu, 25 Jul 2019 12:37:16 -0700 (PDT) Received: from [192.168.1.114] (162-195-240-247.lightspeed.sntcca.sbcglobal.net. [162.195.240.247]) by smtp.gmail.com with ESMTPSA id w22sm16304470otp.73.2019.07.25.12.37.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 12:37:16 -0700 (PDT) Subject: Re: [PATCH v6 02/16] chardev: introduce cdev_get_by_path() To: Greg Kroah-Hartman Cc: Logan Gunthorpe , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Christoph Hellwig , Keith Busch , Jens Axboe , Chaitanya Kulkarni , Max Gurtovoy , Stephen Bates , Alexander Viro References: <20190725172335.6825-1-logang@deltatee.com> <20190725172335.6825-3-logang@deltatee.com> <20190725174032.GA27818@kroah.com> <682ff89f-04e0-7a94-5aeb-895ac65ee7c9@deltatee.com> <20190725180816.GA32305@kroah.com> <20190725182701.GA11547@kroah.com> <5951e0f5-cc90-f3de-0083-088fecfd43bb@grimberg.me> <20190725193415.GA12117@kroah.com> From: Sagi Grimberg Message-ID: <966fa988-de56-effe-dd52-3515ee83629c@grimberg.me> Date: Thu, 25 Jul 2019 12:37:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190725193415.GA12117@kroah.com> Content-Type: text/plain; charset=utf-8; format=flowed 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 >>>>>> Why do you have a "string" within the kernel and are not using the >>>>>> normal open() call from userspace on the character device node on the >>>>>> filesystem in your namespace/mount/whatever? >>>>> >>>>> NVMe-OF is configured using configfs. The target is specified by the >>>>> user writing a path to a configfs attribute. This is the way it works >>>>> today but with blkdev_get_by_path()[1]. For the passthru code, we need >>>>> to get a nvme_ctrl instead of a block_device, but the principal is the same. >>>> >>>> Why isn't a fd being passed in there instead of a random string? >>> >>> I wouldn't know the answer to this but I assume because once we decided >>> to use configfs, there was no way for the user to pass the kernel an fd. >> >> That's definitely not changing. But this is not different than how we >> use the block device or file configuration, this just happen to need the >> nvme controller chardev now to issue I/O. > > So, as was kind of alluded to in another part of the thread, what are > you doing about permissions? It seems that any user/group permissions > are out the window when you have the kernel itself do the opening of the > char device, right? Why is that ok? You can pass it _any_ character > device node and away it goes? What if you give it a "wrong" one? Char > devices are very different from block devices this way. We could condition any configfs operation on capable(CAP_NET_ADMIN) to close that hole for now..