All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Shyam Iyer <Shyam_Iyer@Dell.com>,
	ddutile@redhat.com
Subject: Re: [PATCH] pci, Add AER_panic sysfs file
Date: Fri, 18 May 2012 13:17:54 -0400	[thread overview]
Message-ID: <4FB68442.1010506@redhat.com> (raw)
In-Reply-To: <20120518154715.GA21043@kroah.com>


> 
> Please define "unhardened".  Why aren't all drivers "hardened"?

Most drivers _currently_ do not handle reading all f's (or -1) from hardware.
Some drivers do handle some situations but definitely not all of them.
Hardening a driver involves making the driver "-1" safe.

Some companies do ship hardened drivers, but the ones in the tree are not hardened.

[The above comment is in no way an approval of shipping drivers outside of the
kernel.  I'm just stating a fact.]

The effort involved in hardening this drivers is significant.  It will be a long
time before anyone considers the in-tree drivers hardened.  We should start with
a baby-step of acknowledging the problem and giving current users a way of
protecting their data.

> 
>> In these cases, the system should not do a bus reset, but rather the
>> system should panic to avoid any further possible data corruption.
> 
> Really?  You really want to panic the whole system and shut down and
> potentially loose everything?  That does not sound like a good idea at
> all to me, is there really no way to recover from this?

Yes, that's _exactly_ what I want to do.  Having a driver that is capable of
writing corrupted data to a disk or corrupting memory is much worse than
panicking and stopping the system for a short period of time.

The default is to handle an AER through a bus reset so a user must actively
request the panic.

P.

  reply	other threads:[~2012-05-18 17:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17 17:04 [PATCH] pci, Add AER_panic sysfs file Prarit Bhargava
2012-05-17 17:29 ` Shyam_Iyer
2012-05-17 17:39   ` Prarit Bhargava
2012-05-17 17:51     ` Shyam_Iyer
     [not found]     ` <DBFB1B45AF80394ABD1C807E9F28D15707BC712175@BLRX7MCDC203.AMER.DELL.COM>
2012-05-17 18:00       ` Shyam_Iyer
2012-05-17 18:51 ` Don Dutile
2012-05-17 18:54   ` Prarit Bhargava
2012-05-17 19:11     ` Don Dutile
2012-05-17 22:16       ` Prarit Bhargava
2012-05-17 21:32 ` Betty Dall
2012-05-18  4:51 ` Greg KH
2012-05-18 10:26   ` Prarit Bhargava
2012-05-18 14:16   ` Prarit Bhargava
2012-05-18 15:47     ` Greg KH
2012-05-18 17:17       ` Prarit Bhargava [this message]
2012-05-18 18:13         ` Greg KH
2012-05-18 19:28           ` Prarit Bhargava
2012-05-18 23:19             ` Greg KH
2012-05-18 17:26       ` Prarit Bhargava

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=4FB68442.1010506@redhat.com \
    --to=prarit@redhat.com \
    --cc=Shyam_Iyer@Dell.com \
    --cc=bhelgaas@google.com \
    --cc=ddutile@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-pci@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.