31 Mar, 2011

1 commit


26 Jan, 2011

1 commit


26 Nov, 2009

1 commit

  • Use of msecs_to_jiffies() for nsecs_to_cputime() have some
    problems:

    - The type of msecs_to_jiffies()'s argument is unsigned int, so
    it cannot convert msecs greater than UINT_MAX = about 49.7 days.

    - msecs_to_jiffies() returns MAX_JIFFY_OFFSET if MSB of argument
    is set, assuming that input was negative value. So it cannot
    convert msecs greater than INT_MAX = about 24.8 days too.

    This patch defines a new function nsecs_to_jiffies() that can
    deal greater values, and that can deal all incoming values as
    unsigned.

    Signed-off-by: Hidetoshi Seto
    Acked-by: Peter Zijlstra
    Cc: Stanislaw Gruszka
    Cc: Spencer Candland
    Cc: Oleg Nesterov
    Cc: Balbir Singh
    Cc: Amrico Wang
    Cc: Thomas Gleixner
    Cc: John Stultz
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Hidetoshi Seto
     

24 Dec, 2008

1 commit

  • Hi.

    I've been looking at a bugzilla which describes a problem where
    a customer was advised to use either the "noac" or "actimeo=0"
    mount options to solve a consistency problem that they were
    seeing in the file attributes. It turned out that this solution
    did not work reliably for them because sometimes, the local
    attribute cache was believed to be valid and not timed out.
    (With an attribute cache timeout of 0, the cache should always
    appear to be timed out.)

    In looking at this situation, it appears to me that the problem
    is that the attribute cache timeout code has an off-by-one
    error in it. It is assuming that the cache is valid in the
    region, [read_cache_jiffies, read_cache_jiffies + attrtimeo]. The
    cache should be considered valid only in the region,
    [read_cache_jiffies, read_cache_jiffies + attrtimeo). With this
    change, the options, "noac" and "actimeo=0", work as originally
    expected.

    This problem was previously addressed by special casing the
    attrtimeo == 0 case. However, since the problem is only an off-
    by-one error, the cleaner solution is address the off-by-one
    error and thus, not require the special case.

    Thanx...

    ps

    Signed-off-by: Peter Staubach
    Signed-off-by: Trond Myklebust

    Peter Staubach
     

01 May, 2008

1 commit

  • x86 is the only arch right now, which provides an optimized for
    div_long_long_rem and it has the downside that one has to be very careful that
    the divide doesn't overflow.

    The API is a little akward, as the arguments for the unsigned divide are
    signed. The signed version also doesn't handle a negative divisor and
    produces worse code on 64bit archs.

    There is little incentive to keep this API alive, so this converts the few
    users to the new API.

    Signed-off-by: Roman Zippel
    Cc: Ralf Baechle
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: john stultz
    Cc: Christoph Lameter
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roman Zippel
     

22 Apr, 2008

2 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial: (24 commits)
    DOC: A couple corrections and clarifications in USB doc.
    Generate a slightly more informative error msg for bad HZ
    fix typo "is" -> "if" in Makefile
    ext*: spelling fix prefered -> preferred
    DOCUMENTATION: Use newer DEFINE_SPINLOCK macro in docs.
    KEYS: Fix the comment to match the file name in rxrpc-type.h.
    RAID: remove trailing space from printk line
    DMA engine: typo fixes
    Remove unused MAX_NODES_SHIFT
    MAINTAINERS: Clarify access to OCFS2 development mailing list.
    V4L: Storage class should be before const qualifier (sn9c102)
    V4L: Storage class should be before const qualifier
    sonypi: Storage class should be before const qualifier
    intel_menlow: Storage class should be before const qualifier
    DVB: Storage class should be before const qualifier
    arm: Storage class should be before const qualifier
    ALSA: Storage class should be before const qualifier
    acpi: Storage class should be before const qualifier
    firmware_sample_driver.c: fix coding style
    MAINTAINERS: Add ati_remote2 driver
    ...

    Fixed up trivial conflicts in firmware_sample_driver.c

    Linus Torvalds
     
  • Generate a slightly more informative error msg for bad HZ
    in include/linux/jiffies.h

    Signed-off-by: Robert P. J. Day
    Signed-off-by: Jesper Juhl

    Robert P. J. Day
     

