linux-kernel - Re: [patch 4/6] ide: allow ide_dev_read_id() to be called from the IRQ context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200906241505.52899.bzolnier@gmail.com>
Date:	Wed, 24 Jun 2009 15:05:52 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 4/6] ide: allow ide_dev_read_id() to be called from the IRQ context

On Wednesday 24 June 2009 13:04:14 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 24 June 2009 12:48:20 Bartlomiej Zolnierkiewicz wrote:
> 
> > > 1) You want the device to be quiescent anyways when you do this
> > >    SET_XFER command.  What better way than to plug the queue
> > >    and make sure all currently outstanding requests complete?

BTW this is the way we do it currently.

We just back-ride on ide_finish_cmd() call for the special user-initiated
REQ_TYPE_ATA_TASKFILE request.  Doing it the other way will only result in:

* shorter IRQ latency for user-space requested xfer mode change request
  (irrelevant as the whole interface is just a rarely used legacy)

* much more invasive changes to the IDE core (I would be more than happy
  to welcome them but this is against our newly established policy)

Anyway I'll be happy with whatever solution that will end up in Linus tree
and is OK from the correctness POV.

> > >    And as already discussed, we even already have logic to support
> > >    this kind of thing for the sake of power-management.
> > 
> > Power management requests are kind of special and need block layer support.
> > 
> > Please take a look at REQ_DEVSET_EXEC special requests from ide-devsets.c
> > instead if you would like to investigate possibility of a cleaner (although
> > more invasive) solution.
> > 
> > > 2) All commands going into the device do so from a context from
> > >    which we could take a sleeping lock such as a mutex.  It's
> > >    therefore the most natural way to synchonize things.
> > 
> > The fact is that we need to synchronize against all commands going into
> > the device and they are synchronized using block queue (which is protected
> > with spinlock by block layer). Adding an extra mutex (even if possible)
> 
> We need to also take the synchronization between block queues of all devices
> on the port and the serialized ports into account..  This is quite complex
> and fragile code (vide cmd64x screaming IRQ issue ;)..
> 
> I would personally try going with 1) and avoid 2) at all costs..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/