1. 13 Jul, 2011 10 commits
    • Sjoerd Simons's avatar
      uvcvideo: Remove buffers from the queues when freeing · 986e0f65
      Sjoerd Simons authored
      commit 8ca2c80b upstream.
      
      When freeing memory for the video buffers also remove them from the
      irq & main queues.
      
      This fixes an oops when doing the following:
      
      open ("/dev/video", ..)
      VIDIOC_REQBUFS
      VIDIOC_QBUF
      VIDIOC_REQBUFS
      close ()
      
      As the second VIDIOC_REQBUFS will cause the list entries of the buffers
      to be cleared while they still hang around on the main and irc queues
      Signed-off-by: default avatarSjoerd Simons <sjoerd.simons@collabora.co.uk>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      986e0f65
    • Rafael Aquini's avatar
      mm: fix negative commitlimit when gigantic hugepages are allocated · ae3862c4
      Rafael Aquini authored
      commit b0320c7b upstream.
      
      When 1GB hugepages are allocated on a system, free(1) reports less
      available memory than what really is installed in the box.  Also, if the
      total size of hugepages allocated on a system is over half of the total
      memory size, CommitLimit becomes a negative number.
      
      The problem is that gigantic hugepages (order > MAX_ORDER) can only be
      allocated at boot with bootmem, thus its frames are not accounted to
      'totalram_pages'.  However, they are accounted to hugetlb_total_pages()
      
      What happens to turn CommitLimit into a negative number is this
      calculation, in fs/proc/meminfo.c:
      
              allowed = ((totalram_pages - hugetlb_total_pages())
                      * sysctl_overcommit_ratio / 100) + total_swap_pages;
      
      A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.
      
      Also, every vm statistic which depends on 'totalram_pages' will render
      confusing values, as if system were 'missing' some part of its memory.
      
      Impact of this bug:
      
      When gigantic hugepages are allocated and sysctl_overcommit_memory ==
      OVERCOMMIT_NEVER.  In a such situation, __vm_enough_memory() goes through
      the mentioned 'allowed' calculation and might end up mistakenly returning
      -ENOMEM, thus forcing the system to start reclaiming pages earlier than it
      would be ususal, and this could cause detrimental impact to overall
      system's performance, depending on the workload.
      
      Besides the aforementioned scenario, I can only think of this causing
      annoyances with memory reports from /proc/meminfo and free(1).
      
      [akpm@linux-foundation.org: standardize comment layout]
      Reported-by: default avatarRuss Anderson <rja@sgi.com>
      Signed-off-by: default avatarRafael Aquini <aquini@linux.com>
      Acked-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Christoph Lameter <cl@linux.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ae3862c4
    • Eugene A. Shatokhin's avatar
      ath5k: fix memory leak when fewer than N_PD_CURVES are in use · 6d40246c
      Eugene A. Shatokhin authored
      commit a0b8de35 upstream.
      
      We would free the proper number of curves, but in the wrong
      slots, due to a missing level of indirection through
      the pdgain_idx table.
      
      It's simpler just to try to free all four slots, so do that.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6d40246c
    • Michal Kubecek's avatar
      PM: Free memory bitmaps if opening /dev/snapshot fails · 1588e823
      Michal Kubecek authored
      commit 8440f4b1 upstream.
      
      When opening /dev/snapshot device, snapshot_open() creates memory
      bitmaps which are freed in snapshot_release(). But if any of the
      callbacks called by pm_notifier_call_chain() returns NOTIFY_BAD, open()
      fails, snapshot_release() is never called and bitmaps are not freed.
      Next attempt to open /dev/snapshot then triggers BUG_ON() check in
      create_basic_memory_bitmaps(). This happens e.g. when vmwatchdog module
      is active on s390x.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1588e823
    • Sarah Sharp's avatar
      xhci: Reject double add of active endpoints. · ddaa6a0b
      Sarah Sharp authored
      commit fa75ac37 upstream.
      
      While trying to switch a UAS device from the BOT configuration to the UAS
      configuration via the bConfigurationValue file, Tanya ran into an issue in
      the USB core.  usb_disable_device() sets entries in udev->ep_out and
      udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
      functions to remove the BOT configuration endpoints from the xHCI host's
      internal structures.
      
      The USB core would then attempt to add endpoints for the UAS
      configuration, and some of the endpoints had the same address as endpoints
      in the BOT configuration.  The xHCI driver blindly added the endpoints
      again, but the xHCI host controller rejected the Configure Endpoint
      command because active endpoints were added without being dropped.
      
      Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
      add active endpoints without first calling xhci_drop_endpoint().
      
      This should be backported to kernels as old as 2.6.31.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: default avatarTanya Brokhman <tlinder@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      ddaa6a0b
    • Jiri Slaby's avatar
      TTY: ldisc, do not close until there are readers · 9bb7bdfb
      Jiri Slaby authored
      commit 92f6fa09 upstream.
      
      We restored tty_ldisc_wait_idle in 100eeae2 (TTY: restore
      tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
      case where there are tasks in n_tty_read waiting for data and somebody
      tries to change ldisc.
      
      Similar to the case above, there may be also tasks waiting in
      n_tty_read while hangup is performed. As 65b77046 (tty-ldisc: turn
      ldisc user count into a proper refcount) removed the wait-until-idle
      from all paths, hangup path won't wait for them to disappear either
      now. So add it back even to the hangup path.
      
      There is a difference, we need uninterruptible sleep as there is
      obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
      without possibility to be interrupted. This is what original
      tty_ldisc_wait_idle did. After the wait idle reintroduction
      (100eeae2), we have had interruptible sleeps for the ldisc changing
      path. But as there is a 5s timeout anyway, we don't allow it to be
      interrupted from now on. It's not worth the added complexity of
      deciding what kind of sleep we want.
      
      Before 65b77046 tty_ldisc_release was called also from
      tty_ldisc_release. It is called from tty_release, so I don't think we
      need to restore that one.
      
      This is nicely reproducible after constifying the timing when
      drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
      sanity check" patch is needed to actually see it explode):
      %% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)
      
              /* These are ugly. Currently a malloc failure here can panic */
              if (!tty->read_buf) {
      +               msleep(100);
                      tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
                      if (!tty->read_buf)
                              return -ENOMEM;
      %% -1785,6 +1788,7 @@ do_it_again:
                                      break;
                              }
                              timeout = schedule_timeout(timeout);
      +                       msleep(20);
                              continue;
                      }
                      __set_current_state(TASK_RUNNING);
      ===== With a process: =====
          while (1) {
              int fd = open(argv[1], O_RDWR);
              read(fd, buf, sizeof(buf));
              close(fd);
          }
      ===== and its child: =====
              setsid();
              while (1) {
                      int fd = open(tty, O_RDWR|O_NOCTTY);
                      ioctl(fd, TIOCSCTTY, 1);
                      vhangup();
                      close(fd);
                      usleep(100 * (10 + random() % 1000));
              }
      ===== EOF =====
      
      References: https://bugzilla.novell.com/show_bug.cgi?id=693374
      References: https://bugzilla.novell.com/show_bug.cgi?id=694509Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9bb7bdfb
    • Thomas Gleixner's avatar
      clocksource: Make watchdog robust vs. interruption · b63010f5
      Thomas Gleixner authored
      commit b5199515 upstream.
      
      The clocksource watchdog code is interruptible and it has been
      observed that this can trigger false positives which disable the TSC.
      
      The reason is that an interrupt storm or a long running interrupt
      handler between the read of the watchdog source and the read of the
      TSC brings the two far enough apart that the delta is larger than the
      unstable treshold. Move both reads into a short interrupt disabled
      region to avoid that.
      Reported-and-tested-by: default avatarVernon Mauery <vernux@us.ibm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b63010f5
    • Stefano Stabellini's avatar
      xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped" · 86df3486
      Stefano Stabellini authored
      commit a91d9287 upstream.
      
      We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to
      make sure that cleanup_highmap doesn't remove important mappings at
      _end.
      
      We don't need to do this on x86_32 because cleanup_highmap is not called
      on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted
      side effect of limiting the amount of memory available for the 1:1
      kernel pagetable allocation.
      
      This patch reverts the x86_32 part of the original patch.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      86df3486
    • Andrea Arcangeli's avatar
      migrate: don't account swapcache as shmem · f55a989b
      Andrea Arcangeli authored
      commit 99a15e21 upstream.
      
      swapcache will reach the below code path in migrate_page_move_mapping,
      and swapcache is accounted as NR_FILE_PAGES but it's not accounted as
      NR_SHMEM.
      
      Hugh pointed out we must use PageSwapCache instead of comparing
      mapping to &swapper_space, to avoid build failure with CONFIG_SWAP=n.
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f55a989b
    • Hugh Dickins's avatar
      ksm: fix NULL pointer dereference in scan_get_next_rmap_item() · 4553fbdf
      Hugh Dickins authored
      commit 2b472611 upstream.
      
      Andrea Righi reported a case where an exiting task can race against
      ksmd::scan_get_next_rmap_item (http://lkml.org/lkml/2011/6/1/742) easily
      triggering a NULL pointer dereference in ksmd.
      
      ksm_scan.mm_slot == &ksm_mm_head with only one registered mm
      
      CPU 1 (__ksm_exit)		CPU 2 (scan_get_next_rmap_item)
       				list_empty() is false
      lock				slot == &ksm_mm_head
      list_del(slot->mm_list)
      (list now empty)
      unlock
      				lock
      				slot = list_entry(slot->mm_list.next)
      				(list is empty, so slot is still ksm_mm_head)
      				unlock
      				slot->mm == NULL ... Oops
      
      Close this race by revalidating that the new slot is not simply the list
      head again.
      
      Andrea's test case:
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <sys/mman.h>
      
      #define BUFSIZE getpagesize()
      
      int main(int argc, char **argv)
      {
      	void *ptr;
      
      	if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) {
      		perror("posix_memalign");
      		exit(1);
      	}
      	if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) {
      		perror("madvise");
      		exit(1);
      	}
      	*(char *)NULL = 0;
      
      	return 0;
      }
      Reported-by: default avatarAndrea Righi <andrea@betterlinux.com>
      Tested-by: default avatarAndrea Righi <andrea@betterlinux.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4553fbdf
  2. 23 Jun, 2011 30 commits