21 Apr, 2008

1 commit


09 Feb, 2008

1 commit

  • Fix typo in comments.

    BTW: I have to fix coding style in arch/ia64/kernel/time.c also, otherwise
    checkpatch.pl will be complaining.

    Signed-off-by: Li Zefan
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: john stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Li Zefan
     

26 Jan, 2008

1 commit


17 Oct, 2007

1 commit

  • Optionally add a boot delay after each kernel printk() call, crudely
    measured in milliseconds, with a maximum delay of 10 seconds per printk.

    Enable CONFIG_BOOT_PRINTK_DELAY=y and then add (e.g.):
    "lpj=loops_per_jiffy boot_delay=100"
    to the kernel command line.

    It has been useful in cases like "during boot, my machine just reboots or the
    screen goes black" by slowing down printk, (and adding initcall_debug), we can
    usually see the last thing that happened before the lights went out which is
    usually a valuable clue.

    [akpm@linux-foundation.org: not all architectures implement CONFIG_HZ]
    [akpm@linux-foundation.org: fix lots of stuff]
    [bunk@stusta.de: kernel/printk.c: make 2 variables static]
    [heiko.carstens@de.ibm.com: fix slow down printk on boot compile error]
    Signed-off-by: Randy Dunlap
    Signed-off-by: Dave Jones
    Signed-off-by: Adrian Bunk
    Signed-off-by: Heiko Carstens
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

16 Oct, 2007

1 commit

  • * git://git.linux-nfs.org/pub/linux/nfs-2.6: (131 commits)
    NFSv4: Fix a typo in nfs_inode_reclaim_delegation
    NFS: Add a boot parameter to disable 64 bit inode numbers
    NFS: nfs_refresh_inode should clear cache_validity flags on success
    NFS: Fix a connectathon regression in NFSv3 and NFSv4
    NFS: Use nfs_refresh_inode() in ops that aren't expected to change the inode
    SUNRPC: Don't call xprt_release in call refresh
    SUNRPC: Don't call xprt_release() if call_allocate fails
    SUNRPC: Fix buggy UDP transmission
    [23/37] Clean up duplicate includes in
    [2.6 patch] net/sunrpc/rpcb_clnt.c: make struct rpcb_program static
    SUNRPC: Use correct type in buffer length calculations
    SUNRPC: Fix default hostname created in rpc_create()
    nfs: add server port to rpc_pipe info file
    NFS: Get rid of some obsolete macros
    NFS: Simplify filehandle revalidation
    NFS: Ensure that nfs_link() returns a hashed dentry
    NFS: Be strict about dentry revalidation when doing exclusive create
    NFS: Don't zap the readdir caches upon error
    NFS: Remove the redundant nfs_reval_fsid()
    NFSv3: Always use directory post-op attributes in nfs3_proc_lookup
    ...

    Fix up trivial conflict due to sock_owned_by_user() cleanup manually in
    net/sunrpc/xprtsock.c

    Linus Torvalds
     

13 Oct, 2007

1 commit


10 Oct, 2007

1 commit

  • I would like to discuss the idea that the current checks for attribute
    timeout using time_after are inadequate for 32bit architectures, since
    time_after works correctly only when the two timestamps being compared
    are within 2^31 jiffies of each other. The signed overflow caused by
    comparing values more than 2^31 jiffies apart will flip the result,
    causing incorrect assumptions of validity.

    2^31 jiffies is a fairly large period of time (~25 days) when compared
    to the lifetime of most kernel data structures, but for long lived NFS
    mounts that can sit idle for months (think that for some reason autofs
    cannot be used), it is easy to compare inode attribute timestamps with
    very disparate or even bogus values (as in when jiffies have wrapped
    many times, where the comparison doesn't even make sense).

    Currently the code tests for attribute timeout by simply adding the
    desired amount of jiffies to the stored timestamp and comparing that
    with the current timestamp of obtained attribute data with time_after.
    This is incorrect, as it returns true for the desired timeout period
    and another full 2^31 range of jiffies.

    In testing with artificial jumps (several small jumps, not one big
    crank) of the jiffies I was able to reproduce a problem found in a
    server with very long lived NFS mounts, where attributes would not be
    refreshed even after touching files and directories in the server:

    Initial uptime:
    03:42:01 up 6 min, 0 users, load average: 0.01, 0.12, 0.07

    NFS volume is mounted and time is advanced:
    03:38:09 up 25 days, 2 min, 0 users, load average: 1.22, 1.05, 1.08

    # ls -l /local/A/foo/bar /nfs/A/foo/bar
    -rw-r--r-- 1 root root 0 Dec 17 03:38 /local/A/foo/bar
    -rw-r--r-- 1 root root 0 Nov 22 00:36 /nfs/A/foo/bar

    # touch /local/A/foo/bar

    # ls -l /local/A/foo/bar /nfs/A/foo/bar
    -rw-r--r-- 1 root root 0 Dec 17 03:47 /local/A/foo/bar
    -rw-r--r-- 1 root root 0 Nov 22 00:36 /nfs/A/foo/bar

    We can see the local mtime is updated, but the NFS mount still shows
    the old value. The patch below makes it work:

    Initial setup...
    07:11:02 up 25 days, 1 min, 0 users, load average: 0.15, 0.03, 0.04

    # ls -l /local/A/foo/bar /nfs/A/foo/bar
    -rw-r--r-- 1 root root 0 Jan 11 07:11 /local/A/foo/bar
    -rw-r--r-- 1 root root 0 Jan 11 07:11 /nfs/A/foo/bar

    # touch /local/A/foo/bar

    # ls -l /local/A/foo/bar /nfs/A/foo/bar
    -rw-r--r-- 1 root root 0 Jan 11 07:14 /local/A/foo/bar
    -rw-r--r-- 1 root root 0 Jan 11 07:14 /nfs/A/foo/bar

    Signed-off-by: Fabio Olive Leite
    Signed-off-by: Trond Myklebust

    Fabio Olive Leite
     

17 Feb, 2007

2 commits

  • Prevent timeout overflow if timer ticks are behind jiffies (due to high
    softirq load or due to dyntick), by limiting the valid timeout range to
    MAX_LONG/2.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Cc: john stultz
    Cc: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     
  • There are loads of fat functions hidden in jiffies.h. Uninline them. No code
    changes.

    [jeremy@goop.org: export fix]
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner
    Cc: john stultz
    Cc: Roman Zippel
    Cc: Jeremy Fitzhardinge
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

30 Nov, 2006

1 commit

  • jiffies.h includes a comment informing that jiffies_64 must be read with the
    assistance of the xtime_lock seqlock. The comment text, however, calls
    jiffies_64 "not volatile", which should probably read "not atomic".

    Signed-off-by: Chase Venters
    Signed-off-by: Adrian Bunk

    Chase Venters
     

26 Sep, 2006

1 commit

  • The current time_before/time_after macros will fail typechecks
    when passed u64 values (as returned by get_jiffies_64()). On 64bit
    systems, this will just result in a warning about mismatching types
    without explicit casts, but since unsigned long and u64
    (unsigned long long) are of same size, it will still work.
    On 32bit systems, a long is 32bits, so the value from get_jiffies_64()
    will be truncated by the cast and thus lose all the precision gained by
    64bit jiffies.

    Signed-off-by: Dmitriy Zavin
    Signed-off-by: Andi Kleen

    Dmitriy Zavin
     

01 Aug, 2006

1 commit


10 Apr, 2006

1 commit

  • If the HPET timer is enabled, the clock can drift by ~3 seconds a day.
    This is due to the HPET timer not being initialized with the correct
    setting (still using PIT count).

    If HZ changes, this drift can become even more pronounced.

    HPET patch initializes tick_nsec with correct tick_nsec settings for
    HPET timer.

    Vojtech comments:

    "It's not entirely correct (it assumes the HPET ticks totally
    exactly), but it's significantly better than assuming the PIT error
    there."

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Jordan Hargrave
     

11 Jan, 2006

1 commit


11 Sep, 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