All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: GOTO Masanori <gotom@debian.org>,
	marcelo@conectiva.com.br, linux-kernel@vger.kernel.org,
	andrea@suse.de
Subject: Re: [PATCH] direct IO breaks root filesystem
Date: Tue, 11 Dec 2001 19:03:07 +0100	[thread overview]
Message-ID: <3C164A5B.CA0C6CBC@evision-ventures.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0112110932070.8613-100000@penguin.transmeta.com>

Linus Torvalds wrote:
> 
> On Tue, 11 Dec 2001, GOTO Masanori wrote:
> >
> > Accessing with inode size unit (== 4096 byte) is ok, but if I accessed
> > with block size unit, generic_direct_IO() returns error.  The reason
> > is that blocksize is designated as inode->i_blkbits, and its value is
> > not disk minimal block size (512), but inode's unit size (4096).
> 
> Actually, I now found the _real_ bug that explains both the "inode->i_dev"
> _and_ the block size problem.
> 
> We have the wrong inode.
> 
> We use the on-disk inode, which is NOT the same as the "mapping" inode for
> actually doing the IO.
> 
> This simple (and completely untested) patch should fix it.
> 
> This two-liner should also actually make the previous patch completely
> unnecessary, because now "inode->i_dev" should be automatically correct. I
> should have realized that inode->i_dev should always be right, and have
> thought more about the fact that it wasn't.

Hah! This is explainig well, why my private experiment
to make the ext3_inode_info ext3_i field in struct inode
a pointer is still failing maliciously some how during the
booting of the system (actually the init proces goes
really after some [ OK ] optics. And this despite the
fact that there are currently only two VFS entry points
where a fresh new filesystem specific inode can be allocated.

  reply	other threads:[~2001-12-11 18:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <w53bsh9ybtn.wl@megaela.fe.dis.titech.ac.jp>
2001-12-10  3:59 ` [PATCH] direct IO breaks root filesystem GOTO Masanori
2001-12-10  5:55   ` Linus Torvalds
2001-12-10 12:39     ` GOTO Masanori
2001-12-10 14:40       ` Andrea Arcangeli
2001-12-10 17:10       ` Linus Torvalds
2001-12-11  9:03         ` GOTO Masanori
2001-12-11  9:13           ` Alexander Viro
2001-12-11 11:30             ` GOTO Masanori
2001-12-11 17:26           ` Linus Torvalds
2001-12-11 17:37           ` Linus Torvalds
2001-12-11 18:03             ` Martin Dalecki [this message]
2001-12-12  0:25             ` Tachino Nobuhiro
2001-12-12  0:34               ` Linus Torvalds
2001-12-12  0:51                 ` Tachino Nobuhiro
2001-12-12  1:46                   ` Linus Torvalds
2001-12-12  2:46                     ` Tachino Nobuhiro
2001-12-12  3:25                       ` GOTO Masanori
2001-12-12 16:20                         ` Marcelo Tosatti

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=3C164A5B.CA0C6CBC@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=andrea@suse.de \
    --cc=dalecki@evision.ag \
    --cc=gotom@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=torvalds@transmeta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.