linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: john@szakmeister.net (John Szakmeister)
To: linux-arm-kernel@lists.infradead.org
Subject: No subject
Date: Tue, 20 Mar 2012 14:28:15 -0400	[thread overview]
Message-ID: <CAEBDL5WkFo-W32zTrJ6d_T2RzkocOVr-8aOU-ydApwxAH4fcFw@mail.gmail.com> (raw)

We've been running into several issues on the cache flushing front,
and I'm hoping that someone here can help clarify what should be
happening from a kernel perspective.

Late last year we discovered a few interesting problems.  One of them
is definitely our fault: we weren't flushing the cache after we read
data from a block device a wrote it into the page.  However, there was
another issue we noticed that made less sense: we had to flush a page
before writing it to our block device, otherwise we end up writing
some stale data.  The brd device ran into this issue before, and fixed
it in commit c2572f2b[1].  In that commit Nick Pidgin says:
    "brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the
     pagecache's responsibility to flush user virtual aliases (the driver of
     course should flush kernel virtual mappings)... but anyway, there
     already exists cache flushing for one direction of transfer, so we
     should add the other."

I can't help but to feel he's right.  It was very surprising to me
that I had to flush the user virtual aliases before writing the data
to the device.  Is it expected that we (as device driver writers) have
to do that for block device drivers?  I love Linux, but one of the
aspects I find most frustrating is that I don't know what I can safely
assume at interface boundaries.  Even modeling my work after existing
code yields problems, because a number of drivers in the tree seem to
be broken in this regard.

