All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalpak Shah <kalpak@clusterfs.com>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] e2fsprogs: Offsets of EAs in inode need not be sorted
Date: Sat, 21 Apr 2007 00:47:51 +0530	[thread overview]
Message-ID: <1177096671.3171.4.camel@garfield> (raw)
In-Reply-To: <20070420141052.GA28227@thunk.org>

On Fri, 2007-04-20 at 10:10 -0400, Theodore Tso wrote:
> On Fri, Apr 20, 2007 at 06:35:41PM +0530, Kalpak Shah wrote:
> > 
> > I saw this problem when I was running a script which created a random
> > number of EAs for a file of random sizes. If you mount the image I have
> > given, all the EAs are displayed and they can be used/modified/deleted
> > without any problems so its not a bug in ext3 code.
> 
> Not a bug in the ext3 code, but if a RHEL5 or SLES 10 or Debian etch
> user uses EA-in-Inode, with SELinux enabled, and then uses the e2fsck
> shipped with their distro, some of the unsorted EA's would get
> deleted.... right?  

Yes thats what I meant, it is certainly not a bug in ext3. And actually
the effects are worse, _all_ the EAs in the inode get deleted. I think
not many people have been using > 128 byte inodes and hence this problem
might not have cropped up until now.

Thanks,
Kalpak Shah.
<kalpak@clusterfs.com>

> 
> If that's correct, then that's a pretty nasty data corruption problem
> (that with SELinux enabled could cause the system to become completely
> non-functional, further contributing to SELinux's bad reputation...)
> and we'll need to push your patch to the various distro's as a
> relatively high priority bug fix.
> 
> 						- Ted

  reply	other threads:[~2007-04-20 19:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19 12:05 [PATCH] e2fsprogs: Offsets of EAs in inode need not be sorted Kalpak Shah
2007-04-20 12:38 ` Theodore Tso
2007-04-20 13:05   ` Kalpak Shah
2007-04-20 14:10     ` Theodore Tso
2007-04-20 19:17       ` Kalpak Shah [this message]
2007-05-08  5:07 ` Theodore Tso

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=1177096671.3171.4.camel@garfield \
    --to=kalpak@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.