1. 11 Jul, 2012 1 commit
  2. 09 May, 2012 1 commit
  3. 08 May, 2012 1 commit
    • Kay Sievers's avatar
      kmsg: export printk records to the /dev/kmsg interface · e11fea92
      Kay Sievers authored
      
      Support for multiple concurrent readers of /dev/kmsg, with read(),
      seek(), poll() support. Output of message sequence numbers, to allow
      userspace log consumers to reliably reconnect and reconstruct their
      state at any given time. After open("/dev/kmsg"), read() always
      returns *all* buffered records. If only future messages should be
      read, SEEK_END can be used. In case records get overwritten while
      /dev/kmsg is held open, or records get faster overwritten than they
      are read, the next read() will return -EPIPE and the current reading
      position gets updated to the next available record. The passed
      sequence numbers allow the log consumer to calculate the amount of
      lost messages.
      
        [root@mop ~]# cat /dev/kmsg
        5,0,0;Linux version 3.4.0-rc1+ (kay@mop) (gcc version 4.7.0 20120315 ...
        6,159,423091;ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
        7,160,424069;pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7] (ignored)
         SUBSYSTEM=acpi
         DEVICE=+acpi:PNP0A03:00
        6,339,5140900;NET: Registered protocol family 10
        30,340,5690716;udevd[80]: starting version 181
        6,341,6081421;FDC 0 is a S82078B
        6,345,6154686;microcode: CPU0 sig=0x623, pf=0x0, revision=0x0
        7,346,6156968;sr 1:0:0:0: Attached scsi CD-ROM sr0
         SUBSYSTEM=scsi
         DEVICE=+scsi:1:0:0:0
        6,347,6289375;microcode: CPU1 sig=0x623, pf=0x0, revision=0x0
      
      Cc: Karel Zak <kzak@redhat.com>
      Tested-by: default avatarWilliam Douglas <william.douglas@intel.com>
      Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e11fea92
  4. 07 May, 2012 1 commit
    • Kay Sievers's avatar
      printk: convert byte-buffer to variable-length record buffer · 7ff9554b
      Kay Sievers authored
      
      - Record-based stream instead of the traditional byte stream
        buffer. All records carry a 64 bit timestamp, the syslog facility
        and priority in the record header.
      
      - Records consume almost the same amount, sometimes less memory than
        the traditional byte stream buffer (if printk_time is enabled). The record
        header is 16 bytes long, plus some padding bytes at the end if needed.
        The byte-stream buffer needed 3 chars for the syslog prefix, 15 char for
        the timestamp and a newline.
      
      - Buffer management is based on message sequence numbers. When records
        need to be discarded, the reading heads move on to the next full
        record. Unlike the byte-stream buffer, no old logged lines get
        truncated or partly overwritten by new ones. Sequence numbers also
        allow consumers of the log stream to get notified if any message in
        the stream they are about to read gets discarded during the time
        of reading.
      
      - Better buffered IO support for KERN_CONT continuation lines, when printk()
        is called multiple times for a single line. The use of KERN_CONT is now
        mandatory to use continuation; a few places in the kernel need trivial fixes
        here. The buffering could possibly be extended to per-cpu variables to allow
        better thread-safety for multiple printk() invocations for a single line.
      
      - Full-featured syslog facility value support. Different facilities
        can tag their messages. All userspace-injected messages enforce a
        facility value > 0 now, to be able to reliably distinguish them from
        the kernel-generated messages. Independent subsystems like a
        baseband processor running its own firmware, or a kernel-related
        userspace process can use their own unique facility values. Multiple
        independent log streams can co-exist that way in the same
        buffer. All share the same global sequence number counter to ensure
        proper ordering (and interleaving) and to allow the consumers of the
        log to reliably correlate the events from different facilities.
      Tested-by: default avatarWilliam Douglas <william.douglas@intel.com>
      Signed-off-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ff9554b
  5. 04 Jan, 2012 1 commit
  6. 31 Oct, 2011 1 commit
  7. 20 Apr, 2011 1 commit
  8. 19 Apr, 2011 1 commit
  9. 24 Mar, 2011 1 commit
  10. 26 Oct, 2010 1 commit
  11. 15 Oct, 2010 1 commit
    • Arnd Bergmann's avatar
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann authored
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      see...
      6038f373
  12. 22 Sep, 2010 1 commit
  13. 06 Aug, 2010 1 commit
    • David Howells's avatar
      Fix init ordering of /dev/console vs callers of modprobe · 31d1d48e
      David Howells authored
      
      Make /dev/console get initialised before any initialisation routine that
      invokes modprobe because if modprobe fails, it's going to want to open
      /dev/console, presumably to write an error message to.
      
      The problem with that is that if the /dev/console driver is not yet
      initialised, the chardev handler will call request_module() to invoke
      modprobe, which will fail, because we never compile /dev/console as a
      module.
      
      This will lead to a modprobe loop, showing the following in the kernel
      log:
      
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      
      This can happen, for example, when the built in md5 module can't find
      the built in cryptomgr module (because the latter fails to initialise).
      The md5 module comes before the call to tty_init(), presumably because
      'crypto' comes before 'drivers' alphabetically.
      
      Fix this by calling tty_init() from chrdev_init().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      31d1d48e
  14. 07 Apr, 2010 3 commits
  15. 12 Mar, 2010 2 commits
  16. 03 Feb, 2010 2 commits
  17. 15 Dec, 2009 6 commits
  18. 10 Dec, 2009 1 commit
    • Christoph Hellwig's avatar
      vfs: Implement proper O_SYNC semantics · 6b2f3d1f
      Christoph Hellwig authored
      
      While Linux provided an O_SYNC flag basically since day 1, it took until
      Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
      since that day we had generic_osync_around with only minor changes and the
      great "For now, when the user asks for O_SYNC, we'll actually give
      O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
      semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
      patches which are required before this patch it's actually surprisingly
      simple, we just need to figure out when to set the datasync flag to
      vfs_fsync_range and when not.
      
      This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
      numerical value to keep binary compatibility, and adds a new real O_SYNC
      flag.  To guarantee backwards compatiblity it is defined as expanding to
      both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
      sure we are backwards-compatible when compiled against the new headers.
      
      This also means that all places that don't care about the differences can
      just check O_DSYNC and get the right behaviour for O_SYNC, too - only
      places that actuall care need to check __O_SYNC in addition.  Drivers and
      network filesystems have been updated in a fail safe way to always do the
      full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
      lower layers are kept that way for now to stay failsafe.
      
      We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
      to make sure we always get these sane options.
      
      Note that parisc really screwed up their headers as they already define a
      O_DSYNC that has always been a no-op.  We try to repair it by using it for
      the new O_DSYNC and redefinining O_SYNC to send both the traditional
      O_SYNC numerical value _and_ the O_DSYNC one.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andreas Dilger <adilger@sun.com>
      Acked-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: default avatarKyle McMartin <kyle@mcmartin.ca>
      Acked-by: default avatarUlrich Drepper <drepper@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      6b2f3d1f
  19. 04 Dec, 2009 1 commit
  20. 14 Oct, 2009 1 commit
    • Frederic Weisbecker's avatar
      mem_class: Drop the bkl from memory_open() · 205153aa
      Frederic Weisbecker authored
      
      The generic open callback for the mem class devices is "protected" by
      the bkl.
      
      Let's look at the datas manipulated inside memory_open:
      
      - inode and file: safe
      - the devlist: safe because it is constant
      - the memdev classes inside this array are safe too (constant)
      
      After we find out which memdev file operation we need to use, we call
      its open callback. Depending on the targeted memdev, we call either
      open_port() that doesn't manipulate any racy data (just a capable()
      check), or we call nothing.
      
      So it's safe to remove the big kernel lock there.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <1255113062-5835-1-git-send-email-fweisbec@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      205153aa
  21. 27 Sep, 2009 1 commit
  22. 24 Sep, 2009 1 commit
  23. 19 Sep, 2009 1 commit
  24. 15 Sep, 2009 2 commits
  25. 11 Sep, 2009 1 commit
  26. 18 Jun, 2009 1 commit
  27. 10 Jun, 2009 1 commit
    • Linus Torvalds's avatar
      Make /dev/zero reads interruptible by signals · 2b838687
      Linus Torvalds authored
      
      This helps with bad latencies for large reads from /dev/zero, but might
      conceivably break some application that "knows" that a read of /dev/zero
      cannot return early.  So do this early in the merge window to give us
      maximal test coverage, even if the patch is totally trivial.
      
      Obviously, no well-behaved application should ever depend on the read
      being uninterruptible, but hey, bugs happen.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2b838687
  28. 04 Jun, 2009 1 commit
    • Salman Qazi's avatar
      drivers/char/mem.c: avoid OOM lockup during large reads from /dev/zero · 730c586a
      Salman Qazi authored
      While running 20 parallel instances of dd as follows:
      
        #!/bin/bash
        for i in `seq 1 20`; do
                 dd if=/dev/zero of=/export/hda3/dd_$i bs=1073741824 count=1 &
        done
        wait
      
      on a 16G machine, we noticed that rather than just killing the processes,
      the entire kernel went down.  Stracing dd reveals that it first does an
      mmap2, which makes 1GB worth of zero page mappings.  Then it performs a
      read on those pages from /dev/zero, and finally it performs a write.
      
      The machine died during the reads.  Looking at the code, it was noticed
      that /dev/zero's read operation had been changed by
      557ed1fa
      
       ("remove ZERO_PAGE") from giving
      zero page mappings to actually zeroing the page.
      
      The zeroing of the pages causes physical pages to be allocated to the
      process.  But, when the process exhausts all the memory that it can, the
      kernel cannot kill it, as it is still in the kernel mode allocating more
      memory.  Consequently, the kernel eventually crashes.
      
      To fix this, I propose that when a fatal signal is pending during
      /dev/zero read operation, we simply return and let the user process die.
      Signed-off-by: default avatarSalman Qazi <sqazi@google.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      [ Modified error return and comment trivially.  - Linus]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      730c586a
  29. 10 Apr, 2009 1 commit
  30. 06 Jan, 2009 1 commit