From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Rui Nuno Capela <rncbc@rncbc.org>
Subject: Re: [patch] drivers/ide/pci/alim15x3.c SMP fix
Date: Thu, 01 Sep 2005 11:42:15 +0100 [thread overview]
Message-ID: <1125571335.15768.21.camel@localhost.localdomain> (raw)
In-Reply-To: <20050901072430.GA6213@elte.hu>
On Iau, 2005-09-01 at 09:24 +0200, Ingo Molnar wrote:
> is this the right way to fix the UP assumption below?
Probably not. The ide_lock may already be held (randomly depending on
the code path) at the point we retune a drive on error. Actually you
probably crash before this anyway.
The ALi code in question was written knowing the system would be
uniprocessor and making various related assumptions. You also have to
get this locking right just to make it more fun - loading the timings
for one channel while another is doing I/O corrupts your data silently
in some cases. Fixing the ide_lock to be consistent in usage when the
tuning calls are made (ie fix the reset path and other offenders) might
be possible and would make using ide_lock ok, but it would still be
wrong with pre-emption and/or SMP.
There is currently no sane locking mechanism to enforce or implement
this in the IDE layer. Welcome to hell, please leave your brain at the
door.
Alan
next prev parent reply other threads:[~2005-09-01 10:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-01 7:24 [patch] drivers/ide/pci/alim15x3.c SMP fix Ingo Molnar
2005-09-01 8:13 ` Rui Nuno Capela
2005-09-01 8:17 ` Ingo Molnar
2005-09-01 8:51 ` Rui Nuno Capela
2005-09-01 10:42 ` Alan Cox [this message]
2005-10-03 6:50 ` Ingo Molnar
2005-10-03 16:24 ` Alan Cox
2005-10-04 9:29 ` tsc_c3_compensate undefined since patch-2.6.13-rt13 Rui Nuno Capela
2005-10-04 10:14 ` Ingo Molnar
2005-10-04 13:07 ` Rui Nuno Capela
2005-10-16 22:43 ` Rui Nuno Capela
2005-10-17 12:48 ` Ingo Molnar
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=1125571335.15768.21.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rncbc@rncbc.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