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: <20090623.162256.190152758.davem@davemloft.net>
Date:	Tue, 23 Jun 2009 16:22:56 -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: Tue, 23 Jun 2009 23:29:11 +0200

> From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> Subject: [PATCH] ide: allow ide_dev_read_id() to be called from the IRQ context
> 
> * Un-static __ide_wait_stat().
> 
> * Allow ide_dev_read_id() helper to be called from the IRQ context by
>   adding irq_ctx flag and using mdelay()/__ide_wait_stat() when needed.
> 
> * Switch ide_driveid_update() to set irq_ctx flag.
> 
> This change is needed for the consecutive patch which fixes races in
> handling of user-space SET XFER commands but for improved bisectability
> and clarity it is better to do it in a separate patch.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> ---
> I'm not completely happy with this version of patch since I originally
> intended to unify ide_busy_sleep() with __ide_wait_stat() first..

This and patch #5 seems way overkill for the problem being solved.

All requests programmed into the device get synchronized through the
block request queue, even these raw taskfile commands.

It seems to me that it should be possible to use the block request
layer facilities to plug the queue, wait all executing commands to
complete and for the device to quiesce, then push this single RAW
command from the user to the device, and finally unplug the queue.

Alternatively, if the block request layer can't help, we can put a
mutex around submissions, and have this user RAW command submission
take that mutex.

Anything other than moving code that does significant delays into
interrupt context.
--
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/