Eric Lee / smarc-fsl-linux-kernel

11 Oct, 2007

1 commit

17 Jul, 2007

2 commits

  • cb510b817   seq_file: more atomicity in traverse() ... Browse Code »

    Original problem: in some circumstances seq_file interface can present
    infinite proc file to the following script when normally said proc file is
    finite:

    while read line; do
    [do something with $line]
    done index'es being 0 and 1. Current one is 1, as
    bash prints second object line by line.

    Imagine first object being removed right before lseek().
    traverse() will be called, because there is negative offset.
    traverse() will reset ->index to 0 (!).
    traverse() will call ->next() and get NULL in any usual iterate-over-list
    code using list_for_each_entry_continue() and such. There is one object in
    list now after all...
    traverse() will return 0, lseek() will update file position and pretend
    everything is OK.

    So, what we have now: ->f_pos points to place where second object will be
    printed, but ->index is 0. seq_read() instead of returning EOF, will start
    printing first line of first object every time it's called, until enough
    objects are added to ->f_pos return in bounds.

    Fix is to update ->index only after we're sure we saw enough objects down
    the road.

    Signed-off-by: Alexey Dobriyan
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • 00c5746da   mutex_unlock() later in seq_lseek() ... Browse Code »

    All manipulations with struct seq_file::version are done under
    struct seq_file::lock except one introduced in commit
    d6b7a781c51c91dd054e5c437885205592faac21
    aka "[PATCH] Speed up /proc/pid/maps"

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

    Alexey Dobriyan
     

11 Jul, 2007

1 commit

  • bcf67e162   Make common helpers for seq_files that work with list_heads ... Browse Code »

    Many places in kernel use seq_file API to iterate over a regular list_head.
    The code for such iteration is identical in all the places, so it's worth
    introducing a common helpers.

    This makes code about 300 lines smaller:

    The first version of this patch made the helper functions static inline
    in the seq_file.h header. This patch moves them to the fs/seq_file.c as
    Andrew proposed. The vmlinux .text section sizes are as follows:

    2.6.22-rc1-mm1: 0x001794d5
    with the previous version: 0x00179505
    with this patch: 0x00179135

    The config file used was make allnoconfig with the "y" inclusion of all
    the possible options to make the files modified by the patch compile plus
    drivers I have on the test node.

    This patch:

    Many places in kernel use seq_file API to iterate over a regular list_head.
    The code for such iteration is identical in all the places, so it's worth
    introducing a common helpers.

    Signed-off-by: Pavel Emelianov
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Emelianov
     

09 Dec, 2006

1 commit

  • 0f7fc9e4d   [PATCH] VFS: change struct file to use struct path ... Browse Code »

    This patch changes struct file to use struct path instead of having
    independent pointers to struct dentry and struct vfsmount, and converts all
    users of f_{dentry,vfsmnt} in fs/ to use f_path.{dentry,mnt}.

    Additionally, it adds two #define's to make the transition easier for users of
    the f_dentry and f_vfsmnt.

    Signed-off-by: Josef "Jeff" Sipek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josef "Jeff" Sipek
     

08 Dec, 2006

1 commit

23 Mar, 2006

1 commit

  • 0ac1759ab   [PATCH] sem2mutex: fs/seq_file.c ... Browse Code »

    Semaphore to mutex conversion.

    The conversion was generated via scripts, and the result was validated
    automatically via a script as well.

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

    Ingo Molnar
     

08 Nov, 2005

1 commit

01 May, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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