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]

Date:	Wed, 24 Jun 2009 02:55:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bzolnier@...il.com
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

From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Date: Wed, 24 Jun 2009 11:51:16 +0200

> You've put less than 2h (because that was the time since my post till your
> reply) into analysis of the bug, the related problems and the solution.
> 
> It could be that if you had put a bit more time into it and/or asked detailed
> technical questions related to the solution (i.e. "Why x needs to be there
> and we can't do y?") instead of keeping the technical discussion on the very
> vague level (which sounded like "can't we use block layer to process block
> requests because drive commands are block requests and raw commands are drive
> commands so we should use block layer") you would come to very different
> conclusions than you did initially.

I'm investigating alternative ways to this problem, less because
of the time I put into the investigation, but moreso because I'm
able to put fresh eyes onto the problem.

And also I don't know the IDE code as well as you do, which is
an advantage insofar as not falling into "oh I know how this
stuff works, therefore we can't..." kinds of mental traps.

Back to the technical side, ignoring the interrupt-or-not uglies,
there are two other reasons why using synchronization is better
here:

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?

   And as already discussed, we even already have logic to support
   this kind of thing for the sake of power-management.

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.

I know you're busy, so I'll try to draft something up myself.

Thanks.
--
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/