Skip to content

L
linux-davinci
Switch branch/tag
  1. 18 May, 2005 4 commits
    • Tony Luck's avatar
      Sync with Linus - rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git · 3d620cd7
      Tony Luck authored
      3d620cd7
    • Tony Luck's avatar
      [IA64] alternate perfmon handler · a1ecf7f6
      Tony Luck authored 
      Patch from Charles Spirakis

Some linux customers want to optimize their applications on the latest
hardware but are not yet willing to upgrade to the latest kernel. This
patch provides a way to plug in an alternate, basic, and GPL'ed PMU
subsystem to help with their monitoring needs or for specialty work. It
can also be used in case of serious unexpected bugs in perfmon. Mutual
exclusion between the two subsystems is guaranteed, hence no conflict
can arise from both subsystem being present.
Acked-by: default avatarStephane Eranian <eranian@hpl.hp.com>
Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      a1ecf7f6
    • Stephen Tweedie's avatar
      [PATCH] Avoid console spam with ext3 aborted journal. · 30121624
      Stephen Tweedie authored 
      Avoid console spam with ext3 aborted journal.

ext3 usually reports error conditions that it detects in its environment.
But when its journal gets aborted due to such errors, it can sometimes
continue to report that condition forever, spamming the console to such
an extent that the initial first cause of the journal abort can be lost.

When the journal aborts, we put the filesystem into readonly mode.  Most
subsequent filesystem operations will get rejected immediately by checks
for MS_RDONLY either in the filesystem or in the VFS.  But some paths do
not have such checks --- for example, if we continue to write to a file
handle that was opened before the fs went readonly.  (We only check for
the ROFS condition when the file is first opened.)  In these cases, we
can continue to generate log errors similar to

EXT3-fs error (device $DEV) in start_transaction: Journal has aborted

for each subsequent write.

There is really no point in generating these errors after the initial
error has been fully reported.  Specifically, if we're starting a
completely new filesystem operation, and the filesystem is *already*
readonly (ie. the ext3 layer has already detected and handled the
underlying jbd abort), and we see an EROFS error, then there is simply
no point in reporting it again.
Signed-off-by: default avatarStephen Tweedie <sct@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      30121624
    • Stephen Tweedie's avatar
      [PATCH] Fix filp being passed through raw ioctl handler · e72022e1
      Stephen Tweedie authored 
      Don't pass meaningless file handles to block device ioctls.

The recent raw IO ioctl-passthrough fix started passing the raw file
handle into the block device ioctl handler.  That's unlikely to be
useful, as the file handle is actually open on a character-mode raw
device, not a block device, so dereferencing it is not going to yield
useful results to a block device ioctl handler.

Previously we just passed NULL; also not a value that can usefully
be dereferenced, but at least if it does happen, we'll oops instead of
silently pretending that the file is a block device, so NULL is the more
defensive option here.  This patch reverts to that behaviour.

Noticed by Al Viro.
Signed-off-by: default avatarStephen Tweedie <sct@redhat.com>
Acked-by: default avatarAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e72022e1
  3. 17 May, 2005 36 commits