linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: JiSheng Zhang <jszhang3@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Chris Mason <chris.mason@oracle.com>, Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@kernel.org, rmk@arm.linux.org.uk,
	linux-arm@lists.infradead.org
Subject: Re: [BUG]2.6.27.y some contents lost after writing to mmaped file
Date: Wed, 18 Nov 2009 22:17:56 +0800	[thread overview]
Message-ID: <20091118221756.367c005e@ustc> (raw)
In-Reply-To: <20091117190635.GB31105@duck.suse.cz>

On Tue, 17 Nov 2009 20:06:35 +0100
Jan Kara <jack@suse.cz> wrote:

> On Tue 17-11-09 07:36:22, Chris Mason wrote:
> > On Mon, Nov 16, 2009 at 05:56:55PM -0800, Greg KH wrote:
> > > On Mon, Nov 16, 2009 at 11:38:57AM +0800, JiSheng Zhang wrote:
> > > > Hi,
> > > > 
> > > > I triggered a failure in an fs test with fsx-linux from ltp. It seems that
> > > > fsx-linux failed at mmap->write sequence.
> > > > 
> > > > Tested kernel is 2.6.27.12 and 2.6.27.39
> > > 
> > > Does this work on any kernel you have tested?  Or is it a regression?
> > > 
> > > > Tested file system: ext3, tmpfs.
> > > > IMHO, it impacts all file systems.
> > > > 
> > > > Some fsx-linux log is:
> > > > 
> > > > READ BAD DATA: offset = 0x2771b, size = 0xa28e
> > > > OFFSET  GOOD    BAD     RANGE
> > > > 0x287e0 0x35c9  0x15a9     0x80
> > > > operation# (mod 256) for the bad datamay be 21
> > > > ...
> > > > 7828: 1257514978.306753 READ     0x23dba thru 0x25699 (0x18e0 bytes)
> > > > 7829: 1257514978.306899 MAPWRITE 0x27eeb thru 0x2a516 (0x262c bytes)
> > > >  ******WWWW
> > > > 7830: 1257514978.307504 READ     0x2771b thru 0x319a8 (0xa28e bytes)
> > > >  ***RRRR***
> > > > Correct content saved for comparison
> > > > ...
>   Hmm, how long does it take to reproduce? I'm running fsx-linux on tmpfs
> for a while on 2.6.27.21 and didn't hit the problem yet.

I forget to mention that the test were done on an arm board with 64M ram. 
I have tested fsx-linux again on pc, it seems that failure go away.

> 
> > > Are you sure that the LTP is correct?  It wouldn't be the first time it
> > > wasn't...
> > 
> > I'm afraid fsx usually finds bugs.  I thought Jan Kara recently fixed
> > something here in ext3, does 2.6.32-rc work?
>   Yeah, fsx usually finds bugs. Note that he sees the problem also on tmpfs
> so it's not ext3 problem. Anyway, trying to reproduce with 2.6.32-rc? would
> be interesting.

Currently the arm board doesn't support 2.6.32-rc. But I test with 2.6.32-rc7
On my pc box, there's no failure so far.

> 
> 								Honza

I found this via google:
http://marc.info/?t=118026315000001&r=1&w=2

I even tried the code from
http://marc.info/?l=linux-arch&m=118030601701617&w=2
I got mostly:
firstfirstfirst
firstfirstfirst
firstfirstfirst


No change after pass "MS_SYNC|MS_INVALIDATE" to msync and make the 
flush_dcache_page() call unconditional in do_generic_mapping_read.
This behavior is different from what I read from the mail thread above.

> void do_generic_mapping_read(struct address_space *mapping,
>                              struct file_ra_state *_ra,
>                              struct file *filp,
>                              loff_t *ppos,
>                              read_descriptor_t *desc,
>                              read_actor_t actor)
> {
> ...
>                 /* If users can be writing to this page using arbitrary
>                  * virtual addresses, take care about potential aliasing
>                  * before reading the page on the kernel side.
>                  */
>                 if (1 || mapping_writably_mapped(mapping))
>                         flush_dcache_page(page);

Then I run fsx-linux after the above modification, fsx-linux failed all 
the same both on tmpfs and ext3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-11-18 13:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-16  3:38 JiSheng Zhang
2009-11-17  1:56 ` Greg KH
2009-11-17 11:07   ` JiSheng Zhang
2009-11-17 12:36   ` Chris Mason
2009-11-17 19:06     ` Jan Kara
2009-11-18 14:17       ` JiSheng Zhang [this message]
2009-11-19 14:43         ` Jan Kara
2009-11-19 15:25         ` Russell King - ARM Linux
2009-11-20  3:41         ` JiSheng Zhang

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=20091118221756.367c005e@ustc \
    --to=jszhang3@gmail.com \
    --cc=chris.mason@oracle.com \
    --cc=gregkh@suse.de \
    --cc=jack@suse.cz \
    --cc=linux-arm@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=stable@kernel.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