Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_device.h
between commit:
c01c6066e6fa ("drm/xe/device: implement transient flush")
from the drm-intel tree and commits:
fb74b205cdd2 ("drm/xe: Introduce a simple wedged state")
8ed9aaae39f3
On 03/05/2024 22:59, Dmitry Baryshkov wrote:
On Fri, May 03, 2024 at 11:18:52AM +0200, Luca Weiss wrote:
On Sun Apr 7, 2024 at 5:15 AM CEST, Dmitry Baryshkov wrote:
On Sat, 30 Mar 2024 at 18:49, Marijn Suijten
wrote:
On 2024-03-30 05:52:29, Dmitry Baryshkov wrote:
In case of CMD DSI
On 2024-05-01 00:55, Christoph Hellwig wrote:
> On Fri, Apr 26, 2024 at 05:17:52PM -0700, David Wei wrote:
>> On 2024-04-02 5:20 pm, Mina Almasry wrote:
>>> @@ -69,20 +106,26 @@ net_iov_binding(const struct net_iov *niov)
>>> */
>>> typedef unsigned long __bitwise netmem_ref;
>>>
>>> +static
On Sun, 5 May 2024 at 13:30, Al Viro wrote:
>
> 0. special-cased ->f_count rule for ->poll() is a wart and it's
> better to get rid of it.
>
> 1. fs/eventpoll.c is a steaming pile of shit and I'd be glad to see
> git rm taken to it. Short of that, by all means, let's grab reference
>
On Sun, May 05, 2024 at 01:03:07PM -0700, Linus Torvalds wrote:
> On Sun, 5 May 2024 at 12:46, Al Viro wrote:
> >
> > I've no problem with having epoll grab a reference, but if we make that
> > a universal requirement ->poll() instances can rely upon,
>
> Al, we're note "making that a
On Sun, 5 May 2024 at 13:02, David Laight wrote:
>
> How much is the extra pair of atomics going to hurt performance?
> IIRC a lot of work was done to (try to) make epoll lockless.
If this makes people walk away from epoll, that would be absolutely
*lovely*. Maybe they'd start using io_uring
On Sun, May 05, 2024 at 09:46:05AM -0700, Linus Torvalds wrote:
> WHY?
>
> Why cannot you and Al just admit that the problem is in epoll. Always
> has been, always will be.
Nobody (well, nobody who'd ever read epoll) argues that epoll is not
a problem.
> The fact is, it's not dma-buf that is
From: Linus Torvalds
> Sent: 05 May 2024 18:56
>
> epoll can call out to vfs_poll() with a file pointer that may race with
> the last 'fput()'. That would make f_count go down to zero, and while
> the ep->mtx locking means that the resulting file pointer tear-down will
> be blocked until the poll
On Sun, 5 May 2024 at 12:46, Al Viro wrote:
>
> I've no problem with having epoll grab a reference, but if we make that
> a universal requirement ->poll() instances can rely upon,
Al, we're note "making that a requirement".
It always has been.
Otgherwise, the docs should have shouted out DAMN
On Sat, May 04, 2024 at 08:53:47AM -0700, Linus Torvalds wrote:
> poll_wait
> -> __pollwait
> -> get_file (*boom*)
>
> but the boom is very small because the poll_wait() will be undone by
> poll_freewait(), and normally poll/select has held the file count
> elevated.
Not quite. It's
On Wed, Apr 24, 2024 at 04:14:07PM -0700, Alexey Makhalov wrote:
> +#define VMWARE_CMD_GETVERSION10
> +#define VMWARE_CMD_GETHZ 45
> +#define VMWARE_CMD_GETVCPU_INFO 68
> +#define VMWARE_CMD_STEALCLOCK91
Ok, what part in
"* first patch:
On 5/5/24 11:55 AM, Linus Torvalds wrote:
> epoll can call out to vfs_poll() with a file pointer that may race with
> the last 'fput()'. That would make f_count go down to zero, and while
> the ep->mtx locking means that the resulting file pointer tear-down will
> be blocked until the poll
epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep->mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any
On 5/3/24 3:11 PM, Linus Torvalds wrote:
> epoll is a mess, and does various invalid things in the name of
> performance.
>
> Let's try to rein it in a bit. Something like this, perhaps?
>
> Not-yet-signed-off-by: Linus Torvalds
> ---
>
> This is entirely untested, thus the
On Sun, 5 May 2024 at 03:50, Christian Brauner wrote:
>
> And I agree with you that for some instances it's valid to take another
> reference to a file from f_op->poll() but then they need to use
> get_file_active() imho and simply handle the case where f_count is zero.
I think this is
(a)
Thanks T.J for the reply!!
On 5/4/2024 4:43 AM, T.J. Mercier wrote:
> It looks like a similar conclusion about epoll was reached at:
> https://lore.kernel.org/all/a87d7ef8-2c59-4dc5-ba0a-b821d1eff...@amd.com/
>
I am unaware of this discussion. Thanks...
> I agree with Christian that it should
Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
> > /* wait the flip take affect.*/
> > - timeout = wait_for_completion_timeout(flip_done, HZ);
> > - if (timeout == 0) {
> > + time_left = wait_for_completion_timeout(flip_done, HZ);
> > + if (time_left == 0) {
>
> Honestly, if the name of the variable is confusing I would get rid
On Fri, May 03, 2024 at 10:04:16AM -0300, Jason Gunthorpe wrote:
> On Fri, May 03, 2024 at 01:18:35PM +0300, Ilpo Järvinen wrote:
> > On Thu, 15 Feb 2024, Ilpo Järvinen wrote:
> >
> > > Convert open coded RMW accesses for LNKCTL2 to use
> > > pcie_capability_clear_and_set_word() which makes its
On Sat, May 04, 2024 at 08:40:25AM -0700, Linus Torvalds wrote:
> On Sat, 4 May 2024 at 08:32, Linus Torvalds
> wrote:
> >
> > Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> > file closing completes, eventpoll_release() finishes [..]
>
> Actually, Al is right that
20 matches
Mail list logo
