USB mass storage and ARM cache coherency
in [Kernel]
|
Prev: [PATCH 0/3] HID: make raw output callback more flexible
Next: kprobes: Disable booster when CONFIG_PREEMPT=y
From: Benjamin Herrenschmidt on 24 Feb 2010 16:20 On Wed, 2010-02-24 at 08:16 +0100, Oliver Neukum wrote: > I don't know. The issue seems quite complex. It would seem better to > centralize it as far as practical. Do you have a wrapper drivers could > call? flush_dcache_page() ? :-) Now, the subsystem might be the one to know whether something is mapped into userspace or not (v4l in our case) in which case a wrapper could be created. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 24 Feb 2010 17:00 On Thu, 25 Feb 2010, Benjamin Herrenschmidt wrote: > I'm surprised that usb-storage has an issue here. It shouldn't afaik, > since it's just a SCSI driver (or not anymore ?) It still is. There's also the ub driver, which is a non-SCSI block device driver for some of the same devices handled by usb-storage. > and the BIO or > filesystems handle things there no ? I haven't seen a single call to > flush_dcache_page() in any of drivers/scsi, drivers/ata or drivers/ide > when I looked... There is no real issue; it's just that the problem was first noted in connection with usb-storage reading in executable pages, so Catalin's initial post was oriented toward modifying usb-storage. The main issue here is that the same host controller will use PIO sometimes and DMA sometimes, depending on the details of the transfer. The USB core didn't expect this and consequently we violated the rules for DMA mapping. The question is: If the core is fixed so that the rules aren't violated, will everything work correctly? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 24 Feb 2010 22:50 Am Mittwoch, 24. Februar 2010 22:12:34 schrieb Benjamin Herrenschmidt: > On Wed, 2010-02-24 at 08:16 +0100, Oliver Neukum wrote: > > I don't know. The issue seems quite complex. It would seem better to > > centralize it as far as practical. Do you have a wrapper drivers could > > call? > > flush_dcache_page() ? :-) Will this do anything on arches that don't need it? Secondly, can we have a wrapper that you can pass a pointer and an offset? > Now, the subsystem might be the one to know whether something is mapped > into userspace or not (v4l in our case) in which case a wrapper could be > created. If possible, I'd like to centralize this. Drivers are likely to get this wrong. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 25 Feb 2010 16:00 On Wed, 2010-02-24 at 16:50 -0500, Alan Stern wrote: > The main issue here is that the same host controller will use PIO > sometimes and DMA sometimes, depending on the details of the > transfer. > The USB core didn't expect this and consequently we violated the rules > for DMA mapping. The question is: If the core is fixed so that the > rules aren't violated, will everything work correctly? As long as the only issue is that one (ie, doing PIO while dma-map'ed), then yes, I'd say things should work. If not, then there is -another- problem to be fixed :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 25 Feb 2010 19:30
On Thu, 2010-02-25 at 04:48 +0100, Oliver Neukum wrote: > Am Mittwoch, 24. Februar 2010 22:12:34 schrieb Benjamin Herrenschmidt: > > On Wed, 2010-02-24 at 08:16 +0100, Oliver Neukum wrote: > > > I don't know. The issue seems quite complex. It would seem better to > > > centralize it as far as practical. Do you have a wrapper drivers could > > > call? > > > > flush_dcache_page() ? :-) > > Will this do anything on arches that don't need it? No, it's going to be an empty inline: arch/x86/include/asm/cacheflush.h:static inline void flush_dcache_page(struct page *page) { } > Secondly, can we have a wrapper that you can pass a pointer and an > offset? I'm sure you can make one :-) Use virt_to_page() though that will not work for vmap/vmalloc space of course. > > Now, the subsystem might be the one to know whether something is mapped > > into userspace or not (v4l in our case) in which case a wrapper could be > > created. > > If possible, I'd like to centralize this. Drivers are likely to get this wrong. Right. In the case of v4l, it's probably something that should go into the subsystem. IE. That's how it works for block too, it's done at the BIO and/or filesystem layer (though individual filesystems do have their hand in the pudding). Cheers, Ben. > Regards > Oliver > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |