public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Mario Holbe <Mario.Holbe@TU-Ilmenau.DE>, linux-kernel@vger.kernel.org
Subject: Re: 2.4: "access beyond end of device" after ext2 mount
Date: Mon, 17 Jan 2005 17:46:35 -0200	[thread overview]
Message-ID: <20050117194635.GD22202@logos.cnet> (raw)
In-Reply-To: <20050115233530.GA2803@darkside.22.kls.lan>

On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:
> Hello,
> 
> mounting an ext2 (ext3 as well) filesystem seems to modify the
> block device's EOF behaviour: before the mount the device returned
> EOF, after the mount it doesn't anymore:
> 
> [on a fresh booted system]
> root@darkside:~# uname -a
> Linux darkside 2.4.27 #1 Sat Jan 15 17:07:20 CET 2005 i686 GNU/Linux
> root@darkside:~# dd if=/dev/hdg7 of=/dev/null
> 9992366+0 records in
> 9992366+0 records out
> 5116091392 bytes transferred in 87,157394 seconds (58699453 bytes/sec)
> root@darkside:~# mke2fs /dev/hdg7
> ...
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 625248 inodes, 1249045 blocks
> ...
> root@darkside:~# dd if=/dev/hdg7 of=/dev/null
> 9992366+0 records in
> 9992366+0 records out
> 5116091392 bytes transferred in 87,439332 seconds (58510184 bytes/sec)
> root@darkside:~# mount -t ext2 -o ro /dev/hdg7 /mnt
> root@darkside:~# umount /dev/hdg7
> root@darkside:~# dd if=/dev/hdg7 of=/dev/null
> attempt to access beyond end of device
> 22:07: rw=0, want=4996184, limit=4996183
> dd: reading `/dev/hdg7': Input/output error
> 9992360+0 records in
> 9992360+0 records out
> 5116088320 bytes transferred in 87,145443 seconds (58707468 bytes/sec)
> root@darkside:~# bc
> 1249045 * 4
> 4996180
> 1249045 * 4 * 2
> 9992360
> 
> Could somebody please explain this to me? Is this intentional?

No

> I could partly imagine the ext2 mount shrinking the block device's
> boundaries to the filesystem boundaries - for security reasons perhaps,
> even if I personally think this isn't the best idea at all, since it
> would violate layers encapsulation.
> However, I have no idea why a) if so, this is not reverted at least
> on umount and why b) the EOF behaviour of the block device changes -
> before there were an EOF sent to the application (dd) while after there
> isn't, but an I/O error instead.

Its indeed strange.

> Kernel is Debian's kernel-source-2.4.27 + kernel-patch-2.4-i2c +
> kernel-patch-2.4-lm-sensors.
> 
> It seems there were already some mails regarding this issue suggesting
> this could have shown up between 2.4.24 and 2.4.25, but it seems they
> were misunderstood, for example:
> 
> From: "ProNIC Solutions" <mot@pronicsolutions.com>
> Subject: 2.4.25: attempt to access beyond end of device
> Date: Tue, 16 Mar 2004 09:06:31 -0500
> Message-ID: <005201c40b5f$e21d34a0$0600a8c0@p17>
> 
> From: "Peter S. Mazinger" <ps.m@gmx.net>
> Subject: BUG in 2.4.25-rc1: attempt to access beyond end of device
> Date: Fri, 6 Feb 2004 13:53:40 +0100 (CET)
> Message-ID: <Pine.LNX.4.44.0402061347160.27376-100000@lnx.bridge.intra>

Actually these were fixed during v2.4.26-pre.

Can you please turn readahead off (hdparm -a 0 /dev/hdg) and repeat the tests?

The kernel is trying to read one block after EOD.

> attempt to access beyond end of device
> 22:07: rw=0, want=4996184, limit=4996183

So maybe an off-by-one read-ahead?

Also I suggest a dump_stack() to see where the read is coming
from.

Any other ideas?

  reply	other threads:[~2005-01-17 22:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-15 23:35 2.4: "access beyond end of device" after ext2 mount Mario Holbe
2005-01-17 19:46 ` Marcelo Tosatti [this message]
2005-01-18  8:20   ` Mario Holbe
2005-01-18 10:55   ` Andries Brouwer
2005-01-18  8:45     ` Marcelo Tosatti
2005-01-18 12:15       ` Mario Holbe
2005-01-18 12:37       ` Andries Brouwer
2005-01-18 10:20         ` Marcelo Tosatti
2005-01-18 11:47     ` Mario Holbe
2005-01-18 12:39       ` Andries Brouwer
  -- strict thread matches above, loose matches on Subject: below --
2005-01-18 13:42 Piszcz, Justin Michael
2005-01-18 14:02 ` Mario Holbe
2005-01-18 14:17   ` Sytse Wielinga
2005-01-18 15:20     ` Mario Holbe
2005-01-18 15:55       ` Sytse Wielinga
2005-01-18 16:12         ` Sytse Wielinga
2005-01-18 14:05 Piszcz, Justin Michael
2005-01-18 14:15 ` Mario Holbe
2005-01-18 14:24 Piszcz, Justin Michael
2005-01-18 15:03 ` Andries Brouwer
2005-01-18 15:29 ` Mario Holbe
2005-01-18 15:07 Piszcz, Justin Michael
2005-01-18 15:42 ` Mario Holbe
     [not found] <fa.f2nt105.94e81t@ifi.uio.no>
     [not found] ` <fa.ihdogs4.bjglrq@ifi.uio.no>
2005-01-21 12:11   ` Bodo Eggert

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=20050117194635.GD22202@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=Mario.Holbe@TU-Ilmenau.DE \
    --cc=linux-kernel@vger.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