public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Dave Miller <davem@redhat.com>, Tejun Heo <htejun@gmail.com>,
	axboe@suse.de, bzolnier@gmail.com,
	james.steward@dynamicratings.com, jgarzik@pobox.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHSET] block: fix PIO cache coherency bug
Date: Fri, 13 Jan 2006 12:35:24 -0600	[thread overview]
Message-ID: <1137177324.3365.67.camel@mulgrave> (raw)
In-Reply-To: <20060113182035.GC25849@flint.arm.linux.org.uk>

On Fri, 2006-01-13 at 18:20 +0000, Russell King wrote:
> I think you're misunderstanding the issue.  I'll give you essentially
> my understanding of the explaination that Dave Miller gave me a number
> of years ago.  This is from memory, so Dave may wish to correct it.
> 
> 1. When a driver DMAs data into a page cache page, it is written directly
>    to RAM and is made visible to the kernel mapping via the DMA API.  As
>    a result, there will be no cache lines associated with the kernel
>    mapping at the point when the driver hands the page back to the page
>    cache.

Yes ... that's essentially what I said: DMA API makes us kernel
coherent.  However, we explicitly *don't* mandate the way architectures
do this.  It's certainly true, all the ones I know work by flushing the
kernel mapping cache lines, but I don't think you're entitled to rely on
this behaviour ... it's not inconcievable for large external cache
machines that the DMA could be done straight into the kernel cache.

>    However, in the PIO case, there is the possibility that the data read
>    from the device into the kernel mapping results in cache lines
>    associated with the page.  Moreover, if the cache is write-allocate,
>    you _will_ have cache lines.
> 
>    Therefore, you have two completely differing system states depending
>    on how the driver decided to transfer data from the device to the page
>    cache.
> 
>    As such, drivers must ensure that PIO data transfers have the same
>    system state guarantees as DMA data transfers.
> 
>    ISTR davem recommended flush_dcache_page() be used for this.

Ah ... perhaps this is the misunderstanding.  To clear the kernel lines
associated with the page you use flush_kernel_dcache_page().
flush_dcache_page() is used to make a page cache page coherent with its
user mappings.

> 2. (this is my own)  The cachetlb document specifies quite clearly what
>    is required whenever a page cache page is written to - that is
>    flush_dcache_page() is called.  The situation when a driver uses PIO
>    quote clearly violates the requirements set out in that document.
> 
> >From (2), it is quite clear that flush_dcache_page() is the correct
> function to use, otherwise we would end up with random set of state
> of pages in the page cache.  (1) merely reinforces that it's the
> correct place for the decision to be made.  In fact, it's the only
> part of the kernel which _knows_ what needs to be done.

True, but your assumption that a driver should be doing this is what I'm
saying is incorrect.  A driver's job is to deliver data coherently to
the kernel.  The kernel's job is to deliver it coherently to the user.

Perhaps we should take this to linux-arch ... the audience there is well
versed in these arcane problems?

James



  reply	other threads:[~2006-01-13 18:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13 15:24 [PATCHSET] block: fix PIO cache coherency bug Tejun Heo
2006-01-13 15:24 ` [PATCH 1/8] highmem: include asm/kmap_types.h in linux/highmem.h Tejun Heo
2006-01-13 15:24 ` [PATCH 2/8] block: implement blk kmap helpers Tejun Heo
2006-01-13 15:24 ` [PATCH 3/8] block: convert bio kmap helpers to use blk_kmap helpers Tejun Heo
2006-01-13 15:24 ` [PATCH 4/8] block: convert IDE " Tejun Heo
2006-02-14 19:07   ` Matt Reimer
2006-02-15  2:05     ` Tejun Heo
2006-02-16 18:01       ` Russell King
2006-02-16 18:10         ` Linus Torvalds
2006-02-16 19:02           ` Russell King
2006-01-13 15:24 ` [PATCH 5/8] block: convert libata " Tejun Heo
2006-01-13 15:24 ` [PATCH 8/8] block: convert md " Tejun Heo
2006-01-13 15:24 ` [PATCH 7/8] block: convert block/rd.c " Tejun Heo
2006-01-13 15:24 ` [PATCH 6/8] block: convert scsi " Tejun Heo
2006-01-13 15:37 ` [PATCHSET] block: fix PIO cache coherency bug Jens Axboe
2006-01-13 15:47 ` Bartlomiej Zolnierkiewicz
2006-01-13 15:50 ` James Bottomley
2006-01-13 18:20   ` Russell King
2006-01-13 18:35     ` James Bottomley [this message]
2006-01-13 19:06       ` Russell King
2006-02-22  8:27         ` Tejun Heo
2006-03-02 18:46           ` James Bottomley
2006-03-02 20:30             ` Russell King
2006-03-02 20:43               ` James Bottomley
2006-03-02 20:57                 ` Russell King
2006-03-02 20:44               ` Jens Axboe
2006-05-29 19:17                 ` Nicolas Pitre
2006-05-30 11:19                   ` Tejun Heo
2006-05-30 21:07                     ` Guennadi Liakhovetski
2006-05-30 21:32                       ` Nicolas Pitre
2006-05-31  0:57                       ` David S. Miller
2006-03-02 20:40           ` Jens Axboe
2006-03-20 16:12           ` James Bottomley
2006-03-20 16:26             ` Tejun Heo
2006-03-20 16:33               ` James Bottomley
2006-03-20 16:40                 ` Tejun Heo
2006-03-20 16:48                   ` James Bottomley
2006-03-23 14:23               ` James Bottomley
2006-03-20 16:50             ` Randy.Dunlap
2006-03-20 16:52               ` James Bottomley
2006-01-13 22:02 ` Russell King
2006-01-13 22:38   ` James Bottomley
2006-01-13 22:43     ` David S. Miller
2006-01-14  4:58       ` James Bottomley
2006-01-17 15:00 ` Jeff Garzik

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=1137177324.3365.67.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=axboe@suse.de \
    --cc=bzolnier@gmail.com \
    --cc=davem@redhat.com \
    --cc=htejun@gmail.com \
    --cc=james.steward@dynamicratings.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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