1. 23 4月, 2008 3 次提交
  2. 22 4月, 2008 1 次提交
  3. 15 2月, 2008 2 次提交
  4. 11 10月, 2007 1 次提交
  5. 17 7月, 2007 2 次提交
    • A
      seq_file: more atomicity in traverse() · cb510b81
      Alexey Dobriyan 提交于
      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 </proc/$FILE
      
      bash, to implement such loop does essentially
      
      	read(0, buf, 128);
      	[find \n]
      	lseek(0, -difference, SEEK_CUR);
      
      Consider, proc file prints list of objects each of them consists of many
      lines, each line is shorter than 128 bytes.
      
      Two objects in list, with ->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: NAlexey Dobriyan <adobriyan@sw.ru>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb510b81
    • A
      mutex_unlock() later in seq_lseek() · 00c5746d
      Alexey Dobriyan 提交于
      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: NAlexey Dobriyan <adobriyan@sw.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      00c5746d
  6. 11 7月, 2007 1 次提交
    • P
      Make common helpers for seq_files that work with list_heads · bcf67e16
      Pavel Emelianov 提交于
      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: NPavel Emelianov <xemul@openvz.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bcf67e16
  7. 09 12月, 2006 1 次提交
  8. 08 12月, 2006 1 次提交
  9. 23 3月, 2006 1 次提交
  10. 08 11月, 2005 1 次提交
  11. 01 5月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4