Fix a use-uninitialised bug.

Cc: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The following patch enables attrs by default if the reiserfs_attrs_cleared
bit is set in the superblock.  This allows chattr-type attrs to be used
without any further action by the user.
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Use improved credits estimates for quota operations.  Also reserve space
for a quota operation in a transaction only if filesystem was mounted with
some quota option.
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Check return values of journal_begin() and journal_end() in the quota code
for reiserfs.
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Move some code duplicated in both callers into vfs_quota_on_mount
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NJan Kara <jack@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch fixes a bug introduced by Al Viro's patch: [patch 136/174]
reiserfs endianness: clone struct reiserfs_key

The problem is MAX_KEY and MAX_IN_CORE_KEY defined in this patch do not
look equal from reiserfs comp_key's point of view.  This caused reiserfs'
sanity check to complain.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

comp_short_keys() massaged into sane form, which kills the last place where
pointer to in_core_key (or any object containing such) would be cast to or
from something else.  At that point we are free to change layout of
in_core_key - nothing depends on it anymore.

So we drop the mess with union in there and simply use (unconditional) __u64
k_offset and __u8 k_type instead; places using in_core_key switched to those.
That gives _far_ better code than current mess - on all platforms.
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: <reiserfs-dev@namesys.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

little-endian objects annotated as such; again, obviously no changes of
resulting code, we only replace __u16 with __le16, etc.  in relevant places.
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: <reiserfs-dev@namesys.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

struct reiserfs_key cloned; (currently) identical struct in_core_key added.
Places that expect host-endian data in reiserfs_key switched to in_core_key.
Basically, we get annotation of reiserfs_key users and keep the resulting tree
obviously equivalent to original.
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: <reiserfs-dev@namesys.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It's trivial for the resize option to auto-get the underlying device size,
while it's harder for the user.  I've copied the code from jfs.

Since of the different reiserfs option parser (which does not use the
superior match_token used by almost every other filesystem), I've had to
use the "resize=auto" and not "resize" option to specify this behaviour.
Changing the option parser to the kernel one wouldn't be bad but I've no
time to do this cleanup in this moment.

Btw, the mount(8) man page should be updated to include this option.  Cc
the relevant people, please (I hope I cc'ed the right people).

Cc: <reiserfs-dev@namesys.com>
Cc: <reiserfs-list@namesys.com>
Cc: <mtk-manpages@gmx.net>
Cc: Alex Zarochentsev <zam@namesys.com>
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!