linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-ide@vger.kernel.org
Subject: Current qc_defer implementation may lead to infinite recursion
Date: Sun, 10 Feb 2008 18:54:19 +0100	[thread overview]
Message-ID: <87ir0w4rzo.fsf@denkblock.local> (raw)

Hi Tejun,

due to your commit 31cc23b34913bc173680bdc87af79e551bf8cc0d libata now
sets max_host_blocked and max_device_blocked to 1 for all devices it
manages. Under certain conditions this may lead to system lockups due to
infinite recursion as I have explained to James on the scsi list (kept
you cc-ed). James told me that it was the business of libata to make
sure that such a recursion cannot happen.

In my discussion with James I imprudently claimed that this was easy to
fix in libata. However, after giving the matter some thought, I'm not at
all sure as to what exactly should be done about it. The easy bit is
that max_host_blocked and max_device_blocked should be left alone as
long as the low level driver does not provide the ->qc_defer() callback.
But even if the driver has defined this callback, ata_std_qc_defer() for
one will not prevent this recursion on a uniprocessor, whereas things
might work out well on an SMP system due to the lock fiddling in the
scsi midlayer.

As a conclusion, the current implementation makes it imperative to leave
max_host_blocked and max_device_blocked alone on a uniprocessor system.
For SMP systems the current implementation might just be fine but even
there it might just as well be a good idea to make the adjustment
depending on ->qc_defer != NULL.

Any ideas?

Regards,

Elias

             reply	other threads:[~2008-02-10 18:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10 17:54 Elias Oltmanns [this message]
2008-02-11  5:06 ` Current qc_defer implementation may lead to infinite recursion Tejun Heo
2008-02-11  7:57   ` Elias Oltmanns
2008-02-11  8:43     ` Tejun Heo
2008-02-11 22:03       ` Elias Oltmanns
2008-02-12  1:14         ` Tejun Heo
2008-02-12  8:57           ` Elias Oltmanns
2008-02-12  9:05             ` Tejun Heo
2008-02-12  9:43               ` Elias Oltmanns
2008-02-12 12:56                 ` Tejun Heo
2008-02-18 20:03                   ` Elias Oltmanns
2008-04-12  8:02                   ` Elias Oltmanns

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=87ir0w4rzo.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=htejun@gmail.com \
    --cc=linux-ide@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 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).