But it leads to another concern.  Since I do have to flush on writes,
it got me thinking about whether it's necessary to flush user mode
aliases before conducting a read.  Consider the fact that a page can
span multiple blocks.  Is it possible that:
  * we're asked to read a block of data
  * a user app has scribbled on the page (so it's dirty, but not flushed)
  * we read the requested data from the device
  * load it into the page
  * do a flush_dcache_page()
  * then the data read from the device becomes corrupt because cached user data
    is written to RAM?

Or, instead of that, the cached data gets dropped entirely because it
was on the page, but shouldn't have been because we didn't read new
data into that area, and now that user data is lost?  I confess this
may all be my lack of understanding about Linux's block i/o subsystem,
but I'm thoroughly confused at this point.  What I do know is that
other device drivers are not flushing the page before writing the data
to a device.  For instance, the mmc driver for the at91 architecture
suffers from this problem, and I've been able to see that problem
using mmap.  My concern is that many other drivers also suffer from
this problem, so I'm not sure what the fix needs to be: fix the page
cache, fix the driver, or both.

Also, is there somewhere that says what's guaranteed on entry into my
block device driver?  I've scoured everything I could find... the
Documentation area (including cachetlb.txt), Linux sites, books...
I've yet to find anything mentioning the need to call
flush_dcache_page() much less talk about what the assumptions are.

Thanks in advance for the help.

-John

[1]: <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c2572f2b4ffc27ba79211aceee3bef53a59bb5cd>

             reply	other threads:[~2012-03-20 18:28 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-20 18:28 John Szakmeister [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-06 21:16 No subject Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:16 ` Santosh Shilimkar
2018-07-06 21:18   ` Santosh Shilimkar
2018-06-23 21:08 David Lechner
2018-05-04 20:06 Bjorn Helgaas
2018-04-20  8:02 Christoph Hellwig
2018-04-16  1:22 Andrew Worsley
2017-11-30 10:25 Mary Cuevas
2017-08-22  1:38 Nicholas Piggin
2017-06-26 13:16 [PATCH] arm64: use readq() instead of readl() to read 64bit entry_point Luc Van Oostenryck
2017-07-03 23:46 ` No subject Khuong Dinh
2017-06-04 11:59 Yury Norov
     [not found] <CAMj-D2DO_CfvD77izsGfggoKP45HSC9aD6auUPAYC9Yeq_aX7w@mail.gmail.com>
2017-05-04 16:44 ` gengdongjiu
2017-01-31  7:58 Andy Gross
2016-12-01 10:00 Ramana Radhakrishnan
2016-11-11  3:38 Chunyan Zhang
2016-09-30 14:37 Maxime Ripard
2016-07-10  9:24 Neil Armstrong
2016-04-22  8:25 Daniel Lezcano
2016-04-22  8:27 ` Daniel Lezcano
2016-04-11  7:51 Paul Walmsley
2015-12-13 21:57 何旦洁
2015-10-27  0:44 xuyiping
     [not found] <E1ZqY3A-0004Mt-KH@feisty.vs19.net>
2015-10-26  3:21 ` Jiada Wang
2015-09-01 14:14 Mika Penttilä
2015-09-01 15:22 ` Fabio Estevam
2015-07-22 14:05 Chunfeng Yun
2015-07-15  9:32 Yuan Yao
2015-05-18 20:00 raghu MG
2015-04-21 10:18 Ard Biesheuvel
2015-02-26 16:56 Jorge Ramirez-Ortiz
2015-02-18 16:14 Lee Jones
2014-10-28 14:13 Mark Rutland
2014-09-22 19:41 Santosh Shilimkar
2014-09-22  7:45 Jingchang Lu
2014-07-09 17:49 Sebastian Andrzej Siewior
2014-05-24  1:21 Loc Ho
2014-05-12 16:40 Santosh Shilimkar
2014-05-12 16:38 Santosh Shilimkar
2014-02-22 15:53 Hans de Goede
2014-01-21  4:09 John Tobias
2014-01-16 16:11 Loc Ho
2014-01-16 16:09 Loc Ho
2014-01-13 10:32 Lothar Waßmann
2014-01-13 10:29 Lothar Waßmann
2013-12-12  7:30 Loc Ho
2013-11-01  7:04 Xiubo Li
2013-09-24  3:13 Rohit Vaswani
2013-09-02 17:01 Drasko DRASKOVIC
2013-08-24  9:29 Haojian Zhuang
2013-07-26 10:05 Haojian Zhuang
2013-06-28  5:49 Wang, Yalin
2013-06-19 10:57 Ben Dooks
2013-04-24 18:07 Viral Mehta
2012-12-29  9:17 steve.zhan
2012-11-11 14:16 Sammy Chan
2012-11-08  8:07 Abhimanyu Kapur
2012-10-14 10:05 Alexey Dobriyan
2012-08-27  6:40 Simon Horman
2012-06-21 18:26 Paul Walmsley
2012-06-06 10:33 Sascha Hauer
2012-05-18 12:27 Sascha Hauer
2011-12-28 14:01 Shawn Guo
2011-12-02 16:01 Will Deacon
2011-11-28  2:35 Jett.Zhou
2011-09-19  1:45 Saleem Abdulrasool
2011-09-15  2:03 Jongpill Lee
2011-07-21 11:12 Padmavathi Venna
2011-06-27 20:47 John Ogness
2011-06-27 20:47 Jongpill Lee
2011-06-13 17:29 Andre Silva
2011-06-05 18:33 Hector Oron
2011-05-17  9:28 Javier Martin
2011-05-13 19:35 Vadim Bendebury
2011-03-01 14:02 Javier Martin
2011-01-13  9:13 Uwe Kleine-König
2010-12-03  1:08 tarek attia
2010-10-08  6:02 Daein Moon
2010-09-09  3:33 tarek attia
2010-06-24 13:48 Uwe Kleine-König
2010-06-07 17:58 Dave Hylands
2010-05-18 10:38 Marek Szyprowski
2010-04-17 21:43 nelakurthi koteswararao
2010-02-25  9:36 Thomas Weber
2009-09-17  9:37 Marc Kleine-Budde
2009-09-07 14:07 Somshekar ChandrashekarKadam
2009-08-25 10:34 Syed Rafiuddin

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=CAEBDL5WkFo-W32zTrJ6d_T2RzkocOVr-8aOU-ydApwxAH4fcFw@mail.gmail.com \
    --to=john@szakmeister.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).