An error occurred fetching the project authors.
  1. 20 Aug, 2013 28 commits
  2. 15 Aug, 2013 12 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.4.58 · 13cbe0fb
      Greg Kroah-Hartman authored
      13cbe0fb
    • Joshua Zhu's avatar
      perf tools: Add anonymous huge page recognition · 03bca23e
      Joshua Zhu authored
      commit d0528b5d upstream.
      
      Judging anonymous memory's vm_area_struct, perf_mmap_event's filename
      will be set to "//anon" indicating this vma belongs to anonymous
      memory.
      
      Once hugepage is used, vma's vm_file points to hugetlbfs. In this way,
      this vma will not be regarded as anonymous memory by is_anon_memory() in
      perf user space utility.
      Signed-off-by: default avatarJoshua Zhu <zhu.wen-jie@hp.com>
      Cc: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Joshua Zhu <zhu.wen-jie@hp.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Vinson Lee <vlee@freedesktop.org>
      Link: http://lkml.kernel.org/r/1357363797-3550-1-git-send-email-zhu.wen-jie@hp.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      03bca23e
    • NeilBrown's avatar
      vfs: d_obtain_alias() needs to use "/" as default name. · 7a0117d3
      NeilBrown authored
      commit b911a6bd upstream.
      
      NFS appears to use d_obtain_alias() to create the root dentry rather than
      d_make_root.  This can cause 'prepend_path()' to complain that the root
      has a weird name if an NFS filesystem is lazily unmounted.  e.g.  if
      "/mnt" is an NFS mount then
      
       { cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }
      
      will cause a WARN message like
         WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0()
         ...
         Root dentry has weird name <>
      
      to appear in kernel logs.
      
      So change d_obtain_alias() to use "/" rather than "" as the anonymous
      name.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [bwh: Backported to 3.2: use named initialisers instead of QSTR_INIT()]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a0117d3
    • Arnd Bergmann's avatar
      SCSI: nsp32: use mdelay instead of large udelay constants · 4bcdbddd
      Arnd Bergmann authored
      commit b497ceb9 upstream.
      
      ARM cannot handle udelay for more than 2 miliseconds, so we
      should use mdelay instead for those.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGOTO Masanori <gotom@debian.or.jp>
      Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bcdbddd
    • Andrew Vagin's avatar
      tracing: Fix fields of struct trace_iterator that are zeroed by mistake · 99593eb7
      Andrew Vagin authored
      commit ed5467da upstream.
      
      tracing_read_pipe zeros all fields bellow "seq". The declaration contains
      a comment about that, but it doesn't help.
      
      The first field is "snapshot", it's true when current open file is
      snapshot. Looks obvious, that it should not be zeroed.
      
      The second field is "started". It was converted from cpumask_t to
      cpumask_var_t (v2.6.28-4983-g4462344e), in other words it was
      converted from cpumask to pointer on cpumask.
      
      Currently the reference on "started" memory is lost after the first read
      from tracing_read_pipe and a proper object will never be freed.
      
      The "started" is never dereferenced for trace_pipe, because trace_pipe
      can't have the TRACE_FILE_ANNOTATE options.
      
      Link: http://lkml.kernel.org/r/1375463803-3085183-1-git-send-email-avagin@openvz.orgSigned-off-by: default avatarAndrew Vagin <avagin@openvz.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99593eb7
    • Oleg Nesterov's avatar
      debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs) · 65280b8e
      Oleg Nesterov authored
      commit 776164c1 upstream.
      
      debugfs_remove_recursive() is wrong,
      
      1. it wrongly assumes that !list_empty(d_subdirs) means that this
         dir should be removed.
      
         This is not that bad by itself, but:
      
      2. if d_subdirs does not becomes empty after __debugfs_remove()
         it gives up and silently fails, it doesn't even try to remove
         other entries.
      
         However ->d_subdirs can be non-empty because it still has the
         already deleted !debugfs_positive() entries.
      
      3. simple_release_fs() is called even if __debugfs_remove() fails.
      
      Suppose we have
      
      	dir1/
      		dir2/
      			file2
      		file1
      
      and someone opens dir1/dir2/file2.
      
      Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes
      away.
      
      But debugfs_remove_recursive(dir1) silently fails and doesn't remove
      this directory. Because it tries to delete (the already deleted)
      dir1/dir2/file2 again and then fails due to "Avoid infinite loop"
      logic.
      
      Test-case:
      
      	#!/bin/sh
      
      	cd /sys/kernel/debug/tracing
      	echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events
      	sleep 1000 < events/probe/sigprocmask/id &
      	echo -n >| kprobe_events
      
      	[ -d events/probe ] && echo "ERR!! failed to rm probe"
      
      And after that it is not possible to create another probe entry.
      
      With this patch debugfs_remove_recursive() skips !debugfs_positive()
      files although this is not strictly needed. The most important change
      is that it does not try to make ->d_subdirs empty, it simply scans
      the whole list(s) recursively and removes as much as possible.
      
      Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.comAcked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65280b8e
    • Julius Werner's avatar
      usb: core: don't try to reset_device() a port that got just disconnected · 8b45ff80
      Julius Werner authored
      commit 481f2d4f upstream.
      
      The USB hub driver's event handler contains a check to catch SuperSpeed
      devices that transitioned into the SS.Inactive state and tries to fix
      them with a reset. It decides whether to do a plain hub port reset or
      call the usb_reset_device() function based on whether there was a device
      attached to the port.
      
      However, there are device/hub combinations (found with a JetFlash
      Transcend mass storage stick (8564:1000) on the root hub of an Intel
      LynxPoint PCH) which can transition to the SS.Inactive state on
      disconnect (and stay there long enough for the host to notice). In this
      case, above-mentioned reset check will call usb_reset_device() on the
      stale device data structure. The kernel will send pointless LPM control
      messages to the no longer connected device address and can even cause
      several 5 second khubd stalls on some (buggy?) host controllers, before
      finally accepting the device's fate amongst a flurry of error messages.
      
      This patch makes the choice of reset dependent on the port status that
      has just been read from the hub in addition to the existence of an
      in-kernel data structure for the device, and only proceeds with the more
      extensive reset if both are valid.
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b45ff80
    • Chen Gang's avatar
      cifs: extend the buffer length enought for sprintf() using · 3fbcb7f9
      Chen Gang authored
      commit 057d6332 upstream.
      
      For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length
      is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName'
      length may be "255 + '\0'".
      
      The related sprintf() may cause memory overflow, so need extend related
      buffer enough to hold all things.
      
      It is also necessary to be sure of 'ses->domainName' must be less than
      256, and define the related macro instead of hard code number '256'.
      Signed-off-by: default avatarChen Gang <gang.chen@asianux.com>
      Reviewed-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Reviewed-by: default avatarScott Lovenberg <scott.lovenberg@gmail.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fbcb7f9
    • Piotr Sarna's avatar
      ext4: fix mount/remount error messages for incompatible mount options · 6cd45319
      Piotr Sarna authored
      commit 6ae6514b upstream.
      
      Commit 56889787 ("ext4: improve handling of conflicting mount options")
      introduced incorrect messages shown while choosing wrong mount options.
      
      First of all, both cases of incorrect mount options,
      "data=journal,delalloc" and "data=journal,dioread_nolock" result in
      the same error message.
      
      Secondly, the problem above isn't solved for remount option: the
      mismatched parameter is simply ignored.  Moreover, ext4_msg states
      that remount with options "data=journal,delalloc" succeeded, which is
      not true.
      
      To fix it up, I added a simple check after parse_options() call to
      ensure that data=journal and delalloc/dioread_nolock parameters are
      not present at the same time.
      Signed-off-by: default avatarPiotr Sarna <p.sarna@partner.samsung.com>
      Acked-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cd45319
    • Amit Shah's avatar
      virtio: console: return -ENODEV on all read operations after unplug · a57425e9
      Amit Shah authored
      commit 96f97a83 upstream.
      
      If a port gets unplugged while a user is blocked on read(), -ENODEV is
      returned.  However, subsequent read()s returned 0, indicating there's no
      host-side connection (but not indicating the device went away).
      
      This also happened when a port was unplugged and the user didn't have
      any blocking operation pending.  If the user didn't monitor the SIGIO
      signal, they won't have a chance to find out if the port went away.
      
      Fix by returning -ENODEV on all read()s after the port gets unplugged.
      write() already behaves this way.
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a57425e9
    • Amit Shah's avatar
      virtio: console: fix raising SIGIO after port unplug · 183c6a6b
      Amit Shah authored
      commit 92d34538 upstream.
      
      SIGIO should be sent when a port gets unplugged.  It should only be sent
      to prcesses that have the port opened, and have asked for SIGIO to be
      delivered.  We were clearing out guest_connected before calling
      send_sigio_to_port(), resulting in a sigio not getting sent to
      processes.
      
      Fix by setting guest_connected to false after invoking the sigio
      function.
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      183c6a6b
    • Amit Shah's avatar
      virtio: console: clean up port data immediately at time of unplug · 9f92fafc
      Amit Shah authored
      commit ea3768b4 upstream.
      
      We used to keep the port's char device structs and the /sys entries
      around till the last reference to the port was dropped.  This is
      actually unnecessary, and resulted in buggy behaviour:
      
      1. Open port in guest
      2. Hot-unplug port
      3. Hot-plug a port with the same 'name' property as the unplugged one
      
      This resulted in hot-plug being unsuccessful, as a port with the same
      name already exists (even though it was unplugged).
      
      This behaviour resulted in a warning message like this one:
      
      -------------------8<---------------------------------------
      WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
      Hardware name: KVM
      sysfs: cannot create duplicate filename
      '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1'
      
      Call Trace:
       [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0
       [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50
       [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130
       [<ffffffff811f23e8>] ? create_dir+0x68/0xb0
       [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50
       [<ffffffff81273129>] ? kobject_add_internal+0xb9/0x260
       [<ffffffff812733d8>] ? kobject_add_varg+0x38/0x60
       [<ffffffff812734b4>] ? kobject_add+0x44/0x70
       [<ffffffff81349de4>] ? get_device_parent+0xf4/0x1d0
       [<ffffffff8134b389>] ? device_add+0xc9/0x650
      
      -------------------8<---------------------------------------
      
      Instead of relying on guest applications to release all references to
      the ports, we should go ahead and unregister the port from all the core
      layers.  Any open/read calls on the port will then just return errors,
      and an unplug/plug operation on the host will succeed as expected.
      
      This also caused buggy behaviour in case of the device removal (not just
      a port): when the device was removed (which means all ports on that
      device are removed automatically as well), the ports with active
      users would clean up only when the last references were dropped -- and
      it would be too late then to be referencing char device pointers,
      resulting in oopses:
      
      -------------------8<---------------------------------------
      PID: 6162   TASK: ffff8801147ad500  CPU: 0   COMMAND: "cat"
       #0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b
       #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322
       #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50
       #3 [ffff88011b9d5bf0] die at ffffffff8100f26b
       #4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2
       #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5
          [exception RIP: strlen+2]
          RIP: ffffffff81272ae2  RSP: ffff88011b9d5d00  RFLAGS: 00010246
          RAX: 0000000000000000  RBX: ffff880118901c18  RCX: 0000000000000000
          RDX: ffff88011799982c  RSI: 00000000000000d0  RDI: 3a303030302f3030
          RBP: ffff88011b9d5d38   R8: 0000000000000006   R9: ffffffffa0134500
          R10: 0000000000001000  R11: 0000000000001000  R12: ffff880117a1cc10
          R13: 00000000000000d0  R14: 0000000000000017  R15: ffffffff81aff700
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d
       #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551
       #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb
       #9 [ffff88011b9d5de0] device_del at ffffffff813440c7
      
      -------------------8<---------------------------------------
      
      So clean up when we have all the context, and all that's left to do when
      the references to the port have dropped is to free up the port struct
      itself.
      Reported-by: default avatarchayang <chayang@redhat.com>
      Reported-by: default avatarYOGANANTH SUBRAMANIAN <anantyog@in.ibm.com>
      Reported-by: default avatarFuXiangChun <xfu@redhat.com>
      Reported-by: default avatarQunfang Zhang <qzhang@redhat.com>
      Reported-by: default avatarSibiao Luo <sluo@redhat.com>
      Signed-off-by: default avatarAmit Shah <amit.shah@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f92fafc