1. 28 Oct, 2009 2 commits
    • Joe Perches's avatar
      Fix email matching without name --n and --git-blame · 77bf0053
      Joe Perches authored
         Using --non and --git-blame caused maintainer signature
         matching to fail.  Fixed that by adding 3rd argument to
         sub format_email to control show/hide name portion of address
      Slurp -f file instead of reading line-by-line for K: pattern matching.
         Suggested by Wolfram Sang as more efficient
      Refactor git command execution
         Break into 2 functions, execute/analyze
         Share code between --git and --git-blame
         Don't warn multiple times when git isn't installed
      Improve stats reporting
         --git-min-percent and -- rolestats now count the total number of commits
         for either the period of --git-since or if using --git-blame the commits
         used by the current file and calculate commit % as
            # of commits signed / total commits * 100
      Code style cleaning
         Use consistent sub foo { my (args...) = @_;
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Greg KH <greg@kroah.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Wolfram Sang <w.sang@pengutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      77bf0053
    • Joe Perches's avatar
      --roles shows the role of each email address, i.e. why it was selected. · 24faa8a4
      Joe Perches authored
      --rolestats selects --roles and adds git log/blame signers #'s and %
      
      Multiple roles are possible (supporter, maintainer, git-signer...)
      
      --roles or --rolestats is meant to help identify appropriate maintainers
      to notify and should not be used with "git send-email --cc-cmd"
      
      Example output:
      
      Existing:
      
      $ ./scripts/get_maintainer.pl -f arch/x86/kernel/acpi/boot.c
      Corentin Chary <corentincj@iksaif.net>
      Karol Kozimor <sziwan@users.sourceforge.net>
      Len Brown <len.brown@intel.com>
      Pavel Machek <pavel@ucw.cz>
      Rafael J. Wysocki <rjw@sisk.pl>
      Thomas Gleixner <tglx@linutronix.de>
      Ingo Molnar <mingo@redhat.com>
      H. Peter Anvin <hpa@zytor.com>
      x86@kernel.org
      Yinghai Lu <yhlu.kernel@gmail.com>
      Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      acpi4asus-user@lists.sourceforge.net
      linux-pm@lists.linux-foundation.org
      linux-kernel@vger.kernel.org
      
      With --roles
      
      $ ./scripts/get_maintainer.pl --roles -f arch/x86/kernel/acpi/boot.c
      Corentin Chary <corentincj@iksaif.net> (maintainer:ASUS ACPI EXTRAS...)
      Karol Kozimor <sziwan@users.sourceforge.net> (maintainer:ASUS ACPI EXTRAS...)
      Len Brown <len.brown@intel.com> (supporter:SUSPEND TO RAM,git-signer)
      Pavel Machek <pavel@ucw.cz> (supporter:SUSPEND TO RAM)
      Rafael J. Wysocki <rjw@sisk.pl> (supporter:SUSPEND TO RAM)
      Thomas Gleixner <tglx@linutronix.de> (maintainer:X86 ARCHITECTURE...)
      Ingo Molnar <mingo@redhat.com> (maintainer:X86 ARCHITECTURE...,git-signer)
      H. Peter Anvin <hpa@zytor.com> (maintainer:X86 ARCHITECTURE...)
      x86@kernel.org (maintainer:X86 ARCHITECTURE...)
      Yinghai Lu <yhlu.kernel@gmail.com> (git-signer)
      Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> (git-signer)
      acpi4asus-user@lists.sourceforge.net (open list:ASUS ACPI EXTRAS...)
      linux-pm@lists.linux-foundation.org (open list:SUSPEND TO RAM)
      linux-kernel@vger.kernel.org (open list)
      
      With --rolestats
      
      $ ./scripts/get_maintainer.pl --rolestats -f arch/x86/kernel/acpi/boot.c
      Corentin Chary <corentincj@iksaif.net> (maintainer:ASUS ACPI EXTRAS...)
      Karol Kozimor <sziwan@users.sourceforge.net> (maintainer:ASUS ACPI EXTRAS...)
      Len Brown <len.brown@intel.com> (supporter:SUSPEND TO RAM,git-signer:16/79=20%)
      Pavel Machek <pavel@ucw.cz> (supporter:SUSPEND TO RAM)
      Rafael J. Wysocki <rjw@sisk.pl> (supporter:SUSPEND TO RAM)
      Thomas Gleixner <tglx@linutronix.de> (maintainer:X86 ARCHITECTURE...)
      Ingo Molnar <mingo@redhat.com> (maintainer:X86 ARCHITECTURE...,git-signer:29/79=37%)
      H. Peter Anvin <hpa@zytor.com> (maintainer:X86 ARCHITECTURE...)
      x86@kernel.org (maintainer:X86 ARCHITECTURE...)
      Yinghai Lu <yhlu.kernel@gmail.com> (git-signer:12/79=15%)
      Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> (git-signer:6/79=8%)
      acpi4asus-user@lists.sourceforge.net (open list:ASUS ACPI EXTRAS...)
      linux-pm@lists.linux-foundation.org (open list:SUSPEND TO RAM)
      linux-kernel@vger.kernel.org (open list)
      
      With --rolestats and --git-blame
      
      $ ./scripts/get_maintainer.pl --rolestats --git-blame -f arch/x86/kernel/acpi/boot.c
      Corentin Chary <corentincj@iksaif.net> (maintainer:ASUS ACPI EXTRAS...)
      Karol Kozimor <sziwan@users.sourceforge.net> (maintainer:ASUS ACPI EXTRAS...)
      Len Brown <len.brown@intel.com> (supporter:SUSPEND TO RAM,git-signer:16/79=20%,commits:22/154=14%)
      Pavel Machek <pavel@ucw.cz> (supporter:SUSPEND TO RAM)
      Rafael J. Wysocki <rjw@sisk.pl> (supporter:SUSPEND TO RAM)
      Thomas Gleixner <tglx@linutronix.de> (maintainer:X86 ARCHITECTURE...)
      Ingo Molnar <mingo@redhat.com> (maintainer:X86 ARCHITECTURE...,git-signer:29/79=37%,commits:36/154=23%)
      H. Peter Anvin <hpa@zytor.com> (maintainer:X86 ARCHITECTURE...)
      x86@kernel.org (maintainer:X86 ARCHITECTURE...)
      Yinghai Lu <yhlu.kernel@gmail.com> (git-signer:12/79=15%,commits:9/154=6%)
      Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> (git-signer:6/79=8%)
      Andi Kleen <ak@suse.de> (commits:11/154=7%)
      Andrew Morton <akpm@osdl.org> (commits:10/154=6%)
      acpi4asus-user@lists.sourceforge.net (open list:ASUS ACPI EXTRAS...)
      linux-pm@lists.linux-foundation.org (open list:SUSPEND TO RAM)
      linux-kernel@vger.kernel.org (open list)
      
      Other changes:
      
      Format git-signers email addresses a bit to reduce bad signatures
      Command line bad arguments emitted a verbose usage(), just show --help
      Version number bumped to .22
      
      Ben Hutchings had the idea and created a good deal of this implementation.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      24faa8a4
  2. 12 Oct, 2009 2 commits
    • Bernhard Walle's avatar
      The kernel offers with TIOCL_GETKMSGREDIRECT ioctl() the possibility to · 73ec5177
      Bernhard Walle authored
      redirect the kernel messages to a specific console.
      
      However, since it's not possible to switch to the kernel message console
      after a panic(), it would be nice if the kernel would print the panic
      message on the current console.
      Signed-off-by: default avatarBernhard Walle <bernhard@bwalle.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      73ec5177
    • Bernhard Walle's avatar
      The kernel offers with TIOCL_GETKMSGREDIRECT ioctl() the possibility to · 08d86a94
      Bernhard Walle authored
      redirect the kernel messages to a specific console.
      
      However, since it's not possible to switch to the kernel message console
      after a panic(), it would be nice if the kernel would print the panic
      message on the current console.
      
      This patch series adds a new interface to access the global kmsg_redirect
      variable by a function to be able to use it in code where
      CONFIG_VT_CONSOLE is not set (kernel/panic.c).
      
      
      
      This patch:
      
      Instead of using and exporting a global value kmsg_redirect, introduce a
      function vt_kmsg_redirect() that both can set and return the console where
      messages are printed.
      
      Change all users of kmsg_redirect (the VT code itself and kernel/power.c)
      to the new interface.
      
      The main advantage is that vt_kmsg_redirect() can also be used when
      CONFIG_VT_CONSOLE is not set.
      Signed-off-by: default avatarBernhard Walle <bernhard@bwalle.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      08d86a94
  3. 09 Oct, 2009 1 commit
  4. 29 Sep, 2009 1 commit
  5. 15 Oct, 2009 1 commit
  6. 16 Oct, 2009 2 commits
    • Andrew Morton's avatar
      simplify · 5ed7c366
      Andrew Morton authored
      Cc: Amerigo Wang <amwang@redhat.com>
      Cc: Ben Woodard <bwoodard@llnl.gov>
      Cc: Brian Behlendorf <behlendorf1@llnl.gov>
      Cc: David Howells <dhowells@redhat.com>
      Cc: WANG Cong <amwang@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      5ed7c366
    • Amerigo Wang's avatar
      rwsem_is_locked() tests ->activity without locks, so we should always keep · 75634cc8
      Amerigo Wang authored
      ->activity consistent.  However, the code in __rwsem_do_wake() breaks this
      rule, it updates ->activity after _all_ readers waken up, this may give
      some reader a wrong ->activity value, thus cause rwsem_is_locked() behaves
      wrong.
      
      Quote from Andrew:
      
      "
      - we have one or more processes sleeping in down_read(), waiting for access.
      
      - we wake one or more processes up without altering ->activity
      
      - they start to run and they do rwsem_is_locked().  This incorrectly
        returns "false", because the waker process is still crunching away in
        __rwsem_do_wake().
      
      - the waker now alters ->activity, but it was too late.
      "
      
      So we need get a spinlock to protect this.  And rwsem_is_locked() should
      not block, thus we use spin_trylock_irqsave().
      Reported-by: default avatarBrian Behlendorf <behlendorf1@llnl.gov>
      Cc: Ben Woodard <bwoodard@llnl.gov>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      75634cc8
  7. 14 Oct, 2009 2 commits
  8. 13 Oct, 2009 2 commits
    • H Hartley Sweeten's avatar
      The symbol 'call' is a static symbol used for initcall_debug. This same · 03244f00
      H Hartley Sweeten authored
      symbol name is used locally by a couple functions and produces the
      following sparse warnings:
      
      	warning: symbol 'call' shadows an earlier one
      
      Fix this noise by renaming the local symbols.
      Signed-off-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      03244f00
    • Daniel Mack's avatar
      On Mon, Oct 12, 2009 at 12:31:46PM -0400, H Hartley Sweeten wrote: · 2498f9f5
      Daniel Mack authored
      > On Wednesday, October 07, 2009 1:01 PM, Daniel Mack wrote:
      > > This is actually too trivial to publish, but to export the function of
      > > that chip to the userspace, a module like this is needed.
      > >
      > > Signed-off-by: Daniel Mack <daniel@caiaq.de>
      > > Cc: Andrew Morton <akpm@linux-foundation.org>
      > > Cc: David Brownell <dbrownell@users.sourceforge.net>
      > > Cc: spi-devel-general@lists.sourceforge.net
      > > ---
      >
      > [snip]
      >
      > > +static ssize_t dac7512_store_val(struct device *dev,
      > > +				 struct device_attribute *attr,
      > > +				 const char *buf, size_t count)
      > > +{
      > > +	struct spi_device *spi = to_spi_device(dev);
      > > +	unsigned char tmp[2];
      > > +	unsigned long val;
      > > +
      > > +	if (strict_strtoul(buf, 10, &val) < 0)
      > > +		return -EINVAL;
      > > +
      > > +	tmp[0] = val >> 8;
      > > +	tmp[1] = val & 0xff;
      > > +	spi_write(spi, tmp, sizeof(tmp));
      > > +	return count;
      > > +}
      > > +
      > > +static DEVICE_ATTR(value, S_IWUSR | S_IRUGO,
      > > +		   NULL, dac7512_store_val);
      >
      > You have declared the "value" device attribute with mode S_IWUSR | S_IRUGO
      > but have not provided a show callback.
      
      Sorry, forget my last mail, I got you wrong. You're of course right,
      S_IRUGO shouldn't be set for write-only attributes. Updates patch below.
      
      Thanks,
      Daniel
      
      >From ab18a967e55d2bb1d39559333bca81a01c2838f0 Mon Sep 17 00:00:00 2001
      Date: Thu, 8 Oct 2009 03:55:46 +0800
      Subject: [PATCH] drivers/misc: add driver for Texas Instruments DAC7512
      This is actually too trivial to publish, but to export the function of
      that chip to the userspace, a module like this is needed.
      Signed-off-by: default avatarDaniel Mack <daniel@caiaq.de>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: "H Hartley Sweeten" <hartleys@visionengravers.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      2498f9f5
  9. 26 Oct, 2009 1 commit
  10. 24 Sep, 2009 1 commit
  11. 10 Oct, 2009 1 commit
  12. 09 Oct, 2009 2 commits
  13. 30 Sep, 2009 2 commits
  14. 12 Oct, 2009 1 commit
  15. 13 Oct, 2009 1 commit
    • Arjan van de Ven's avatar
      gcc is not convinced that the floppy.c ioctl has sufficient bound checks: · 8c262146
      Arjan van de Ven authored
      In function `copy_from_user',
          inlined from `fd_copyin' at drivers/block/floppy.c:3080,
          inlined from `fd_ioctl' at drivers/block/floppy.c:3503:
      /home/arjan/linux/arch/x86/include/asm/uaccess_32.h:211:
      warning: call to `copy_from_user_overflow' declared with attribute
      warning: copy_from_user buffer size is not provably correct
      
      And frankly, as a human I have a hard time proving the same more or less
      (the size comes from the ioctl argument.  humpf.  maybe.  the code isn't
      very nice)
      
      This patch adds an explicit check to make 100% sure it's safe, better than
      finding out later that there indeed was a gap.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      8c262146
  16. 12 Oct, 2009 1 commit
  17. 23 Jul, 2009 1 commit
  18. 14 Feb, 2009 2 commits
  19. 28 Oct, 2009 1 commit
  20. 31 Oct, 2009 1 commit
    • KAMEZAWA Hiroyuki's avatar
      It's reported that OOM-Killer kills Gnone/KDE first. And yes, we can · cdd5ac71
      KAMEZAWA Hiroyuki authored
      reproduce it easily.
      
      Now, oom-killer uses mm->total_vm as its base value.  But in recent
      applications, there are a big gap between VM size and RSS size.  Because
      
        - Applications attaches much dynamic libraries. (Gnome, KDE, etc...)
        - Applications may alloc big VM area but use small part of them.
          (Java, and multi-threaded applications has this tendency because
           of default-size of stack.)
      
      I think using mm->total_vm as score for oom-kill is not good.  By the same
      reason, overcommit memory can't work as expected.  (In other words, if we
      depends on total_vm, using overcommit more positive is a good choice.)
      
      This patch uses mm->anon_rss/file_rss as base value for calculating badness.
      
      Following is changes to OOM score(badness) on an environment with 1.6G memory
      plus memory-eater(500M & 1G).
      
      Top 10 of badness score. (The highest one is the first candidate to be killed)
      Before
      badness program
      91228	gnome-settings-
      94210	clock-applet
      103202	mixer_applet2
      106563	tomboy
      112947	gnome-terminal
      128944	mmap              <----------- 500M malloc
      129332	nautilus
      215476	bash              <----------- parent of 2 mallocs.
      256944	mmap              <----------- 1G malloc
      423586	gnome-session
      
      After
      badness
      1911	mixer_applet2
      1955	clock-applet
      1986	xinit
      1989	gnome-session
      2293	nautilus
      2955	gnome-terminal
      4113	tomboy
      104163	mmap             <----------- 500M malloc.
      168577	bash             <----------- parent of 2 mallocs
      232375	mmap             <----------- 1G malloc
      
      seems good for me.  Maybe we can tweak this patch more, but this one will
      be a good one as a start point.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reviewed-by: default avatarMinchan Kim <minchan.kim@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      cdd5ac71
  21. 16 Oct, 2009 2 commits
  22. 15 Oct, 2009 2 commits
  23. 16 Oct, 2009 1 commit
    • Hugh Dickins's avatar
      Swap is duplicated (reference count incremented by one) whenever the same · 1f975884
      Hugh Dickins authored
      swap page is inserted into another mm (when forking finds a swap entry in
      place of a pte, or when reclaim unmaps a pte to insert the swap entry).
      
      swap_info_struct's vmalloc'ed swap_map is the array of these reference
      counts: but what happens when the unsigned short (or unsigned char since
      the preceding patch) is full? (and its high bit is kept for a cache flag)
      
      We then lose track of it, never freeing, leaving it in use until swapoff:
      at which point we _hope_ that a single pass will have found all instances,
      assume there are no more, and will lose user data if we're wrong.
      
      Swapping of KSM pages has not yet been enabled; but it is implemented,
      and makes it very easy for a user to overflow the maximum swap count:
      possible with ordinary process pages, but unlikely, even when pid_max
      has been raised from PID_MAX_DEFAULT.
      
      This patch implements swap count continuations: when the count overflows,
      a continuation page is allocated and linked to the original vmalloc'ed
      map page, and this used to hold the continuation counts for that entry
      and its neighbours.  These continuation pages are seldom referenced:
      the common paths all work on the original swap_map, only referring to
      a continuation page when the low "digit" of a count is incremented or
      decremented through SWAP_MAP_MAX.
      Signed-off-by: default avatarHugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1f975884
  24. 15 Oct, 2009 2 commits
  25. 16 Oct, 2009 1 commit
  26. 15 Oct, 2009 3 commits
  27. 13 Oct, 2009 1 commit