All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Oded Gabbay <oded.gabbay@gmail.com>,
	Dave Airlie <airlied@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
	Jiho Chu <jiho.chu@samsung.com>, Arnd Bergmann <arnd@arndb.de>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: New subsystem for acceleration devices
Date: Tue, 9 Aug 2022 10:32:27 +0200	[thread overview]
Message-ID: <CAK8P3a3y2=FyzK4S6MRfZdrz=DdLat1ajdT_uPmN533mNYmF9w@mail.gmail.com> (raw)
In-Reply-To: <YvIU/wMdqFA1fYc6@infradead.org>

On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote:
> > > This is different from the number of FDs pointing at the struct file.
> > > Userpsace can open a HW state and point a lot of FDs at it, that is
> > > userspace's problem. From a kernel view they all share one struct file
> > > and thus one HW state.
> >
> > Yes, that's fine, if that is what is happening here, I have no
> > objection.
>
> It would be great if we could actually life that into a common
> layer (chardev or vfs) given just how common this, and drivers tend
> to get it wrong, do it suboptimal so often.

Totally agreed.

I think for devices with hardware MMU contexts you actually want to
bind the context to a 'mm_struct', and then ensure that the context
is only ever used from a process that shares this mm_struct,
regardless of who else has access to the same file or inode.

We did this in a somewhat hacky way in spufs a long time ago, and
I would expect this to be solved more cleanly in drivers/gpu/drm, but
I don't know where to look for that code.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>,
	Jason Gunthorpe <jgg@nvidia.com>, Jiho Chu <jiho.chu@samsung.com>
Subject: Re: New subsystem for acceleration devices
Date: Tue, 9 Aug 2022 10:32:27 +0200	[thread overview]
Message-ID: <CAK8P3a3y2=FyzK4S6MRfZdrz=DdLat1ajdT_uPmN533mNYmF9w@mail.gmail.com> (raw)
In-Reply-To: <YvIU/wMdqFA1fYc6@infradead.org>

On Tue, Aug 9, 2022 at 10:04 AM Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Aug 09, 2022 at 08:23:27AM +0200, Greg Kroah-Hartman wrote:
> > > This is different from the number of FDs pointing at the struct file.
> > > Userpsace can open a HW state and point a lot of FDs at it, that is
> > > userspace's problem. From a kernel view they all share one struct file
> > > and thus one HW state.
> >
> > Yes, that's fine, if that is what is happening here, I have no
> > objection.
>
> It would be great if we could actually life that into a common
> layer (chardev or vfs) given just how common this, and drivers tend
> to get it wrong, do it suboptimal so often.

Totally agreed.

I think for devices with hardware MMU contexts you actually want to
bind the context to a 'mm_struct', and then ensure that the context
is only ever used from a process that shares this mm_struct,
regardless of who else has access to the same file or inode.

We did this in a somewhat hacky way in spufs a long time ago, and
I would expect this to be solved more cleanly in drivers/gpu/drm, but
I don't know where to look for that code.

        Arnd

  reply	other threads:[~2022-08-09  8:32 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220731114605epcas1p1afff6b948f542e2062b60d49a8023f6f@epcas1p1.samsung.com>
2022-07-31 11:45 ` New subsystem for acceleration devices Oded Gabbay
2022-07-31 15:37   ` Greg Kroah-Hartman
2022-08-01  2:29     ` yuji2.ishikawa
2022-08-01  8:21       ` Oded Gabbay
2022-08-03  4:39         ` yuji2.ishikawa
2022-08-03  5:34           ` Greg KH
2022-08-03 20:28           ` Oded Gabbay
2022-08-02 17:25   ` Jiho Chu
2022-08-02 19:07     ` Oded Gabbay
2022-08-03 19:04   ` Dave Airlie
2022-08-03 20:20     ` Oded Gabbay
2022-08-03 23:31       ` Daniel Stone
2022-08-04  6:46         ` Oded Gabbay
2022-08-04  9:27           ` Jiho Chu
2022-08-03 23:54       ` Dave Airlie
2022-08-03 23:54         ` Dave Airlie
2022-08-04  7:43         ` Oded Gabbay
2022-08-04  7:43           ` Oded Gabbay
2022-08-04 14:50           ` Jason Gunthorpe
2022-08-04 14:50             ` Jason Gunthorpe
2022-08-04 17:48             ` Oded Gabbay
2022-08-04 17:48               ` Oded Gabbay
2022-08-05  0:22               ` Jason Gunthorpe
2022-08-05  0:22                 ` Jason Gunthorpe
2022-08-07  6:43                 ` Oded Gabbay
2022-08-07  6:43                   ` Oded Gabbay
2022-08-07 11:25                   ` Oded Gabbay
2022-08-07 11:25                     ` Oded Gabbay
2022-08-08  6:10                     ` Greg Kroah-Hartman
2022-08-08  6:10                       ` Greg Kroah-Hartman
2022-08-08 17:55                       ` Jason Gunthorpe
2022-08-08 17:55                         ` Jason Gunthorpe
2022-08-09  6:23                         ` Greg Kroah-Hartman
2022-08-09  6:23                           ` Greg Kroah-Hartman
2022-08-09  8:04                           ` Christoph Hellwig
2022-08-09  8:32                             ` Arnd Bergmann [this message]
2022-08-09  8:32                               ` Arnd Bergmann
2022-08-09 12:18                               ` Jason Gunthorpe
2022-08-09 12:18                                 ` Jason Gunthorpe
2022-08-09 12:46                                 ` Arnd Bergmann
2022-08-09 12:46                                   ` Arnd Bergmann
2022-08-09 14:22                                   ` Jason Gunthorpe
2022-08-09 14:22                                     ` Jason Gunthorpe
2022-08-09  8:45                             ` Greg Kroah-Hartman
2022-08-09  8:45                               ` Greg Kroah-Hartman
2022-08-08 17:46                   ` Jason Gunthorpe
2022-08-08 17:46                     ` Jason Gunthorpe
2022-08-08 20:26                     ` Oded Gabbay
2022-08-08 20:26                       ` Oded Gabbay
2022-08-09 12:43                       ` Jason Gunthorpe
2022-08-09 12:43                         ` Jason Gunthorpe
2022-08-05  3:02           ` Dave Airlie
2022-08-05  3:02             ` Dave Airlie
2022-08-07  6:50             ` Oded Gabbay
2022-08-07  6:50               ` Oded Gabbay
2022-08-09 21:42               ` Oded Gabbay
2022-08-09 21:42                 ` Oded Gabbay
2022-08-10  9:00                 ` Jiho Chu
2022-08-10  9:00                   ` Jiho Chu
2022-08-10 14:05                 ` yuji2.ishikawa
2022-08-10 14:05                   ` yuji2.ishikawa
2022-08-10 14:37                   ` Oded Gabbay
2022-08-10 14:37                     ` Oded Gabbay
2022-08-23 18:23                 ` Kevin Hilman
2022-08-23 18:23                   ` Kevin Hilman
2022-08-23 20:45                   ` Oded Gabbay
2022-08-23 20:45                     ` Oded Gabbay
2022-08-29 20:54                     ` Kevin Hilman
2022-08-29 20:54                       ` Kevin Hilman
2022-09-23 16:21                       ` Oded Gabbay
2022-09-23 16:21                         ` Oded Gabbay
2022-09-26  8:16                         ` Christoph Hellwig
2022-09-29  6:50                           ` Oded Gabbay
2022-09-29  6:50                             ` Oded Gabbay
2022-08-04 12:00         ` Tvrtko Ursulin
2022-08-04 15:03           ` Jeffrey Hugo
2022-08-04 17:53             ` Oded Gabbay
2022-08-04 17:53               ` Oded Gabbay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a3y2=FyzK4S6MRfZdrz=DdLat1ajdT_uPmN533mNYmF9w@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jgg@nvidia.com \
    --cc=jiho.chu@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oded.gabbay@gmail.com \
    --cc=yuji2.ishikawa@toshiba.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.