On Fri, 03. May 14:08, Dmitry Antipov wrote:
> On 5/3/24 11:18 AM, Christian König wrote:
>
> > Attached is a compile only tested patch, please verify if it fixes your
> > problem.
>
> LGTM, and this is similar to get_file() in __pollwait() and fput() in
> free_poll_entry() used in implementatio
On Fri, May 3, 2024 at 11:36 PM Douglas Anderson wrote:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someon
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these function
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> It's the responsibility of a correctly written DRM modeset driver to
> call drm_atomic_helper_shutdown() at shutdown time and that should be
> disabling / unpreparing the panel if needed. Panel drivers shouldn't
> be calling these function
On Fri, May 3, 2024 at 11:38 PM Douglas Anderson wrote:
> As talked about in commit d2aacaf07395 ("drm/panel: Check for already
> prepared/enabled in drm_panel"), we want to remove needless code from
> panel drivers that was storing and double-checking the
> prepared/enabled state. Even if someon
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. We'll use the
> same concepts as the recently introduced
> mipi_dsi_generic_write_seq_multi() to make this clean/e
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note: Class-ba
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> The current mipi_dsi_*_write_seq() macros are non-intutitive because
> they contain a hidden "return" statement that will return out of the
> _caller_ of the macro. Let's mark them as deprecated and instead
> introduce some new macros that
On Mon, Apr 29, 2024 at 4:26 PM Doug Anderson wrote:
> So I guess I'd say that I ended up being pretty happy with the
> "context" even if it does feel a little over engineered and I'd argue
> to keep it that way. That being said, if you feel strongly about it
> then we can perhaps get others to c
On Wed, May 1, 2024 at 5:43 PM Douglas Anderson wrote:
> Consensus on the mailing lists is that panels shouldn't use a table of
> init commands but should instead use init functions. With the recently
> introduced mipi_dsi_dcs_write_seq_multi() this is not only clean/easy
> but also saves space.
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 pane
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 i
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
> in
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 requirement
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 inst
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 vi
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 L
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: sol
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 returns,
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 us
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 "Not-yet-signed-off-
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) prac
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 no
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
inconsistent
> > /* 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 of
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 ea
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 ep_item
30 matches
Mail list logo
