linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: tsbogend@alpha.franken.de
Cc: fujita.tomonori@lab.ntt.co.jp, linux-scsi@vger.kernel.org,
	linux-ide@vger.kernel.org, jens.axboe@oracle.com,
	bzolnier@gmail.com, James.Bottomley@HansenPartnership.com,
	jeff@garzik.org, akpm@linux-foundation.org, davem@davemloft.net
Subject: Re: [PATCH 0/4] revert the commit 22a9189f (cdrom: use kmalloced buffers instead of buffers on stack)
Date: Thu, 22 May 2008 10:13:31 +0900	[thread overview]
Message-ID: <20080522095506E.tomof@acm.org> (raw)
In-Reply-To: <20080521221113.GA12695@alpha.franken.de>

On Thu, 22 May 2008 00:11:13 +0200
tsbogend@alpha.franken.de (Thomas Bogendoerfer) wrote:

> On Tue, May 20, 2008 at 01:58:30PM +0900, FUJITA Tomonori wrote:
> > The goal of this patchset is reverting the commit
> > 22a9189fd073db3d03a4cf8b8c098aa207602de1 (cdrom: use kmalloced buffers
> > instead of buffers on stack).
> > 
> > http://lkml.org/lkml/2008/4/21/634
> > 
> > The commit is using kmalloced buffers for cdrom packet commands to
> > avoid stack corruption on non coherent platforms. But allocating a
> > small buffer like this is not nice (unnecessary complicity):
> > 
> > +	buffer = kmalloc(8, GFP_KERNEL);
> 
> If I read the bio code correctly with your patch non coherent system will
> be punished a lot more. bio_copy_kern will allocate a whole page for this
> 8 bytes. Please correct me, if I'm wrong otherwise I tend to NAK that 
> approach.

You read the block layer code correctly, but I don't think allocating
one page frame is expensive.

We still have many places to do DMA on stack and need to fix them.

There are still many places (scsi_execute users) in the scsi mid-layer
that uses stack addresses for DMA.

drivers/block/pktcdvd.c always uses stack addresses for DMA for
generic packets.

I don't think that using kmalloc/kfree all over the place is a good
idea. We have a mechanism to do I/Os via a temporary buffer for a
buffer that we can't do DMA against. This patch just uses the mechnism
instead of spreading kmalloc/kfree everywhere. Note that of course
this patch fixes the problems that I explained above.


> > If some architectures can't do DMA on stack, we also need to a new
> > queue_flag like QUEUE_FLAG_NO_DMA_ON_STACK in addtion of this
> > patchset.
> 
> DMA-mapping.txt tells that DMA on stack is forbidden. IMHO we either need
> to revoke that first or deal with it. 

Yeah, it would be better to postpone the 4th patch until we finish
this issue. But I guess that we have enough time to do that until the
next merge window.

DMA on stack is forbidden because of non coherent architecutes and
architectures can't uses stack addresses for DMA? What architectures
can't uses stack addresses for DMA? Would it be better to just forbid
using stack addresses for DMA on all the architectures at all times?

  reply	other threads:[~2008-05-22  1:14 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20  4:58 [PATCH 0/4] revert the commit 22a9189f (cdrom: use kmalloced buffers instead of buffers on stack) FUJITA Tomonori
2008-05-20  4:58 ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask FUJITA Tomonori
2008-05-20  4:58   ` [PATCH 2/4] block: add blk_queue_update_dma_pad FUJITA Tomonori
2008-05-20  4:58     ` [PATCH 3/4] ide: use the dma safe check for REQ_TYPE_ATA_PC FUJITA Tomonori
2008-05-20  4:58       ` [PATCH 4/4] cdrom: revert commit 22a9189 (cdrom: use kmalloced buffers instead of buffers on stack) FUJITA Tomonori
2008-05-20  7:33         ` Elias Oltmanns
2008-05-20  7:42           ` Jim Paris
2008-05-20  8:14             ` Elias Oltmanns
2008-05-28  6:43       ` [PATCH 3/4] ide: use the dma safe check for REQ_TYPE_ATA_PC Borislav Petkov
2008-05-20  9:31   ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask Andrew Morton
2008-05-20  9:38     ` Herbert Xu
2008-05-20  9:52       ` Andrew Morton
2008-05-20  9:58         ` FUJITA Tomonori
2008-05-20 11:32         ` Herbert Xu
2008-05-20 13:25       ` FUJITA Tomonori
2008-05-20 15:34         ` Herbert Xu
2008-05-20 15:53           ` Plans for libsas and SAS-2? Marushak, Nathan
2008-05-20 16:09           ` [PATCH 1/4] block: use ARCH_KMALLOC_MINALIGN as the default dma pad mask FUJITA Tomonori
2008-05-21  1:26             ` Herbert Xu
2008-05-21  1:36               ` FUJITA Tomonori
2008-05-21  3:16                 ` Herbert Xu
2008-05-21  6:54                   ` FUJITA Tomonori
2008-05-21  8:47                     ` Herbert Xu
2008-05-21  9:34                       ` FUJITA Tomonori
2008-05-21 10:05                         ` Herbert Xu
2008-05-21 11:01                           ` FUJITA Tomonori
2008-05-21 11:25                             ` Herbert Xu
2008-05-21 12:09                               ` FUJITA Tomonori
2008-05-21 12:22                                 ` Herbert Xu
2008-05-21 12:46                                   ` FUJITA Tomonori
2008-05-21 12:55                                     ` FUJITA Tomonori
2008-05-21 13:19                                       ` Herbert Xu
2008-05-21 13:18                                     ` Herbert Xu
2008-05-22  1:14                                       ` FUJITA Tomonori
2008-05-22  1:19                                         ` David Miller
2008-05-22  1:21                                           ` Herbert Xu
2008-05-22  1:32                                           ` FUJITA Tomonori
2008-05-22  1:56                                             ` Herbert Xu
2008-05-20  9:55     ` Paul Mundt
2008-05-21 22:11 ` [PATCH 0/4] revert the commit 22a9189f (cdrom: use kmalloced buffers instead of buffers on stack) Thomas Bogendoerfer
2008-05-22  1:13   ` FUJITA Tomonori [this message]
2008-05-22  1:18     ` David Miller
2008-05-22  8:43       ` James Bottomley
2008-05-26  9:17         ` FUJITA Tomonori
2008-05-27 18:58 ` Bartlomiej Zolnierkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080522095506E.tomof@acm.org \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=bzolnier@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).