On Tue, Jan 08, 2013 at 04:58:14PM -0800, Eric W. Biederman wrote: > Konrad Rzeszutek Wilk <konrad.w...@oracle.com> writes: > > > On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote: > >> On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu <ying...@kernel.org> wrote: > >> > On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman > >> > <ebied...@xmission.com> wrote: > >> >> I meant we should detect failure to allocate bounce buffers in in > >> >> swiotlb_init() instead of panicing. > >> >> > >> >> I meant swiotlb_map_single() should either panic or simply fail. > >> >> > >> >> If I have read lib/swiotlb.c correctly the only place we allocate a > >> >> bounce buffer is in swiotlb_map_single. If there are more places we can > >> >> allocate bounce buffers those need to be handled as well. > >> > > >> > ok, will give it a try. > >> > >> please check if you are ok with attached. > >> > >> looks like it need more change of lines. > > > > The swiotlb_full check I don't believe is neccessary. You won't ever get > > to that unless swiotlb_map_page has at least provided a bounce buffer. > > And if the swiotlb_map_page does not have a bounce buffer it will exit > > with: > > > > + if (no_iotlb_memory) > > > > + return SWIOTLB_MAP_ERROR; > > > > + > > > > which is dangerous. That is b/c there are drivers that don't use the > > dma_mapping_error check (so check the bus address after calling > > pci_map_*). This means they would try to do DMA on 0xffffffff (yikes!). > > > > That is reason the failback (v_overflow_buffer) is still in > > usage - b/c we have drivers that might just do this and this is the last > > resort for them. And until those drivers are fixed - we _need_ this > > fallback to work. > > So instead we need to say? > > + if (no_iotlb_memory) > > + panic("Cannot allocate SWIOTLB buffer");
"Did not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer." > + > > Which is just making the panic a little later than it used to be and > seems completely reasonable. Yes. When those drivers are all fixed and then we can remove that duct-tape. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/