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
| ||
|
Date: Fri, 12 Sep 2008 13:55:17 +0200 From: Elias Oltmanns <eo@...ensachen.de> To: Bartlomiej Zolnierkiewicz <bzolnier@...il.com> Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Jeff Garzik <jeff@...zik.org>, Randy Dunlap <randy.dunlap@...cle.com>, Tejun Heo <htejun@...il.com>, linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 3/4] ide: Implement disk shock protection support Elias Oltmanns <eo@...ensachen.de> wrote: > Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote: [...] >> Since Tejun already raised concerns about multiplexing per-device >> and per-port settings I'm not repeating them here. Please just >> remember to backport fixes from libata version to ide one. > > For the sake of consistency, I've always tried to make ide and libata > behave alike (or as close to it as possible). However, the final version > of the libata patch is very hard to mimc in ide. Therefore, I wonder > whether we can do in ide what we'd really like to do in libata > eventually. The patch below is a real per-device implementation of the > unload feature. However, I'd like you to confirm the crucial assumption > underlying this patch: a port reset is the only way a device can > interfere with another device on the same port. In particular, I haven't > made an effort to understand pnp and similar stuff completely, but from > a first glance I got the impression that these things are done per-port > rather than per-device and that nothing sinister will happen behind our > back. In short, can you confirm the following: > > Condition: device A on a port is parked (implies there is at least one > request on the queue of that device, i.e we hold a > reference to the device and thus to the port). > Assumption: nothing will disturb the device because resets due to > command failure / timeouts on device B are deferred (see my > patch) and spurious commands like IDENTIFY (or whatever > actions may be related to pnp and the like) are not > performed while the device is sleeping and a request is > waiting on the queue. Sorry for spamming you again, but I forgot to mention one more thing: In my hardware environment, I cannot easily test the code in do_reset1() which is supposed to defer resets if necessary. Since we have something very similar in libata (which I have tested), I'm quite confident that everything will work out nicely. Still, you may want to pay special attention to this piece of code. Regards, Elias -- 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/
Powered by blists - more mailing lists