28 Apr, 2008

1 commit


31 Mar, 2008

1 commit


09 May, 2007

1 commit


13 Feb, 2007

1 commit

  • Many struct inode_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

09 Dec, 2006

1 commit


04 Oct, 2006

1 commit

  • This patch converts several if () BUG(); construct to BUG_ON();
    which occupies less space, uses unlikely and is safer when
    BUG() is disabled. S_ISREG() has no side effects, so the
    conversion is safe.

    Signed-off-by: Eric Sesterhenn
    Signed-off-by: Adrian Bunk

    Eric Sesterhenn
     

01 Oct, 2006

3 commits

  • Some filesystems, instead of simply decrementing i_nlink, simply zero it
    during an unlink operation. We need to catch these in addition to the
    decrement operations.

    Signed-off-by: Dave Hansen
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • This is mostly included for parity with dec_nlink(), where we will have some
    more hooks. This one should stay pretty darn straightforward for now.

    Signed-off-by: Dave Hansen
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     
  • When a filesystem decrements i_nlink to zero, it means that a write must be
    performed in order to drop the inode from the filesystem.

    We're shortly going to have keep filesystems from being remounted r/o between
    the time that this i_nlink decrement and that write occurs.

    So, add a little helper function to do the decrements. We'll tie into it in a
    bit to note when i_nlink hits zero.

    Signed-off-by: Dave Hansen
    Acked-by: Christoph Hellwig
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave Hansen
     

01 Jul, 2006

1 commit


03 Mar, 2006

1 commit

  • The bitmaps associated with generation numbers for directory entries
    are declared as an array of ints. On some platforms, this causes alignment
    exceptions.

    The following patch uses the standard bitmap declaration macros to
    declare the bitmaps, fixing the problem.

    Originally from Takashi Iwai.

    Signed-off-by: Takashi Iwai
    Acked-by: Jeff Mahoney
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

02 Feb, 2006

1 commit


15 Jan, 2006

1 commit


14 Aug, 2005

1 commit


13 Jul, 2005

1 commit

  • This was a pure indentation change, using:

    scripts/Lindent fs/reiserfs/*.c include/linux/reiserfs_*.h

    to make reiserfs match the regular Linux indentation style. As Jeff
    Mahoney writes:

    The ReiserFS code is a mix of a number of different coding styles, sometimes
    different even from line-to-line. Since the code has been relatively stable
    for quite some time and there are few outstanding patches to be applied, it
    is time to reformat the code to conform to the Linux style standard outlined
    in Documentation/CodingStyle.

    This patch contains the result of running scripts/Lindent against
    fs/reiserfs/*.c and include/linux/reiserfs_*.h. There are places where the
    code can be made to look better, but I'd rather keep those patches separate
    so that there isn't a subtle by-hand hand accident in the middle of a huge
    patch. To be clear: This patch is reformatting *only*.

    A number of patches may follow that continue to make the code more consistent
    with the Linux coding style.

    Hans wasn't particularly enthusiastic about these patches, but said he
    wouldn't really oppose them either.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

24 Jun, 2005

1 commit


06 May, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds