Skip to content

L
linux-davinci
Switch branch/tag
  1. 24 Aug, 2009 1 commit
    • Edward Shishkin's avatar
      In accordance with reiser4 transactional model every dirty page should be · 5c025457
      Edward Shishkin authored 
      "captured" by some atom.  However, outside reiser4 context dirty page can
not be captured in some cases, as it is accompanied with specific work
(jnode creation, etc).  Reiser4 recognizes such "anonymous" pages (i.e. 
pages that were dirtied outside of reiser4) by the tag
PAGECACHE_TAG_DIRTY.  Pages dirtied inside reiser4 context are not tagged
at all: we don't need this.  Indeed, once page is dirtied and captured, it
is attached to a jnode (a special header to keep a track of transactions).

reiser4_set_page_dirty_internal() was the internal reiser4 function that
set dirty bit without tagging the page.  Having such internal function led
to real problems (incorrect task io accounting, etc.  because of not
updating this internal "friend").

Solution:

The following patch adds a core library function that sets a dirty bit
without tagging the page.

Signed-off-by: Edward Shishkin<edward.shishkin@gmail.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      5c025457
  3. 04 Jun, 2009 1 commit
  5. 24 Aug, 2009 1 commit
  7. 04 Jun, 2009 1 commit
  9. 24 Aug, 2009 1 commit
  11. 04 Aug, 2009 1 commit
  13. 25 Jun, 2009 1 commit
  15. 20 Jul, 2009 1 commit
  17. 03 Aug, 2009 1 commit
  19. 03 Sep, 2009 1 commit
  21. 02 Sep, 2009 1 commit
  23. 24 Aug, 2009 2 commits
  25. 25 Jun, 2009 1 commit
  27. 26 Aug, 2009 1 commit
  29. 11 Aug, 2009 2 commits
  31. 15 Jul, 2009 3 commits
  33. 23 Jul, 2009 1 commit
  35. 30 Jul, 2009 1 commit
  37. 24 Aug, 2009 1 commit
  39. 10 Sep, 2009 1 commit
    • Alexey Dobriyan's avatar
      It's unused. · f3725c8c
      Alexey Dobriyan authored 
      It isn't needed -- read or write flag is already passed and sysctl
shouldn't care about the rest.

It _was_ used in two places at arch/frv for some reason.
Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      f3725c8c
  41. 24 Aug, 2009 1 commit
  43. 10 Sep, 2009 1 commit
  45. 17 Aug, 2009 1 commit
  47. 12 Aug, 2009 1 commit
    • Nils Carlson's avatar
      The periodic interrupt from drivers/char/hpet.c does not work correctly, · 7a6c798b
      Nils Carlson authored 
      both when using the periodic capability of the hardware and while
emulating the periodic interrupt (when hardware does not support periodic
mode).

With timers capable of periodic interrupts, the comparator field is first
set with the period value followed by set of hidden accumulator, which has
the side effect of overwriting the comparator value.  This results in
wrong periodicity for the interrupts.  For, periodic interrupts to work,
following steps are necessary, in that order.

* Set config with Tn_VAL_SET_CNF bit

* Write to hidden accumulator, the value written is the time when the
  first interrupt should be generated

