mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Olaf Hering <olh@suse.de>
Cc: linux-kernel@vger.kernel.org, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH] cramfs corruption after BLKFLSBUF on loop device
Date: Wed, 20 Sep 2006 11:47:19 -0700	[thread overview]
Message-ID: <20060920114719.15909483.akpm@osdl.org> (raw)
In-Reply-To: <20060920132011.GA4612@suse.de>

On Wed, 20 Sep 2006 15:20:11 +0200
Olaf Hering <olh@suse.de> wrote:

> On Thu, Jun 01, Olaf Hering wrote:
> 
> > ...
> > Error -3 while decompressing!
> > c0000000009592a2(2649)->c0000000edf87000(4096)
> > Error -3 while decompressing!
> > c000000000959298(2520)->c0000000edbc7000(4096)
> > Error -3 while decompressing!
> > c000000000959c70(2489)->c0000000f1482000(4096) 
> > Error -3 while decompressing!
> > c00000000095a629(2355)->c0000000edaff000(4096)
> > Error -3 while decompressing!
> > ...
> 
> Today I looked at this bug again and found that 2.6.18-rc6-git2 has
> fix for this. Is the patch below supposed to fix the cramfs corruption
> or does it just paper over the bug?
> 
> ...
> cramfs_read() clears parts of the src buffer because the page is not
> uptodate. invalidate_bdev() called from block_ioctl(BLKFLSBUF) will set
> ClearPageUptodate() after cramfs_read() got the page from read_cache_page()
> ...
> 
> /root/cramfscrash.sh
> #!/bin/bash
> # cd /dev/shm/
> # tar xfz /mounts/mirror/kernel/v2.6/linux-2.6.18.tar.gz
> # cd linux-2.6.18/
> # mkfs.cramfs drivers /tmp/cramfs.image
> mount -vnt proc proc /proc
> echo 1 > /proc/sys/kernel/panic
> echo 9 > /proc/sysrq-trigger

That's a novel way of setting the log level.

> mount -vnt sysfs sysfs /sys
> modprobe -v loop
> mount -vnt cramfs -o loop /tmp/cramfs.image /mnt
> while :;do /sbin/blockdev --flushbufs /dev/loop0;done </dev/null &>/dev/null&
> while :;do /usr/bin/find /mnt -type f -print0|xargs -0 cat &>/dev/null;done
> 
> 
> kernel cmdline
> xmon=off panic=1 sysrq=1 quiet root=/dev/disk/by-uuid/d50e4029-2e91-4332-bb16-24f946a74d3f ro init=/root/cramfscrash.sh
> 
> 
> 
>  016eb4a0ed06a3677d67a584da901f0e9a63c666.patch
> From: Andrew Morton <akpm@osdl.org>
> 
> If a CPU faults this page into pagetables after invalidate_mapping_pages()
> checked page_mapped(), invalidate_complete_page() will still proceed to remove
> the page from pagecache.  This leaves the page-faulting process with a
> detached page.  If it was MAP_SHARED then file data loss will ensue.
> 
> Fix that up by checking the page's refcount after taking tree_lock.

Yes, I think this is a reasonable solution to the cramfs race.  Previously,
invalidate_inode_pages() was removing pages from pagecache even if some
other thread had a ref against them, which is pretty bad behaviour.

      reply	other threads:[~2006-09-20 18:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 21:40 Olaf Hering
2006-05-30 13:19 ` Olaf Hering
2006-05-30 18:24 ` Olaf Hering
2006-06-01 18:49   ` [PATCH] " Olaf Hering
2006-06-01 19:12     ` Andrew Morton
2006-06-01 19:15       ` Andrew Morton
2006-06-01 20:10       ` Olaf Hering
2006-06-01 21:24         ` Andrew Morton
2006-06-01 21:41           ` Olaf Hering
2006-06-01 21:57             ` Andrew Morton
2006-06-02  8:43               ` Olaf Hering
2006-06-02  9:11                 ` Andrew Morton
2006-06-02 19:14                   ` Olaf Hering
2006-06-02 19:41                     ` Andrew Morton
2006-06-02 21:06                       ` Olaf Hering
2006-06-02 19:37                   ` Olaf Hering
2006-06-02 19:46                     ` Andrew Morton
2006-06-03 13:13                       ` Olaf Hering
2006-06-01 20:17     ` Chris Mason
2006-06-01 20:20       ` Olaf Hering
2006-06-01 20:29         ` Chris Mason
2006-09-20 13:20     ` Olaf Hering
2006-09-20 18:47       ` Andrew Morton [this message]

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=20060920114719.15909483.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olh@suse.de \
    --cc=viro@ftp.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

Powered by JetHome