mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Vasily Averin <vvs@sw.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devel@openvz.org, Markus Lidel <Markus.Lidel@shadowconnect.com>
Subject: Re: [patch i2o 5/6] i2o_proc files permission
Date: Wed, 16 May 2007 13:52:45 +0100	[thread overview]
Message-ID: <20070516135245.45b4b2db@the-village.bc.nu> (raw)
In-Reply-To: <464A8F7D.2090409@sw.ru>

> We have i2o on one of our testnodes: Adaptec Zero channel RAID 2010S integrated
> on MSI MS-9136 motherboard and I don't have access to another i2o hardware.
> Also I don't have any ideas how to detect buggy i2o node. As far as I understand
> Markus is right, and i2o hardware couldn't handle received message that on the
> first glance looks correctly.
> >From my POV it is bug in firmware and only vendor is able to fix it correctly.
> My patch is not a fix but workaround only -- it just do not allow to crash the
> node by any user in case when node admin due some reasons has loaded i2o_proc
> module.

It merely allows it to occur by accident if root does something like find
in the wrong place and it also breaks the expected behaviour for existing
systems.

There are two ways you can identify a specific controller if the vendor
didn't totally screw up

The first is the PCI idents or subidents, the second is to look at the
tables returned when the controller is being set up. In fact the
Adaptecrap controllers (ex DPT) are already detected and we set
c->adaptec in pci.c so we can stop them exploding for other reasons and
to use some extensions they have.

Thus I think the right solution is to skip registering those proc files
(and unregistering them on unload) if c->adaptec is set.

  reply	other threads:[~2007-05-16 12:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-15 12:41 [patch i2o] i2o layer cleanup Vasily Averin
2007-05-15 12:42 ` [patch i2o 1/6] i2o_cfg_passthru cleanup Vasily Averin
2007-05-15 16:42   ` Alan Cox
2007-05-15 12:43 ` [patch i2o 2/6] wrong memory access in i2o_block_device_lock() Vasily Averin
2007-05-15 12:44 ` [patch i2o 3/6] i2o message leak in i2o_msg_post_wait_mem() Vasily Averin
2007-05-15 12:45 ` [patch i2o 4/6] i2o proc reading oops Vasily Averin
2007-05-15 12:47 ` [patch i2o 5/6] i2o_proc files permission Vasily Averin
2007-05-15 12:59   ` [Devel] " Vasily Averin
2007-05-16  9:27     ` Greg KH
2007-05-15 16:45   ` Alan Cox
2007-05-16  4:58     ` Vasily Averin
2007-05-16 12:52       ` Alan Cox [this message]
2007-05-15 12:48 ` [patch i2o 6/6] i2o debug output cleanup Vasily Averin
2007-05-15 16:46   ` Alan Cox
2007-05-15 12:53 ` [Devel] [patch i2o] i2o layer cleanup Kirill Korotaev

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=20070516135245.45b4b2db@the-village.bc.nu \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=Markus.Lidel@shadowconnect.com \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vvs@sw.ru \
    /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

all inboxes | Powered by JetHome®