From: Hans Reiser <reiser@namesys.com>
To: Sergey Vlasov <vsu@altlinux.ru>, Jeff Mahoney <jeffm@suse.com>
Cc: Bernd Schubert <bernd-schubert@gmx.de>,
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 21:47:28 -0800 [thread overview]
Message-ID: <43F01D70.70600@namesys.com> (raw)
In-Reply-To: <20060212005541.107f7011.vsu@altlinux.ru>
This is an xattr bug, and I'll let jeff answer it.
Hans
Sergey Vlasov wrote:
>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?
>
>
next prev parent reply other threads:[~2006-02-13 5:47 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
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 [this message]
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=43F01D70.70600@namesys.com \
--to=reiser@namesys.com \
--cc=bernd-schubert@gmx.de \
--cc=chrisw@sous-sol.org \
--cc=jeffm@suse.com \
--cc=john@hjsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-list@namesys.com \
--cc=sam@vilain.net \
--cc=vsu@altlinux.ru \
/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.