linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Ian Pilcher <arequipeno@gmail.com>,
	axboe@kernel.dk, pavel@ucw.cz, linux-leds@vger.kernel.org,
	linux-block@vger.kernel.org, kabel@kernel.org
Subject: Re: [PATCH 09/18] ledtrig-blkdev: Periodically check devices for activity & blink LEDs
Date: Sun, 5 Sep 2021 09:55:13 -0700	[thread overview]
Message-ID: <YTT2cbhFkxtWw0mO@sol.localdomain> (raw)
In-Reply-To: <YTTeZ1kSQMRZNpz7@kroah.com>

On Sun, Sep 05, 2021 at 05:12:39PM +0200, Greg KH wrote:
> On Sun, Sep 05, 2021 at 09:56:58AM -0500, Ian Pilcher wrote:
> > On 9/5/21 9:51 AM, Greg KH wrote:
> > > On Sun, Sep 05, 2021 at 09:39:57AM -0500, Ian Pilcher wrote:
> > > > On 9/4/21 1:01 AM, Greg KH wrote:
> > > > > Please never use WARN_ON() in new code unless the machine is really
> > > > > broken and you can not do anything else here.
> > > > 
> > > > Wait what?  I thought that was BUG_ON.
> > > 
> > > Not whan panic-on-warn is set, which is getting more and more common
> > > these days.
> > 
> > Fair enough.  What is the recommend approach to reporting a "this should
> > never" happen situation these days?
> 
> dev_err() and handle the error properly.
> 
> 

WARN_ON is the right choice for reporting recoverable kernel bugs, and BUG_ON
for unrecoverable ones; see the two comments in include/asm-generic/bug.h which
explain this.  Please don't use dev_err() if it's a kernel bug (and not just
unexpected input from userspace or hardware behaving weirdly), as that prevents
the bug from being reported if it occurs.

Greg, you've been corrected on this before, e.g.
https://lore.kernel.org/linux-fsdevel/20210707023548.15872-1-desmondcheongzx@gmail.com/T/#u.
Please stop spreading false information as it is destroying your credibility :-(

- Eric

  reply	other threads:[~2021-09-05 16:55 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 20:45 [PATCH 00/18] Introduce block device LED trigger Ian Pilcher
2021-09-03 20:45 ` [PATCH 01/18] docs: Add block device (blkdev) LED trigger documentation Ian Pilcher
2021-09-04  6:29   ` Pavel Machek
2021-09-05 14:49     ` Ian Pilcher
2021-09-05 18:42       ` Pavel Machek
2021-09-05 23:13         ` Ian Pilcher
2021-09-03 20:45 ` [PATCH 02/18] ledtrig-blkdev: Add build infra for block device LED trigger Ian Pilcher
2021-09-03 20:45 ` [PATCH 03/18] ledtrig-blkdev: Add function placeholders needed by block changes Ian Pilcher
2021-09-04 16:57   ` kernel test robot
2021-09-03 20:45 ` [PATCH 04/18] block: Add block device LED trigger integrations Ian Pilcher
2021-09-03 20:45 ` [PATCH 05/18] ledtrig-blkdev: Implement functions called from block subsystem Ian Pilcher
2021-09-03 20:45 ` [PATCH 06/18] ledtrig-blkdev: Add function to get gendisk by name Ian Pilcher
2021-09-03 20:45 ` [PATCH 07/18] ledtrig-blkdev: Add constants, data types, and global variables Ian Pilcher
2021-09-03 20:45 ` [PATCH 08/18] ledtrig-blkdev: Add miscellaneous helper functions Ian Pilcher
2021-09-04  6:00   ` Greg KH
2021-09-04 22:43     ` Ian Pilcher
2021-09-03 20:45 ` [PATCH 09/18] ledtrig-blkdev: Periodically check devices for activity & blink LEDs Ian Pilcher
2021-09-04  6:01   ` Greg KH
2021-09-05 14:39     ` Ian Pilcher
2021-09-05 14:51       ` Greg KH
2021-09-05 14:56         ` Ian Pilcher
2021-09-05 15:12           ` Greg KH
2021-09-05 16:55             ` Eric Biggers [this message]
2021-09-03 20:45 ` [PATCH 10/18] ledtrig-blkdev: Add function to associate the trigger with an LED Ian Pilcher
2021-09-03 20:45 ` [PATCH 11/18] ledtrig-blkdev: Add function to associate a device " Ian Pilcher
2021-09-03 20:45 ` [PATCH 12/18] ledtrig-blkdev: Add function to remove LED/device association Ian Pilcher
2021-09-03 20:45 ` [PATCH 13/18] ledtrig-blkdev: Add function to disassociate a device from all LEDs Ian Pilcher
2021-09-03 20:45 ` [PATCH 14/18] ledtrig-blkdev: Add function to disassociate an LED from the trigger Ian Pilcher
2021-09-03 20:45 ` [PATCH 15/18] ledtrig-blkdev: Add sysfs attributes to [un]link LEDs & devices Ian Pilcher
2021-09-04  5:57   ` Greg KH
2021-09-04 21:28     ` Ian Pilcher
2021-09-04  5:59   ` Greg KH
2021-09-04 22:35     ` Ian Pilcher
2021-09-05 14:51       ` Greg KH
2021-09-05 15:33         ` Ian Pilcher
2021-09-05 16:43           ` Greg KH
2021-09-03 20:45 ` [PATCH 16/18] ledtrig-blkdev: Add blink_time & interval sysfs attributes Ian Pilcher
2021-09-03 20:45 ` [PATCH 17/18] ledtrig-blkdev: Add mode (read/write/rw) sysfs attributue Ian Pilcher
2021-09-04  5:57   ` Greg KH
2021-09-04 21:01     ` Ian Pilcher
2021-09-05 14:50       ` Greg KH
2021-09-03 20:45 ` [PATCH 18/18] ledtrig-blkdev: Add initialization & exit functions Ian Pilcher
2021-09-04  6:35 ` [PATCH 00/18] Introduce block device LED trigger Pavel Machek

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=YTT2cbhFkxtWw0mO@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=arequipeno@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=kabel@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).