From: Sergey Vlasov <vsu@altlinux.ru>
To: Bernd Schubert <bernd-schubert@gmx.de>
Cc: Chris Wright <chrisw@sous-sol.org>,
John M Flinchbaugh <john@hjsoft.com>,
reiserfs-list@namesys.com, Sam Vilain <sam@vilain.net>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.15 Bug? New security model?
Date: Sun, 12 Feb 2006 00:55:41 +0300 [thread overview]
Message-ID: <20060212005541.107f7011.vsu@altlinux.ru> (raw)
In-Reply-To: <20060208221124.GN30803@sorel.sous-sol.org>
[-- Attachment #1: Type: text/plain, Size: 2848 bytes --]
On Wed, 8 Feb 2006 14:11:24 -0800 Chris Wright wrote:
> * Bernd Schubert (bernd-schubert@gmx.de) wrote:
> > Er, you mean /proc/fs/reiserfs/{partition}/on-disk-super?
>
> Yup.
>
> > bernd@bathl ~>grep attrs_cleared /proc/fs/reiserfs/hda6/on-disk-super
> > flags: 1[attrs_cleared]
>
> > > 2) does mount -o attrs ... make a difference?
> >
> > Yes, 2.6.13 now makes the same trouble. No difference with 2.6.15.3.
> > I played with mount -o noattrs, this makes no difference with 2.6.13, but has
> > some effects to 2.6.15.3. Creating files in /var/run is possible again,
> > lsattr gives "lsattr: Inappropriate ioctl for device While reading flags
> > on /var/run", but deleting files in /var/run is still impossible (still
> > rather bad for the init-scripts).
Is the filesystem in question old - could it be created initially in the
reiserfs v3.5 format (used with 2.2.x kernels) and later converted to
v3.6 (by mounting with the "conv" option)?
> Yes, that's what I thought. There's still some backward logic in there.
> noattrs vs. attrs triggers whether the code path that's patched in
> 2.6.15.3 is taken. I'll dig a bit more, but hopefully the reiserfs folks
> can fix this for us.
Here is a simple test case which reproduces the problem with a
filesystem converted from v3.5:
# dd if=/dev/zero of=tmp.img bs=1M count=100
# mkreiserfs --format 3.5 -f tmp.img
# mount -t reiserfs -o loop,conv tmp.img /mnt/disk/
# umount /mnt/disk/
# reiserfsck --clean-attributes tmp.img
# mount -t reiserfs -o loop tmp.img /mnt/disk/
At this point, I get obviously wrong attributes on /mnt/disk:
# lsattr -d /mnt/disk/
-----a--c---- /mnt/disk/
BTW, this breaks even with kernels earlier than 2.6.15.2, if you also
add the "attrs" options to the last mount command.
Apparently the reiserfs attrs code has been broken for such converted
filesystems for some time, but it could be enabled only with the "attrs"
option, so people were not hitting this. However, the following patch:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2949ccf9379678df66ecf2ca70ed4656159eacdd
changed the logic to enable the "attrs" option on all filesystems which
have the reiserfs_attrs_cleared flag. But that patch was broken - it
did not really set the option properly, so the attrs-related breakage
did not became visible until yet another patch:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d35c602870ece3166cff3d25fbc687a7f707acf3
which later made into 2.6.15.2, and caused problems for some people.
I have noticed that fs/reiserfs/inode.c:init_inode() does not initialize
REISERFS_I(inode)->i_attrs and inode->i_flags (as done by
sd_attrs_to_i_attrs()) in the branch for v1 stat data; maybe this causes
the problem?
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2006-02-11 21:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 1:12 2.6.15 Bug? New security model? Bernd Schubert
2006-02-08 1:31 ` Sam Vilain
2006-02-08 5:37 ` John M Flinchbaugh
2006-02-08 12:14 ` Bernd Schubert
2006-02-08 20:50 ` Chris Wright
2006-02-08 21:46 ` Bernd Schubert
2006-02-08 22:11 ` Chris Wright
2006-02-11 21:55 ` Sergey Vlasov [this message]
2006-02-11 23:50 ` Bernd Schubert
2006-02-12 18:44 ` Sergey Vlasov
2006-02-12 17:57 ` Jeff Mahoney
2006-02-12 19:21 ` Sergey Vlasov
2006-02-12 23:03 ` Bernd Schubert
2006-02-13 17:52 ` Sergey Vlasov
2006-02-12 23:10 ` Bernd Schubert
2006-02-13 5:47 ` Hans Reiser
2006-02-13 15:24 ` Jeff Mahoney
2006-02-13 16:39 ` Hans Reiser
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=20060212005541.107f7011.vsu@altlinux.ru \
--to=vsu@altlinux.ru \
--cc=bernd-schubert@gmx.de \
--cc=chrisw@sous-sol.org \
--cc=john@hjsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-list@namesys.com \
--cc=sam@vilain.net \
/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