All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ali Ahmet Memis <ali@iusegentoo.com>
To: Wilken Gottwalt <wilken.gottwalt@posteo.net>,
	Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (corsair-psu) serialize debugfs access against hwmon
Date: Tue,  4 Aug 2026 10:06:45 +0000	[thread overview]
Message-ID: <20260804100645.233305-1-ali@iusegentoo.com> (raw)
In-Reply-To: <20260804094753.230500-1-ali@iusegentoo.com>

> the next command's reinit_completion() re-arms the guard at the top of
> raw_event, and that stale reply is taken as the answer to the new command

Correcting myself on the mechanism, since it changes what a fix has to do.

reinit_completion() is not what defeats that guard. completion_done() is
just x->done != 0, and x->done is zero in every state between commands: a
successful wait_for_completion_timeout() decrements it back to zero, and a
timeout leaves it at zero because it was never set. So the check at the top
of raw_event practically never rejects anything, and reinit_completion() on
the next command writes zero over a value that is already zero.

The outcome I described is the same, a late reply still lands in cmd_buffer
and completes the next waiter with the previous command's data. But that
check is not a "command in flight" flag and cannot be turned into one by
moving it around, so whatever fixes this needs a way to tell which command a
reply actually belongs to.

  reply	other threads:[~2026-08-04 10:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 12:36 [PATCH] hwmon: (corsair-psu) serialize debugfs access against hwmon Ali Ahmet Memis
2026-08-02 12:48 ` sashiko-bot
2026-08-02 12:57 ` Wilken Gottwalt
2026-08-02 14:07   ` Guenter Roeck
2026-08-03 23:19   ` Guenter Roeck
2026-08-03 23:56     ` Ali Ahmet Memis
2026-08-04  2:54       ` Guenter Roeck
2026-08-04  4:11         ` Wilken Gottwalt
2026-08-04  9:47           ` Ali Ahmet Memis
2026-08-04 10:06             ` Ali Ahmet Memis [this message]
2026-08-04 16:34           ` Guenter Roeck
2026-08-04 17:53             ` Wilken Gottwalt
2026-08-04 18:37             ` Wilken Gottwalt
2026-08-04 20:14               ` Guenter Roeck
2026-08-06  5:23 ` Wilken Gottwalt
2026-08-06  9:23   ` Guenter Roeck
2026-08-06 12:19     ` Wilken Gottwalt
2026-08-06 14:10 ` Wilken Gottwalt
2026-08-06 14:21 ` [PATCH v2] " Ali Ahmet Memis
2026-08-06 14:35   ` sashiko-bot
2026-08-06 15:41   ` Guenter Roeck

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=20260804100645.233305-1-ali@iusegentoo.com \
    --to=ali@iusegentoo.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=wilken.gottwalt@posteo.net \
    /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.