28 Sep, 2016

1 commit

  • CURRENT_TIME_SEC is not y2038 safe. current_time() will
    be transitioned to use 64 bit time along with vfs in a
    separate patch.
    There is no plan to transistion CURRENT_TIME_SEC to use
    y2038 safe time interfaces.

    current_time() will also be extended to use superblock
    range checking parameters when range checking is introduced.

    This works because alloc_super() fills in the the s_time_gran
    in super block to NSEC_PER_SEC.

    Signed-off-by: Deepa Dinamani
    Acked-by: Jan Kara
    Signed-off-by: Al Viro

    Deepa Dinamani
     

09 Aug, 2014

1 commit

  • The original minix zmap blocks calculation was correct, in the formula of:

    sbi->s_nzones - sbi->s_firstdatazone + 1

    It is

    sp->s_zones - (sp->s_firstdatazone - 1)

    in the minix3 source code.

    But a later commit 016e8d44bc06 ("fs/minix: Verify bitmap block counts
    before mounting") has changed it unfortunately as:

    sbi->s_nzones - (sbi->s_firstdatazone + 1)

    This would show free blocks one block less than the real when the total
    data blocks are in "full zmap blocks plus one".

    This patch corrects that zmap blocks calculation and tidy a printk
    message while at it.

    Signed-off-by: Qi Yong
    Cc: Josh Boyer
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Qi Yong
     

04 Jan, 2012

1 commit


20 Nov, 2011

2 commits

  • Signed-off-by: Al Viro

    Al Viro
     
  • Newer versions of MINIX can create filesystems that allocate an extra
    bitmap block. Mounting of this succeeds, but doing a statfs call will
    result in an oops in count_free because of a negative number being used
    for the bh index.

    Avoid this by verifying the number of allocated blocks at mount time,
    erroring out if there are not enough and make statfs ignore the extras
    if there are too many.

    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=18792

    Signed-off-by: Josh Boyer
    Signed-off-by: Al Viro

    Josh Boyer
     

10 Aug, 2010

1 commit


22 May, 2010

1 commit


17 Jun, 2009

1 commit


14 Nov, 2008

1 commit

  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     

17 Oct, 2007

1 commit


22 May, 2007

1 commit

  • First thing mm.h does is including sched.h solely for can_do_mlock() inline
    function which has "current" dereference inside. By dealing with can_do_mlock()
    mm.h can be detached from sched.h which is good. See below, why.

    This patch
    a) removes unconditional inclusion of sched.h from mm.h
    b) makes can_do_mlock() normal function in mm/mlock.c
    c) exports can_do_mlock() to not break compilation
    d) adds sched.h inclusions back to files that were getting it indirectly.
    e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
    getting them indirectly

    Net result is:
    a) mm.h users would get less code to open, read, preprocess, parse, ... if
    they don't need sched.h
    b) sched.h stops being dependency for significant number of files:
    on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
    after patch it's only 3744 (-8.3%).

    Cross-compile tested on

    all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
    alpha alpha-up
    arm
    i386 i386-up i386-defconfig i386-allnoconfig
    ia64 ia64-up
    m68k
    mips
    parisc parisc-up
    powerpc powerpc-up
    s390 s390-up
    sparc sparc-up
    sparc64 sparc64-up
    um-x86_64
    x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

    as well as my two usual configs.

    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

13 Feb, 2007

1 commit

  • This morning I needed to read a Minix V3 filesystem, but unfortunately my
    2.6.19 did not support that, and neither did the downloaded 2.6.20rc4.

    Fortunately, google told me that Daniel Aragones had already done the work,
    patch found at http://www.terra.es/personal2/danarag/

    Unfortunaly, looking at the patch was painful to my eyes, so I polished it
    a bit before applying. The resulting kernel boots, and reads the
    filesystem it needed to read.

    Signed-off-by: Daniel Aragones
    Signed-off-by: Andries Brouwer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andries Brouwer
     

27 Sep, 2006

1 commit

  • This eliminates the i_blksize field from struct inode. Filesystems that want
    to provide a per-inode st_blksize can do so by providing their own getattr
    routine instead of using the generic_fillattr() function.

    Note that some filesystems were providing pretty much random (and incorrect)
    values for i_blksize.

    [bunk@stusta.de: cleanup]
    [akpm@osdl.org: generic_fillattr() fix]
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Theodore Ts'o
     

26 Mar, 2006

1 commit

  • Believe it or not, but in fs/minix/*, the oldest filesystem in the kernel,
    something still can be fixed:

    printk("new_inode: bit already set");

    "\n" is missing!

    While at it, I also removed periods from the end of error messages and made
    capitalization uniform. Also s/i-node/inode/, s/printk (/printk(/

    Signed-ff-by: Denis Vlasenko

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Denis Vlasenko
     

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