On Fri, Apr 16, 2021 at 05:30:41PM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:58:15PM +0200, Christian Brauner wrote:
>
> > They could probably refactor this but I'm not sure why they'd bother. If
> > they fail processing any of those files they end up aborting the
> > whole transaction.
>
On Fri, Apr 16, 2021 at 05:58:15PM +0200, Christian Brauner wrote:
> They could probably refactor this but I'm not sure why they'd bother. If
> they fail processing any of those files they end up aborting the
> whole transaction.
> (And the original code didn't check the error code btw.)
Wait a s
On Fri, Apr 16, 2021 at 06:00:38PM +0200, Christian Brauner wrote:
> (dma_buf_fd() seems like another good candidate. But again, I don't have
> any plans to shove this down anyone's throat.)
Sure, there are candidates for such a helper. Just as there are legitimate
users of anon_inode_getfd().
On Fri, Apr 16, 2021 at 05:58:25PM +0200, Christian Brauner wrote:
> On Fri, Apr 16, 2021 at 03:35:59PM +, Al Viro wrote:
> > On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
> >
> > > My point here was more that the _file_ has already been opened _before_
> > > that call to
On Fri, Apr 16, 2021 at 03:35:59PM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
>
> > My point here was more that the _file_ has already been opened _before_
> > that call to io_uring_add_task_file(). But any potential non-trivial
> > side-effects of o
On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
> My point here was more that the _file_ has already been opened _before_
> that call to io_uring_add_task_file(). But any potential non-trivial
> side-effects of opening that file that you correctly pointed out in an
> earlier mai
Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
> Le 16/04/2021 à 12:54, Lucas Stach a écrit :
> > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > > In order to be able to share the control hardware block between
> > > VPUs use a syscon instead a iorem
On Fri, Apr 16, 2021 at 02:09:35PM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 03:42:52PM +0200, Christian Brauner wrote:
> > > > are drivers/dma-buf/sw_sync.c and drivers/dma-buf/sync_file.c, etc.
> > >
> > > FWIW, pretty much all ioctls that return descriptor as part of a structure
> > > sto
On Fri, Apr 16, 2021 at 03:42:52PM +0200, Christian Brauner wrote:
> > > are drivers/dma-buf/sw_sync.c and drivers/dma-buf/sync_file.c, etc.
> >
> > FWIW, pretty much all ioctls that return descriptor as part of a structure
> > stored to user-supplied address tend to be that way; some don't have a
On Fri, Apr 16, 2021 at 05:55:16AM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:19:50AM +, Al Viro wrote:
> > On Thu, Apr 01, 2021 at 12:40:34PM +0200, Christian Brauner wrote:
>
> > > and see whether all of them can be switched to simply using
> > > receive_fd(). I did a completely unte
Le 16/04/2021 à 12:54, Lucas Stach a écrit :
Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
In order to be able to share the control hardware block between
VPUs use a syscon instead a ioremap it in the driver.
To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctr
Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> In order to be able to share the control hardware block between
> VPUs use a syscon instead a ioremap it in the driver.
> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
> phandle is not found look at 'ctrl' re
12 matches
Mail list logo
