On 11/01/2023 22:19, Daniel Vetter wrote:
On Tue, Jan 10, 2023 at 01:14:51PM +, Tvrtko Ursulin wrote:
On 06/01/2023 18:00, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at
On Tue, Jan 10, 2023 at 01:14:51PM +, Tvrtko Ursulin wrote:
>
> On 06/01/2023 18:00, Daniel Vetter wrote:
> > On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
> > > Am 06.01.23 um 11:53 schrieb Daniel Vetter:
> > > > On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König
On 06/01/2023 18:00, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
Am 05.01.23 um 13:32 schrieb Daniel Vetter:
[SNIP]
For the case of an
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
> Am 06.01.23 um 11:53 schrieb Daniel Vetter:
> > On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
> > > Am 05.01.23 um 13:32 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > For the case of an master fd I actually
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
Am 05.01.23 um 13:32 schrieb Daniel Vetter:
[SNIP]
For the case of an master fd I actually don't see the reason why we should
limit that? And fd can become master if it either was
On 05/01/2023 12:32, Daniel Vetter wrote:
On Fri, Dec 02, 2022 at 10:01:01AM +0100, Christian König wrote:
Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With the
On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
> Am 05.01.23 um 13:32 schrieb Daniel Vetter:
> > [SNIP]
> > > For the case of an master fd I actually don't see the reason why we should
> > > limit that? And fd can become master if it either was master before or has
> > >
Am 05.01.23 um 13:32 schrieb Daniel Vetter:
[SNIP]
For the case of an master fd I actually don't see the reason why we should
limit that? And fd can become master if it either was master before or has
CAP_SYS_ADMIN. Why would we want an extra check for the pid/tgid here?
This is just
On Fri, Dec 02, 2022 at 10:01:01AM +0100, Christian König wrote:
> Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
> >
> > On 30/11/2022 14:18, Daniel Vetter wrote:
> > > On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > With the typical
Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With the typical model where the display server opends the file
descriptor
and then hands it over to the client we
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> With the typical model where the display server opends the file descriptor
> and then hands it over to the client we were showing stale data in
> debugfs.
>
> Fix it by updating the drm_file->pid on ioctl
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to
13 matches
Mail list logo