* Write compartor with period interval for subsequent interrupts
  (http://www.intel.com/hardwaredesign/hpetspec_1.pdf )

When emulating periodic timer with timers not capable of periodic
interrupt, driver is adding the period to counter value instead of
comparator value, which causes slow drift when using this emulation.

Also, driver seems to add hpetp->hp_delta both while setting up periodic
interrupt and while emulating periodic interrupts with timers not capable
of doing periodic interrupts.  This hp_delta will result in slower than
expected interrupt rate and should not be used while setting the interval.
Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: default avatarNils Carlson <nils.carlson@ericsson.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      7a6c798b
  49. 04 Aug, 2009 1 commit
  51. 24 Aug, 2009 2 commits
  53. 18 Aug, 2009 1 commit
    • Renzo Davoli's avatar
      There are two useless lines in fs/char_dev.c. · 5529cb8a
      Renzo Davoli authored 
      In register_chrdev there is a loop to change all '/' into '!' in the
kernel object name.
This code is useless as the same substitution is in kobject_set_name_vargs in
lib/kobject.c:
228         /* ewww... some of these buggers have '/' in the name ... */
229         while ((s = strchr(kobj->name, '/')))
230                 s[0] = '!';

kobject_set_name_vargs is called by kobject_set_name.
kobject_set_name is called just above the useless loop.
Signed-off-by: default avatarRenzo Davoli <renzo@cs.unibo.it>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      5529cb8a
  55. 21 Jul, 2009 1 commit
  57. 02 Jul, 2009 1 commit
  59. 20 Jul, 2009 1 commit
  61. 01 Jul, 2009 2 commits
  63. 23 Jul, 2009 1 commit
    • Lai Jiangshan's avatar
      _cpu_down() changes the current task's affinity and then recovers it at · 0fdcbb46
      Lai Jiangshan authored 
      the end.

It has two problems:

1) The recovery of the current tasks's cpus_allowed will fail under
   some conditions.

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      0-3

   # taskset -pc 2 $$
   pid 29075's current affinity list: 0-3
   pid 29075's new affinity list: 2

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      2

   # echo 0 > /sys/devices/system/cpu/cpu2/online

   # grep Cpus_allowed_list /proc/$$/status
   Cpus_allowed_list:      0

   Here, the Cpus_allowed_list was originally "2" and has become
   "0-1,3" after cpu #2 is offlined.

   This "Cpus_allowed_list:      0" is incorrect.

2) If the current task is a userspace task, the user may change its
   cpu-affinity during the CPU hot-unplugging.  This change can be
   overwritten when _cpu_down() changes the current task's affinity.


Fix all this by not changing the current tasks's affinity.  Instead we
create a kernel thread to do the work.
Signed-off-by: default avatarLai Jiangshan <laijs@cn.fujitsu.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      0fdcbb46
  65. 28 Jul, 2009 1 commit
    • Oleg Nesterov's avatar
      sys_delete_module() can set MODULE_STATE_GOING after · dfdcb38a
      Oleg Nesterov authored 
      search_binary_handler() does try_module_get().  In this case
set_binfmt()->try_module_get() fails but since none of the callers
check the returned error, the task will run with the wrong old
->binfmt.

The proper fix should change all ->load_binary() methods, but we can
rely on fact that the caller must hold a reference to binfmt->module
and use __module_get() which never fails.
Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      dfdcb38a
  67. 22 Jul, 2009 1 commit
    • Neil Horman's avatar
      Allow core_pattern pipes to wait for user space to complete · 00c67933
      Neil Horman authored 
      One of the things that user space processes like to do is look at metadata
for a crashing process in their /proc/<pid> directory.  this is racy
however, since do_coredump in the kernel doesn't wait for the user space
process to complete before it reaps the crashing process.  This patch
corrects that.  Allowing the kernel to wait for the user space process to
complete before cleaning up the crashing process.  This is a bit tricky to
do for a few reasons:

1) The user space process isn't our child, so we can't sys_wait4 on it
2) We need to close the pipe before waiting for the user process to complete,
since the user process may rely on an EOF condition

I've discussed several solutions with Oleg Nesterov off-list about this,
and this is the one we've come up with.  We add ourselves as a pipe reader
(to prevent premature cleanup of the pipe_inode_info), and remove
ourselves as a writer (to provide an EOF condition to the writer in user
space), then we iterate until the user space process exits (which we
detect by pipe->readers == 1, hence the > 1 check in the loop).  When we
exit the loop, we restore the proper reader/writer values, then we return
and let filp_close in do_coredump clean up the pipe data properly.
Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
Reported-by: default avatarEarl Chew <earl_chew@agilent.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      00c67933