linux-kernel - Re: [PATCH] libata-sff: Don't call bmdma

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: <20070125172739.0c990a9a@localhost.localdomain>
Date:	Thu, 25 Jan 2007 17:27:39 +0000
From:	Alan <alan@...rguk.ukuu.org.uk>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	jgarzik@...ox.com, torvalds@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable
 controllers

> >  void ata_bmdma_post_internal_cmd(struct ata_queued_cmd *qc)
> >  {
> > -       ata_bmdma_stop(qc);
> > +       if (qc->ap->ioaddr.bmdma_addr)
> > +               ata_bmdma_stop(qc);
> >  }
> 
> But what if the bmdma_addr _is_ zero? Please, let's not allow the "zero
> is not a valid number" braindamage to spread any further than the IRQ
> setup it's already broken.

The fix matches the rest of libata on this and fixes a bug that wants
fixing urgently for 2.6.20.

If you want to put your bmdma address at zero then libata-sff won't help
you at the moment, and assumes zero is a safe "not in use" value because
the PCI layer also takes a similar view in places.

libata-sff and thus ata_bmdma_post_internal_cmd() aren't used by non PCI
devices so the bmdma test is ok providing it stays within libata-sff. I
don't think its a problem, although clearly its an assumption that the
core code rather than the SFF code cannot make.

drivers/ide uses roughly the same assumptions without problem.

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