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: <200906241151.16506.bzolnier@gmail.com>
Date:	Wed, 24 Jun 2009 11:51:16 +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 06:35:35 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> Date: Wed, 24 Jun 2009 03:36:24 +0200
> 
> > IOW if there are really some technical issues left to be addressed with
> > these patches I'll be happy to address them but I'm not doing any more
> > new IDE stuff.
> 
> Discussing alternative approaches to fixing the problem is a technical
> issue.
> 
> If you just want to dump your pending fixes and have no interest in
> anything other than minor fixups and typo cures, then it's likely most
> of these patches will be used only as guides for others rather than
> being applied.

I'm perfectly happy with it.

> Specifically in this case I really think this is a very unclean way to
> solve this problem, which is why I suggested alternative
> implementations in the first place.
> 
> Anything that requires a set of if() blocks checking "in interrupt
> context" or not is a big red flag in my book.

It is also a big red flag in my book.  However after long hours put into
analysis of the issue I came to conclusions that they are needed/justified
in this specific case unless we are going to do really major surgery there
(which we shouldn't according to the new policy).

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