All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bryam Vargas <hexlabsecurity@proton.me>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, Linus Walleij <linusw@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] Input: mms114 - replace BUG() and fix alignment
Date: Tue, 16 Jun 2026 07:21:37 +0000	[thread overview]
Message-ID: <20260616072133.158968-1-hexlabsecurity@proton.me> (raw)
In-Reply-To: <20260616050912.1531241-5-dmitry.torokhov@gmail.com>

Hi Dmitry,

Replacing BUG() with WARN_ON() + return is the right call, and the rest of
the patch is fine.

One nit on the changelog though: this guard isn't reachable from userspace.
reg and len are always driver-internal constants -- there is no sysfs/debugfs/
ioctl that lets userspace pick a register, every __mms114_read_reg() call site
passes a fixed reg >= MMS114_INFORMATION (0x10), and the single MMS114_MODE_CONTROL
read is short-circuited by the cache in mms114_read_reg() before it ever reaches
__mms114_read_reg(). So the condition only fires if a *future in-kernel caller*
requests a read that spans the write-only MODE_CONTROL register -- a driver-
internal invariant, not a userspace-triggered one.

Worth tightening the wording, since that distinction is exactly what justifies
WARN_ON() here: a genuinely userspace-reachable WARN_ON() would itself be a
problem (log spam / panic_on_warn). Maybe something like:

  "Avoid taking the machine down with BUG() if a caller ever requests a read
   spanning the write-only MODE_CONTROL register; warn and return -EINVAL so
   the driver can recover."

The code is good either way.

Thanks,
Bryam


  parent reply	other threads:[~2026-06-16  7:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  5:09 [PATCH 1/6] Input: mms114 - fix touch indexing for MMS134S and MMS136 Dmitry Torokhov
2026-06-16  5:09 ` [PATCH 2/6] Input: mms114 - prefer GPL over GPL v2 for module license Dmitry Torokhov
2026-06-16 11:38   ` Linus Walleij
2026-06-16  5:09 ` [PATCH 3/6] Input: mms114 - use appropriate register argument types Dmitry Torokhov
2026-06-16  5:20   ` sashiko-bot
2026-06-16  5:09 ` [PATCH 4/6] Input: mms114 - replace udelay with usleep_range Dmitry Torokhov
2026-06-16  5:20   ` sashiko-bot
2026-06-16  5:09 ` [PATCH 5/6] Input: mms114 - replace BUG() and fix alignment Dmitry Torokhov
2026-06-16  5:27   ` sashiko-bot
2026-06-16  7:21   ` Bryam Vargas [this message]
2026-06-16  5:09 ` [PATCH 6/6] Input: mms114 - refactor chip variant handling using descriptors Dmitry Torokhov
2026-06-16  5:20   ` sashiko-bot
2026-06-16  7:42   ` Bryam Vargas
2026-06-16  5:20 ` [PATCH 1/6] Input: mms114 - fix touch indexing for MMS134S and MMS136 sashiko-bot
2026-06-16  7:05 ` Bryam Vargas

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=20260616072133.158968-1-hexlabsecurity@proton.me \
    --to=hexlabsecurity@proton.me \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linusw@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.