Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 5月, 2005 2 次提交
  3. 19 5月, 2005 9 次提交
    • D
      AUDIT: Honour audit_backlog_limit again. · fb19b4c6
      由 David Woodhouse 提交于 
      The limit on the number of outstanding audit messages was inadvertently
removed with the switch to queuing skbs directly for sending by a kernel
thread. Put it back again.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      fb19b4c6
    • D
      Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git · 7063e6c7
      由 David Woodhouse 提交于
      7063e6c7
    • D
      AUDIT: Quis Custodiet Ipsos Custodes? · 7ca00264
      由 David Woodhouse 提交于 
      Nobody does. Really, it gets very silly if auditd is recording its
own actions.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      7ca00264
    • D
      Restore logging of pid= and comm= in AVC audit messages · cd77b821
      由 David Woodhouse 提交于 
      We turned this all off because the 'exe=' was causing deadlocks on
dcache_lock. There's no need to leave the pid and comm out though. 
They'll all be logged correctly if full auditing is enabled, but we
should still print them in case auditing _isn't_ enabled.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      cd77b821
    • D
      AUDIT: Send netlink messages from a separate kernel thread · b7d11258
      由 David Woodhouse 提交于 
      netlink_unicast() will attempt to reallocate and will free messages if
the socket's rcvbuf limit is reached unless we give it an infinite 
timeout. So do that, from a kernel thread which is dedicated to spewing
stuff up the netlink socket.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      b7d11258
    • S
      AUDIT: Clean up logging of untrusted strings · 168b7173
      由 Steve Grubb 提交于 
      * If vsnprintf returns -1, it will mess up the sk buffer space accounting. 
This is fixed by not calling skb_put with bogus len values.

* audit_log_hex was a loop that called audit_log_vformat with %02X for each 
character. This is very inefficient since conversion from unsigned character 
to Ascii representation is essentially masking, shifting, and byte lookups. 
Also, the length of the converted string is well known - it's twice the 
original. Fixed by rewriting the function.

* audit_log_untrustedstring had no comments. This makes it hard for 
someone to understand what the string format will be.

* audit_log_d_path was never fixed to use untrustedstring. This could mess
up user space parsers. This was fixed to make a temp buffer, call d_path, 
and log temp buffer using untrustedstring. 

From: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      168b7173
    • L
      Automatic merge of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ · 05d3794a
      由 Linus Torvalds 提交于
      05d3794a
    • S
      [PATCH] Avoid console spam with ext3 aborted journal. · 30121624
      由 Stephen Tweedie 提交于 
      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: NStephen Tweedie <sct@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30121624
    • S
      [PATCH] Fix filp being passed through raw ioctl handler · e72022e1
      由 Stephen Tweedie 提交于 
      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: NStephen Tweedie <sct@redhat.com>
Acked-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e72022e1
  5. 18 5月, 2005 12 次提交
  7. 17 5月, 2005 17 次提交