1. 26 Sep, 2013 40 commits
    • Miklos Szeredi's avatar
      fuse: readdir: check for slash in names · 459c331d
      Miklos Szeredi authored
      commit efeb9e60
      
       upstream.
      
      Userspace can add names containing a slash character to the directory
      listing.  Don't allow this as it could cause all sorts of trouble.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      459c331d
    • Maxim Patlasov's avatar
      fuse: hotfix truncate_pagecache() issue · 125fe73b
      Maxim Patlasov authored
      commit 06a7c3c2
      
       upstream.
      
      The way how fuse calls truncate_pagecache() from fuse_change_attributes()
      is completely wrong. Because, w/o i_mutex held, we never sure whether
      'oldsize' and 'attr->size' are valid by the time of execution of
      truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
      released fc->lock in the middle of fuse_change_attributes(), we completely
      loose control of actions which may happen with given inode until we reach
      truncate_pagecache. The list of potentially dangerous actions includes
      mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.
      
      The typical outcome of doing truncate_pagecache() with outdated arguments
      is data corruption from user point of view. This is (in some sense)
      acceptable in cases when the issue is triggered by a change of the file on
      the server (i.e. externally wrt fuse operation), but it is absolutely
      intolerable in scenarios when a single fuse client modifies a file without
      any external intervention. A real life case I discovered by fsx-linux
      looked like this:
      
      1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
      FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
      2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
      to the server synchronously, then calls fuse_change_attributes(). The
      latter updates i_size, releases fc->lock, but before comparing oldsize vs
      attr->size..
      3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
      updating attributes and i_size, but now oldsize is equal to
      outarg.attr.size because i_size has just been updated (step 2). Hence,
      fuse_do_setattr() returns w/o calling truncate_pagecache().
      4. As soon as ftruncate(2) completes, the user extends file size by
      write(2) making a hole in the middle of file, then reads data from the hole
      either by read(2) or mmap-ed read. The user expects to get zero data from
      the hole, but gets stale data because truncate_pagecache() is not executed
      yet.
      
      The scenario above illustrates one side of the problem: not truncating the
      page cache even though we should. Another side corresponds to truncating
      page cache too late, when the state of inode changed significantly.
      Theoretically, the following is possible:
      
      1. As in the previous scenario fuse_dentry_revalidate() discovered that
      i_size changed (due to our own fuse_do_setattr()) and is going to call
      truncate_pagecache() for some 'new_size' it believes valid right now. But
      by the time that particular truncate_pagecache() is called ...
      2. fuse_do_setattr() returns (either having called truncate_pagecache() or
      not -- it doesn't matter).
      3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
      4. mmap-ed write makes a page in the extended region dirty.
      
      The result will be the lost of data user wrote on the fourth step.
      
      The patch is a hotfix resolving the issue in a simplistic way: let's skip
      dangerous i_size update and truncate_pagecache if an operation changing
      file size is in progress. This simplistic approach looks correct for the
      cases w/o external changes. And to handle them properly, more sophisticated
      and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
      postpone it until the issue is well discussed on the mailing list(s).
      
      Changed in v2:
       - improved patch description to cover both sides of the issue.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      125fe73b
    • Anand Avati's avatar
      fuse: invalidate inode attributes on xattr modification · d3ab0e6f
      Anand Avati authored
      commit d331a415
      
       upstream.
      
      Calls like setxattr and removexattr result in updation of ctime.
      Therefore invalidate inode attributes to force a refresh.
      Signed-off-by: default avatarAnand Avati <avati@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3ab0e6f
    • Maxim Patlasov's avatar
      fuse: postpone end_page_writeback() in fuse_writepage_locked() · 5063ec30
      Maxim Patlasov authored
      commit 4a4ac4eb
      
       upstream.
      
      The patch fixes a race between ftruncate(2), mmap-ed write and write(2):
      
      1) An user makes a page dirty via mmap-ed write.
      2) The user performs shrinking truncate(2) intended to purge the page.
      3) Before fuse_do_setattr calls truncate_pagecache, the page goes to
         writeback. fuse_writepage_locked fills FUSE_WRITE request and releases
         the original page by end_page_writeback.
      4) fuse_do_setattr() completes and successfully returns. Since now, i_mutex
         is free.
      5) Ordinary write(2) extends i_size back to cover the page. Note that
         fuse_send_write_pages do wait for fuse writeback, but for another
         page->index.
      6) fuse_writepage_locked proceeds by queueing FUSE_WRITE request.
         fuse_send_writepage is supposed to crop inarg->size of the request,
         but it doesn't because i_size has already been extended back.
      
      Moving end_page_writeback to the end of fuse_writepage_locked fixes the
      race because now the fact that truncate_pagecache is successfully returned
      infers that fuse_writepage_locked has already called end_page_writeback.
      And this, in turn, infers that fuse_flush_writepages has already called
      fuse_send_writepage, and the latter used valid (shrunk) i_size. write(2)
      could not extend it because of i_mutex held by ftruncate(2).
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5063ec30
    • Mark Brown's avatar
      clk: wm831x: Initialise wm831x pointer on init · 107bef86
      Mark Brown authored
      commit 08442ce9
      
       upstream.
      
      Otherwise any attempt to interact with the hardware will crash. This is
      what happens when drivers get written blind.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      107bef86
    • Brian Norris's avatar
      mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices · e8247a33
      Brian Norris authored
      commit 68e80780 upstream.
      
      The code for NAND_BUSWIDTH_AUTO is broken. According to Alexander:
      
        "I have a problem with attach NAND UBI in 16 bit mode.
         NAND works fine if I specify NAND_BUSWIDTH_16 option, but not
         working with NAND_BUSWIDTH_AUTO option. In second case NAND
         chip is identifyed with ONFI."
      
      See his report for the rest of the details:
      
        http://lists.infradead.org/pipermail/linux-mtd/2013-July/047515.html
      
      
      
      Anyway, the problem is that nand_set_defaults() is called twice, we
      intend it to reset the chip functions to their x16 buswidth verions
      if the buswidth changed from x8 to x16; however, nand_set_defaults()
      does exactly nothing if called a second time.
      
      Fix this by hacking nand_set_defaults() to reset the buswidth-dependent
      functions if they were set to the x8 version the first time. Note that
      this does not do anything to reset from x16 to x8, but that's not the
      supported use case for NAND_BUSWIDTH_AUTO anyway.
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Reported-by: default avatarAlexander Shiyan <shc_work@mail.ru>
      Tested-by: default avatarAlexander Shiyan <shc_work@mail.ru>
      Cc: Matthieu Castet <matthieu.castet@parrot.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8247a33
    • Grant Likely's avatar
      of: Fix missing memory initialization on FDT unflattening · 763532e9
      Grant Likely authored
      commit 0640332e upstream.
      
      Any calls to dt_alloc() need to be zeroed. This is a temporary fix, but
      the allocation function itself needs to zero memory before returning
      it. This is a follow up to patch 9e401275
      
      , "of: fdt: fix memory
      initialization for expanded DT" which fixed one call site but missed
      another.
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Acked-by: default avatarWladislav Wiebe <wladislav.kw@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      763532e9
    • Sergei Shtylyov's avatar
      mmc: tmio_mmc_dma: fix PIO fallback on SDHI · 4963c59a
      Sergei Shtylyov authored
      commit f936f9b6 upstream.
      
      I'm testing SH-Mobile SDHI driver in DMA mode with  a new DMA controller  using
      'bonnie++' and getting DMA error after which the tmio_mmc_dma.c code falls back
      to PIO but all commands time out after that.  It turned out that the fallback
      code calls tmio_mmc_enable_dma() with RX/TX channels already freed and pointers
      to them cleared, so that the function bails out early instead  of clearing the
      DMA bit in the CTL_DMA_ENABLE register. The regression was introduced by commit
      162f43e3
      
       (mmc: tmio: fix a deadlock).
      Moving tmio_mmc_enable_dma() calls to the top of the PIO fallback code in
      tmio_mmc_start_dma_{rx|tx}() helps.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Acked-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4963c59a
    • Josh Durgin's avatar
      rbd: fix I/O error propagation for reads · 3ed52a38
      Josh Durgin authored
      commit 17c1cc1d upstream.
      
      When a request returns an error, the driver needs to report the entire
      extent of the request as completed.  Writes already did this, since
      they always set xferred = length, but reads were skipping that step if
      an error other than -ENOENT occurred.  Instead, rbd would end up
      passing 0 xferred to blk_end_request(), which would always report
      needing more data.  This resulted in an assert failing when more data
      was required by the block layer, but all the object requests were
      done:
      
      [ 1868.719077] rbd: obj_request read result -108 xferred 0
      [ 1868.719077]
      [ 1868.719518] end_request: I/O error, dev rbd1, sector 0
      [ 1868.719739]
      [ 1868.719739] Assertion failure in rbd_img_obj_callback() at line 1736:
      [ 1868.719739]
      [ 1868.719739]   rbd_assert(more ^ (which == img_request->obj_request_count));
      
      Without this assert, reads that hit errors would hang forever, since
      the block layer considered them incomplete.
      
      Fixes: http://tracker.ceph.com/issues/5647
      
      Signed-off-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      Reviewed-by: default avatarAlex Elder <alex.elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ed52a38
    • majianpeng's avatar
    • Sage Weil's avatar
      libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc · bc2a0231
      Sage Weil authored
      commit 9542cf0b
      
       upstream.
      
      Fix a typo that used the wrong bitmask for the pg.seed calculation.  This
      is normally unnoticed because in most cases pg_num == pgp_num.  It is, however,
      a bug that is easily corrected.
      Signed-off-by: default avatarSage Weil <sage@inktank.com>
      Reviewed-by: default avatarAlex Elder <alex.elder@linary.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc2a0231
    • majianpeng's avatar
      libceph: unregister request in __map_request failed and nofail == false · d0bafacc
      majianpeng authored
      commit 73d9f7ee
      
       upstream.
      
      For nofail == false request, if __map_request failed, the caller does
      cleanup work, like releasing the relative pages.  It doesn't make any sense
      to retry this request.
      Signed-off-by: default avatarJianpeng Ma <majianpeng@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@inktank.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0bafacc
    • Richard Weinberger's avatar
      um: Implement probe_kernel_read() · 1e354b6b
      Richard Weinberger authored
      commit f75b1b1b
      
       upstream.
      
      UML needs it's own probe_kernel_read() to handle kernel
      mode faults correctly.
      The implementation uses mincore() on the host side to detect
      whether a page is owned by the UML kernel process.
      
      This fixes also a possible crash when sysrq-t is used.
      Starting with 3.10 sysrq-t calls probe_kernel_read() to
      read details from the kernel workers. As kernel worker are
      completely async pointers may turn NULL while reading them.
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Cc: <stian@nixia.no>
      Cc: <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e354b6b
    • Alex Deucher's avatar
      drm/edid: add quirk for Medion MD30217PG · 61bc1759
      Alex Deucher authored
      commit 118bdbd8
      
       upstream.
      
      This LCD monitor (1280x1024 native) has a completely
      bogus detailed timing (640x350@70hz).  User reports that
      1280x1024@60 has waves so prefer 1280x1024@75.
      
      Manufacturer: MED  Model: 7b8  Serial#: 99188
      Year: 2005  Week: 5
      EDID Version: 1.3
      Analog Display Input,  Input Voltage Level: 0.700/0.700 V
      Sync:  Separate
      Max Image Size [cm]: horiz.: 34  vert.: 27
      Gamma: 2.50
      DPMS capabilities: Off; RGB/Color Display
      First detailed timing is preferred mode
      redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
      blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
      Supported established timings:
      720x400@70Hz
      640x480@60Hz
      640x480@72Hz
      640x480@75Hz
      800x600@56Hz
      800x600@60Hz
      800x600@72Hz
      800x600@75Hz
      1024x768@60Hz
      1024x768@70Hz
      1024x768@75Hz
      1280x1024@75Hz
      Manufacturer's mask: 0
      Supported standard timings:
      Supported detailed timing:
      clock: 25.2 MHz   Image Size:  337 x 270 mm
      h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
      v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
      Monitor name: MD30217PG
      Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
      Serial No: 501099188
      EDID (in hex):
                00ffffffffffff0034a4b80774830100
                050f010368221b962a0c55a559479b24
                125054afcf00310a0101010101018180
                000000000000d60980a0205e63103060
                0200510e1100001e000000fc004d4433
                3032313750470a202020000000fd0038
                4c1e530e000a202020202020000000ff
                003530313039393138380a2020200078
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reported-by: friedrich@mailstation.de
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61bc1759
    • Borislav Petkov's avatar
      amd64_edac: Fix single-channel setups · dd311a3c
      Borislav Petkov authored
      commit f0a56c48
      
       upstream.
      
      It can happen that configurations are running in a single-channel mode
      even with a dual-channel memory controller, by, say, putting the DIMMs
      only on the one channel and leaving the other empty. This causes a
      problem in init_csrows which implicitly assumes that when the second
      channel is enabled, i.e. channel 1, the struct dimm hierarchy will be
      present. Which is not.
      
      So always allocate two channels unconditionally.
      
      This provides for the nice side effect that the data structures are
      initialized so some day, when memory hotplug is supported, it should
      just work out of the box when all of a sudden a second channel appears.
      Reported-and-tested-by: default avatarRoger Leigh <rleigh@debian.org>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd311a3c
    • Jan Kara's avatar
      isofs: Refuse RW mount of the filesystem instead of making it RO · 77ad400f
      Jan Kara authored
      commit 17b7f7cf
      
       upstream.
      
      Refuse RW mount of isofs filesystem. So far we just silently changed it
      to RO mount but when the media is writeable, block layer won't notice
      this change and thus will think device is used RW and will block eject
      button of the drive. That is unexpected by users because for
      non-writeable media eject button works just fine.
      
      Userspace mount(8) command handles this just fine and retries mounting
      with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
      tool mounting isofs is likely confronted with the case of read-only
      media where block layer already refuses to mount the filesystem without
      MS_RDONLY set so our behavior shouldn't be anything new for it.
      Reported-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      77ad400f
    • Eric W. Biederman's avatar
      proc: Restrict mounting the proc filesystem · 43be3c13
      Eric W. Biederman authored
      commit aee1c13d
      
       upstream.
      
      Don't allow mounting the proc filesystem unless the caller has
      CAP_SYS_ADMIN rights over the pid namespace.  The principle here is if
      you create or have capabilities over it you can mount it, otherwise
      you get to live with what other people have mounted.
      
      Andy pointed out that this is needed to prevent users in a user
      namespace from remounting proc and specifying different hidepid and gid
      options on already existing proc mounts.
      Reported-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43be3c13
    • Libin's avatar
      mm/huge_memory.c: fix potential NULL pointer dereference · edf125ce
      Libin authored
      commit a8f531eb
      
       upstream.
      
      In collapse_huge_page() there is a race window between releasing the
      mmap_sem read lock and taking the mmap_sem write lock, so find_vma() may
      return NULL.  So check the return value to avoid NULL pointer dereference.
      
      collapse_huge_page
      	khugepaged_alloc_page
      		up_read(&mm->mmap_sem)
      	down_write(&mm->mmap_sem)
      	vma = find_vma(mm, address)
      Signed-off-by: default avatarLibin <huawei.libin@huawei.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reviewed-by: default avatarWanpeng Li <liwanp@linux.vnet.ibm.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      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@linuxfoundation.org>
      edf125ce
    • Greg Thelen's avatar
      memcg: fix multiple large threshold notifications · 4b699f48
      Greg Thelen authored
      commit 2bff24a3 upstream.
      
      A memory cgroup with (1) multiple threshold notifications and (2) at least
      one threshold >=2G was not reliable.  Specifically the notifications would
      either not fire or would not fire in the proper order.
      
      The __mem_cgroup_threshold() signaling logic depends on keeping 64 bit
      thresholds in sorted order.  mem_cgroup_usage_register_event() sorts them
      with compare_thresholds(), which returns the difference of two 64 bit
      thresholds as an int.  If the difference is positive but has bit[31] set,
      then sort() treats the difference as negative and breaks sort order.
      
      This fix compares the two arbitrary 64 bit thresholds returning the
      classic -1, 0, 1 result.
      
      The test below sets two notifications (at 0x1000 and 0x81001000):
        cd /sys/fs/cgroup/memory
        mkdir x
        for x in 4096 2164264960; do
          cgroup_event_listener x/memory.usage_in_bytes $x | sed "s/^/$x listener:/" &
        done
        echo $$ > x/cgroup.procs
        anon_leaker 500M
      
      v3.11-rc7 fails to signal the 4096 event listener:
        Leaking...
        Done leaking pages.
      
      Patched v3.11-rc7 properly notifies:
        Leaking...
        4096 listener:2013:8:31:14:13:36
        Done leaking pages.
      
      The fixed bug is old.  It appears to date back to the introduction of
      memcg threshold notifications in v2.6.34-rc1-116-g2e72b634
      
       "memcg:
      implement memory thresholds"
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.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@linuxfoundation.org>
      4b699f48
    • Jie Liu's avatar
      ocfs2: fix the end cluster offset of FIEMAP · f0fbb71f
      Jie Liu authored
      commit 28e8be31 upstream.
      
      Call fiemap ioctl(2) with given start offset as well as an desired mapping
      range should show extents if possible.  However, we somehow figure out the
      end offset of mapping via 'mapping_end -= cpos' before iterating the
      extent records which would cause problems if the given fiemap length is
      too small to a cluster size, e.g,
      
      Cluster size 4096:
      debugfs.ocfs2 1.6.3
              Block Size Bits: 12   Cluster Size Bits: 12
      
      The extended fiemap test utility From David:
      https://gist.github.com/anonymous/6172331
      
      
      
      # dd if=/dev/urandom of=/ocfs2/test_file bs=1M count=1000
      # ./fiemap /ocfs2/test_file 4096 10
      start: 4096, length: 10
      File /ocfs2/test_file has 0 extents:
      #	Logical          Physical         Length           Flags
      	^^^^^ <-- No extent is shown
      
      In this case, at ocfs2_fiemap(): cpos == mapping_end == 1. Hence the
      loop of searching extent records was not executed at all.
      
      This patch remove the in question 'mapping_end -= cpos', and loops
      until the cpos is larger than the mapping_end as usual.
      
      # ./fiemap /ocfs2/test_file 4096 10
      start: 4096, length: 10
      File /ocfs2/test_file has 1 extents:
      #	Logical          Physical         Length           Flags
      0:	0000000000000000 0000000056a01000 0000000006a00000 0000
      Signed-off-by: default avatarJie Liu <jeff.liu@oracle.com>
      Reported-by: default avatarDavid Weber <wb@munzinger.de>
      Tested-by: default avatarDavid Weber <wb@munzinger.de>
      Cc: Sunil Mushran <sunil.mushran@gmail.com>
      Cc: Mark Fashen <mfasheh@suse.de>
      Cc: Joel Becker <jlbec@evilplan.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@linuxfoundation.org>
      f0fbb71f
    • Oleg Nesterov's avatar
      pidns: fix vfork() after unshare(CLONE_NEWPID) · f230d527
      Oleg Nesterov authored
      commit e79f525e upstream.
      
      Commit 8382fcac
      
       ("pidns: Outlaw thread creation after
      unshare(CLONE_NEWPID)") nacks CLONE_VM if the forking process unshared
      pid_ns, this obviously breaks vfork:
      
      	int main(void)
      	{
      		assert(unshare(CLONE_NEWUSER | CLONE_NEWPID) == 0);
      		assert(vfork() >= 0);
      		_exit(0);
      		return 0;
      	}
      
      fails without this patch.
      
      Change this check to use CLONE_SIGHAND instead.  This also forbids
      CLONE_THREAD automatically, and this is what the comment implies.
      
      We could probably even drop CLONE_SIGHAND and use CLONE_THREAD, but it
      would be safer to not do this.  The current check denies CLONE_SIGHAND
      implicitely and there is no reason to change this.
      
      Eric said "CLONE_SIGHAND is fine.  CLONE_THREAD would be even better.
      Having shared signal handling between two different pid namespaces is
      the case that we are fundamentally guarding against."
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reported-by: default avatarColin Walters <walters@redhat.com>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: default avatar"Eric W. Biederman" <ebiederm@xmission.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@linuxfoundation.org>
      f230d527
    • Eric W. Biederman's avatar
      pidns: Fix hang in zap_pid_ns_processes by sending a potentially extra wakeup · cbe0a23a
      Eric W. Biederman authored
      commit a6064885 upstream.
      
      Serge Hallyn <serge.hallyn@ubuntu.com> writes:
      
      > Since commit af4b8a83 it's been
      > possible to get into a situation where a pidns reaper is
      > <defunct>, reparented to host pid 1, but never reaped.  How to
      > reproduce this is documented at
      >
      > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526
      > (and see
      > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1168526/comments/13
      
      )
      > In short, run repeated starts of a container whose init is
      >
      > Process.exit(0);
      >
      > sysrq-t when such a task is playing zombie shows:
      >
      > [  131.132978] init            x ffff88011fc14580     0  2084   2039 0x00000000
      > [  131.132978]  ffff880116e89ea8 0000000000000002 ffff880116e89fd8 0000000000014580
      > [  131.132978]  ffff880116e89fd8 0000000000014580 ffff8801172a0000 ffff8801172a0000
      > [  131.132978]  ffff8801172a0630 ffff88011729fff0 ffff880116e14650 ffff88011729fff0
      > [  131.132978] Call Trace:
      > [  131.132978]  [<ffffffff816f6159>] schedule+0x29/0x70
      > [  131.132978]  [<ffffffff81064591>] do_exit+0x6e1/0xa40
      > [  131.132978]  [<ffffffff81071eae>] ? signal_wake_up_state+0x1e/0x30
      > [  131.132978]  [<ffffffff8106496f>] do_group_exit+0x3f/0xa0
      > [  131.132978]  [<ffffffff810649e4>] SyS_exit_group+0x14/0x20
      > [  131.132978]  [<ffffffff8170102f>] tracesys+0xe1/0xe6
      >
      > Further debugging showed that every time this happened, zap_pid_ns_processes()
      > started with nr_hashed being 3, while we were expecting it to drop to 2.
      > Any time it didn't happen, nr_hashed was 1 or 2.  So the reaper was
      > waiting for nr_hashed to become 2, but free_pid() only wakes the reaper
      > if nr_hashed hits 1.
      
      The issue is that when the task group leader of an init process exits
      before other tasks of the init process when the init process finally
      exits it will be a secondary task sleeping in zap_pid_ns_processes and
      waiting to wake up when the number of hashed pids drops to two.  This
      case waits forever as free_pid only sends a wake up when the number of
      hashed pids drops to 1.
      
      To correct this the simple strategy of sending a possibly unncessary
      wake up when the number of hashed pids drops to 2 is adopted.
      
      Sending one extraneous wake up is relatively harmless, at worst we
      waste a little cpu time in the rare case when a pid namespace
      appropaches exiting.
      
      We can detect the case when the pid namespace drops to just two pids
      hashed race free in free_pid.
      
      Dereferencing pid_ns->child_reaper with the pidmap_lock held is safe
      without out the tasklist_lock because it is guaranteed that the
      detach_pid will be called on the child_reaper before it is freed and
      detach_pid calls __change_pid which calls free_pid which takes the
      pidmap_lock.  __change_pid only calls free_pid if this is the
      last use of the pid.  For a thread that is not the thread group leader
      the threads pid will only ever have one user because a threads pid
      is not allowed to be the pid of a process, of a process group or
      a session.  For a thread that is a thread group leader all of
      the other threads of that process will be reaped before it is allowed
      for the thread group leader to be reaped ensuring there will only
      be one user of the threads pid as a process pid.  Furthermore
      because the thread is the init process of a pid namespace all of the
      other processes in the pid namespace will have also been already freed
      leading to the fact that the pid will not be used as a session pid or
      a process group pid for any other running process.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Tested-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Reported-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbe0a23a
    • Alex Williamson's avatar
      intel-iommu: Fix leaks in pagetable freeing · 33d979ef
      Alex Williamson authored
      commit 3269ee0b
      
       upstream.
      
      At best the current code only seems to free the leaf pagetables and
      the root.  If you're unlucky enough to have a large gap (like any
      QEMU guest with more than 3G of memory), only the first chunk of leaf
      pagetables are freed (plus the root).  This is a massive memory leak.
      This patch re-writes the pagetable freeing function to use a
      recursive algorithm and manages to not only free all the pagetables,
      but does it without any apparent performance loss versus the current
      broken version.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarJoerg Roedel <joro@8bytes.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33d979ef
    • Gera Kazakov's avatar
      target: Fix >= v3.9+ regression in PR APTPL + ALUA metadata write-out · 7c0f09b9
      Gera Kazakov authored
      commit f730f915 upstream.
      
      This patch fixes a >= v3.9+ regression in __core_scsi3_write_aptpl_to_file()
      + core_alua_write_tpg_metadata() write-out, where a return value of -EIO was
      incorrectly being returned upon success.
      
      This bug was originally introduced in:
      
      commit 0e9b10a9
      Author: Al Viro <viro@zeniv.linux.org.uk>
      Date:   Sat Feb 23 15:22:43 2013 -0500
      
          target: writev() on single-element vector is pointless
      
      However, given that the return of core_scsi3_update_and_write_aptpl()
      was not used to determine if a command should be returned with non GOOD
      status, this bug was not being triggered in PR logic until v3.11-rc1 by
      commit:
      
      commit 459f213b
      
      
      Author: Andy Grover <agrover@redhat.com>
      Date:   Thu May 16 10:41:02 2013 -0700
      
          target: Allocate aptpl_buf inside update_and_write_aptpl()
      
      So, go ahead and only return -EIO if kernel_write() returned a
      negative value.
      Reported-by: default avatarGera Kazakov <gkazakov@msn.com>
      Signed-off-by: default avatarGera Kazakov <gkazakov@msn.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Grover <agrover@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c0f09b9
    • Felix Fietkau's avatar
      MIPS: ath79: Fix ar933x watchdog clock · 2e7120ad
      Felix Fietkau authored
      commit a1191927 upstream.
      
      The watchdog device on the AR933x is connected to
      the AHB clock, however the current code uses the
      reference clock. Due to the wrong rate, the watchdog
      driver can't calculate correct register values for
      a given timeout value and the watchdog unexpectedly
      restarts the system.
      
      The code uses the wrong value since the initial
      commit 04225e1d
      
      
      (MIPS: ath79: add AR933X specific clock init)
      
      The patch fixes the code to use the correct clock
      rate to avoid the problem.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarGabor Juhos <juhosg@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5777/
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2e7120ad
    • Mark Brown's avatar
      leds: wm831x-status: Request a REG resource · e4ff584f
      Mark Brown authored
      commit 61abeba5
      
       upstream.
      
      The wm831x-status driver was not converted to use a REG resource when they
      were introduced and the rest of the wm831x drivers converted, causing it
      to fail to probe due to requesting the wrong resource type.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarBryan Wu <cooloney@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4ff584f
    • Oleg Nesterov's avatar
      uprobes: Fix utask->depth accounting in handle_trampoline() · 00338606
      Oleg Nesterov authored
      commit 878b5a6e
      
       upstream.
      
      Currently utask->depth is simply the number of allocated/pending
      return_instance's in uprobe_task->return_instances list.
      
      handle_trampoline() should decrement this counter every time we
      handle/free an instance, but due to typo it does this only if
      ->chained == T. This means that in the likely case this counter
      is never decremented and the probed task can't report more than
      MAX_URETPROBE_DEPTH events.
      Reported-by: default avatarMikhail Kulemin <Mikhail.Kulemin@ru.ibm.com>
      Reported-by: default avatarHemant Kumar Shaw <hkshaw@linux.vnet.ibm.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarAnton Arapov <anton@redhat.com>
      Cc: masami.hiramatsu.pt@hitachi.com
      Cc: srikar@linux.vnet.ibm.com
      Cc: systemtap@sourceware.org
      Link: http://lkml.kernel.org/r/20130911154726.GA8093@redhat.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      00338606
    • Stefan Behrens's avatar
      Btrfs: don't allow the replace procedure on read only filesystems · cc321317
      Stefan Behrens authored
      commit bbb651e4
      
       upstream.
      
      If you start the replace procedure on a read only filesystem, at
      the end the procedure fails to write the updated dev_items to the
      chunk tree. The problem is that this error is not indicated except
      for a WARN_ON(). If the user now thinks that everything was done
      as expected and destroys the source device (with mkfs or with a
      hammer). The next mount fails with "failed to read chunk root" and
      the filesystem is gone.
      
      This commit adds code to fail the attempt to start the replace
      procedure if the filesystem is mounted read-only.
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc321317
    • Bjørn Mork's avatar
      media: siano: fix divide error on 0 counters · f118b548
      Bjørn Mork authored
      commit ec532503 upstream.
      
      GIT_AUTHOR_DATE=1376465691
      I took a quick look at the code and wonder if the problem is caused by
      an initial zero statistics message?  This is all just a wild guess, but
      if it is correct, then the attached untested patch might fix it...
      Bjørn
      >From d78a0599d5b5d4da384eae08bf7da316389dfbe5 Mon Sep 17 00:00:00 2001
      ts_packets and ets_packets counters can be 0.  Don't fall over
      if they are. Fixes:
      [  846.851711] divide error: 0000 [#1] SMP
      [  846.851806] Modules linked in: smsdvb dvb_core ir_lirc_codec lirc_dev ir_sanyo_decoder ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_hauppauge smsusb smsmdtv rc_core pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) parport_pc ppdev lp parport cpufreq_userspace cpufreq_powersave cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd dns_resolver fscache sunrpc ext4 jbd2 fuse tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 dm_crypt snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm thinkpad_acpi nvram snd_page_alloc hid_generic snd_seq_midi snd_seq_midi_event arc4 usbhid snd_rawmidi uvcvideo hid iwldvm coretemp kvm_intel mac8021
       1 cdc_wdm
      [  846.853477]  cdc_acm snd_seq videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media kvm radeon r852 ttm joydev cdc_ether usbnet pcmcia mii sm_common nand btusb drm_kms_helper tpm_tis acpi_cpufreq bluetooth iwlwifi nand_ecc drm nand_ids i2c_i801 mtd snd_seq_device iTCO_wdt iTCO_vendor_support r592 memstick lpc_ich mperf tpm yenta_socket pcmcia_rsrc pcmcia_core cfg80211 snd_timer snd pcspkr i2c_algo_bit crc16 i2c_core tpm_bios processor mfd_core wmi psmouse mei_me rfkill mei serio_raw soundcore evdev battery button video ac microcode ext3 mbcache jbd md_mod dm_mirror dm_region_hash dm_log dm_mod sg sr_mod sd_mod cdrom crc_t10dif firewire_ohci sdhci_pci sdhci mmc_core firewire_core crc_itu_t thermal thermal_sys ahci libahci ehci_pci uhci_hcd ehci_hcd libata scsi_mod usbcore e1000
       e usb_common
      [  846.855310]  ptp pps_core
      [  846.855356] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O 3.10-2-amd64 #1 Debian 3.10.5-1
      [  846.855490] Hardware name: LENOVO 4061WFA/4061WFA, BIOS 6FET92WW (3.22 ) 12/14/2011
      [  846.855609] task: ffffffff81613400 ti: ffffffff81600000 task.ti: ffffffff81600000
      [  846.855636] RIP: 0010:[<ffffffffa092be0c>]  [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
      [  846.863906] RSP: 0018:ffff88013bc03cf0  EFLAGS: 00010046
      [  846.863906] RAX: 0000000000000000 RBX: ffff880133bf6000 RCX: 0000000000000000
      [  846.863906] RDX: 0000000000000000 RSI: ffff88005d3b58c0 RDI: ffff880133bf6000
      [  846.863906] RBP: ffff88005d1da000 R08: 0000000000000058 R09: 0000000000000015
      [  846.863906] R10: 0000000000001a0d R11: 000000000000021a R12: ffff88005d3b58c0
      [  846.863906] R13: ffff88005d1da008 R14: 00000000ffffff8d R15: ffff880036cf5060
      [  846.863906] FS:  0000000000000000(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000
      [  846.863906] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  846.863906] CR2: 00007f3a4b69ae50 CR3: 0000000036dac000 CR4: 00000000000407f0
      [  846.863906] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  846.863906] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  846.863906] Stack:
      [  846.863906]  ffff88007a102000 ffff88005d1da000 ffff88005d3b58c0 0000000000085824
      [  846.863906]  ffffffffa08c5aa3 ffff88005d1da000 ffff8800a6907390 ffff8800a69073b0
      [  846.863906]  ffff8800a6907000 ffffffffa08b642c 000000000000021a ffff8800a69073b0
      [  846.863906] Call Trace:
      [  846.863906]  <IRQ>
      [  846.863906]
      [  846.863906]  [<ffffffffa08c5aa3>] ? smscore_onresponse+0x1d5/0x353 [smsmdtv]
      [  846.863906]  [<ffffffffa08b642c>] ? smsusb_onresponse+0x146/0x192 [smsusb]
      [  846.863906]  [<ffffffffa004cb1a>] ? usb_hcd_giveback_urb+0x6c/0xac [usbcore]
      [  846.863906]  [<ffffffffa0217be1>] ? ehci_urb_done+0x62/0x72 [ehci_hcd]
      [  846.863906]  [<ffffffffa0217c82>] ? qh_completions+0x91/0x364 [ehci_hcd]
      [  846.863906]  [<ffffffffa0219bba>] ? ehci_work+0x8a/0x68e [ehci_hcd]
      [  846.863906]  [<ffffffff8107336c>] ? timekeeping_get_ns.constprop.10+0xd/0x31
      [  846.863906]  [<ffffffff81064d41>] ? update_cfs_rq_blocked_load+0xde/0xec
      [  846.863906]  [<ffffffff81058ec2>] ? run_posix_cpu_timers+0x25/0x575
      [  846.863906]  [<ffffffffa021aa46>] ? ehci_irq+0x211/0x23d [ehci_hcd]
      [  846.863906]  [<ffffffffa004c0c1>] ? usb_hcd_irq+0x31/0x48 [usbcore]
      [  846.863906]  [<ffffffff810996fd>] ? handle_irq_event_percpu+0x49/0x1a4
      [  846.863906]  [<ffffffff8109988a>] ? handle_irq_event+0x32/0x4b
      [  846.863906]  [<ffffffff8109bd76>] ? handle_fasteoi_irq+0x80/0xb6
      [  846.863906]  [<ffffffff8100e93e>] ? handle_irq+0x18/0x20
      [  846.863906]  [<ffffffff8100e657>] ? do_IRQ+0x40/0x95
      [  846.863906]  [<ffffffff813883ed>] ? common_interrupt+0x6d/0x6d
      [  846.863906]  <EOI>
      [  846.863906]
      [  846.863906]  [<ffffffff812a011c>] ? arch_local_irq_enable+0x4/0x8
      [  846.863906]  [<ffffffff812a04f3>] ? cpuidle_enter_state+0x52/0xc1
      [  846.863906]  [<ffffffff812a0636>] ? cpuidle_idle_call+0xd4/0x143
      [  846.863906]  [<ffffffff8101398c>] ? arch_cpu_idle+0x5/0x17
      [  846.863906]  [<ffffffff81072571>] ? cpu_startup_entry+0x10d/0x187
      [  846.863906]  [<ffffffff816b3d3d>] ? start_kernel+0x3e8/0x3f3
      [  846.863906]  [<ffffffff816b3777>] ? repair_env_string+0x54/0x54
      [  846.863906]  [<ffffffff816b3598>] ? x86_64_start_kernel+0xf2/0xfd
      [  846.863906] Code: 25 09 00 00 c6 83 da 08 00 00 03 8b 45 54 48 01 83 b6 08 00 00 8b 45 50 48 01 83 db 08 00 00 8b 4d 18 69 c1 ff ff 00 00 03 4d 14 <48> f7 f1 89 83 a8 09 00 00 e9 68 fe ff ff 48 8b 7f 10 e8 79 92
      [  846.863906] RIP  [<ffffffffa092be0c>] smsdvb_onresponse+0x264/0xa86 [smsdvb]
      [  846.863906]  RSP <ffff88013bc03cf0>
      Reference: http://bugs.debian.org/719623
      
      Reported-by: default avatarJohannes Rohr <jorohr@gmail.com>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f118b548
    • Mauro Carvalho Chehab's avatar
      media: mb86a20s: Fix TS parallel mode · 7c33812d
      Mauro Carvalho Chehab authored
      commit 9d32069f upstream.
      
      changeset 768e6dad
      
       caused a regression on using mb86a20s
      in parallel mode, as the parallel mode selection got
      overriden by mb86a20s_init2.
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c33812d
    • Hans Verkuil's avatar
      media: cx88: Fix regression: CX88_AUDIO_WM8775 can't be 0 · 1e4508a3
      Hans Verkuil authored
      commit f66b2a1c upstream.
      
      Cards using the wm8775 specify that in their card struct. Those that do not
      use it leave the audio_chip field to 0. Unfortunately, the CX88_AUDIO_WM8775
      enum is 0 as well, so boards that do not have the wm8775 still try to load
      and use that driver. Change it to 1 to fix this.
      This regression was introduced in commit facd2366
      
      .
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Tested-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e4508a3
    • Sylwester Nawrocki's avatar
      media: exynos4-is: Fix entity unregistration on error path · 098b05d9
      Sylwester Nawrocki authored
      commit d2b903b4
      
       upstream.
      
      This patch corrects media entities unregistration order to make sure
      the fimc.N.capture and fimc-lite video nodes are unregistered with
      fimc->lock mutex held. This prevents races between video device open()
      and defered probing and NULL pointer dereference in open() callback
      as follows:
      [   77.645000] Unable to handle kernel NULL pointer dereference at virtual address 00000290t
      [   77.655000] pgd = ee7a8000
      [   77.660000] [00000290] *pgd=6e13c831, *pte=00000000, *ppte=00000000
      [   77.665000] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      [   77.670000] Modules linked in: s5p_fimc ipv6 exynos_fimc_is exynos_fimc_lite
       s5p_csis v4l2_mem2mem videobuf2_dma_contig videobuf2_memops exynos4_is_common videobuf2_core [last unloaded: s5p_fimc]
      [   77.685000] CPU: 0 PID : 2998 Comm: v4l_id Tainted: G        W   3.10.0-next-20130709-00039-g39f491b-dirty #1548
      [   77.695000] task: ee084000 ti: ee46e000 task.ti: ee46e000
      [   77.700000] PC is at __mutex_lock_slowpath+0x54/0x368
      [   77.705000] LR is at __mutex_lock_slowpath+0x24/0x368
      [   77.710000] pc : [<c038dc10>]    lr : [<c038dbe0>]    psr: 60000093
      [   77.710000] sp : ee46fd70  ip : 000008c8  fp : c054e34c
      [   77.725000] r10: ee084000  r9 : 00000000  r8 : ee439480
      [   77.730000] r7 : ee46e000  r6 : 60000013  r5 : 00000290  r4 : 0000028c
      [   77.735000] r3 : 00000000  r2 : 00000000  r1 : 20000093  r0 : 00000001
      [   77.740000] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment user
      [   77.750000] Control: 10c5387d  Table: 6e7a804a  DAC: 00000015
      [   77.755000] Process v4l_id (pid: 2998, stack limit = 0xee46e238)
      [   77.760000] Stack: (0xee46fd70 to 0xee470000)
          	       ...
      [   77.935000] [<c038dc10>] (__mutex_lock_slowpath+0x54/0x368) from [<c038df30>] (mutex_lock+0xc/0x24)
      [   77.945000] [<c038df30>] (mutex_lock+0xc/0x24) from [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite])
      [   77.955000] [<bf03fa90>] (fimc_lite_open+0x12c/0x2bc [exynos_fimc_lite]) from [<c02ab11c>] (v4l2_open+0xa0/0xe0)
      [   77.965000] [<c02ab11c>] (v4l2_open+0xa0/0xe0) from [<c00b1de4>] (chrdev_open+0x88/0x170)
      [   77.975000] [<c00b1de4>] (chrdev_open+0x88/0x170) from [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258)
      [   77.985000] [<c00ac710>] (do_dentry_open.isra.14+0x1d8/0x258) from [<c00ac860>] (finish_open+0x20/0x38)
      [   77.995000] [<c00ac860>] (finish_open+0x20/0x38) from [<c00ba658>] (do_last.isra.43+0x538/0xb1c)
      [   78.000000] [<c00ba658>] (do_last.isra.43+0x538/0xb1c) from [<c00bacf0>] (path_openat+0xb4/0x5c4)
      [   78.010000] [<c00bacf0>] (path_openat+0xb4/0x5c4) from [<c00bb4b4>] (do_filp_open+0x2c/0x80)
      [   78.020000] [<c00bb4b4>] (do_filp_open+0x2c/0x80) from [<c00ad744>] (do_sys_open+0xf4/0x1a8)
      [   78.025000] [<c00ad744>] (do_sys_open+0xf4/0x1a8) from [<c000e320>] (ret_fast_syscall+0x0/0x30)
      [   78.035000] Code: 1a000093 e10f6000 f10c0080 e2845004 (e1953f9f)
      Reported-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      098b05d9
    • Arun Kumar K's avatar
      media: exynos-gsc: Register v4l2 device · 51a94c0a
      Arun Kumar K authored
      commit d0b1c313 upstream.
      
      Gscaler video device registration was happening without reference to
      a parent v4l2_dev causing probe to fail. The patch creates a parent
      v4l2 device and uses it for the gsc m2m video device registration.
      This fixes regression introduced with comit commit 1c1d86a1
      
      
      [media] v4l2: always require v4l2_dev, rename parent to dev_parent
      Signed-off-by: default avatarArun Kumar K <arun.kk@samsung.com>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51a94c0a
    • Arun Kumar K's avatar
      media: exynos4-is: Fix fimc-lite bayer formats · 04d49c32
      Arun Kumar K authored
      commit 3396b096
      
       upstream.
      
      The 10-bit and 12-bit Bayer output formats supported by FIMC-LITE
      actually use 16 bits where the extra bits are padded with zeros.
      The patch corrects buffer allocation for these two formats by
      modifying the depth field. This prevents memory corruption by the
      output DMA due to insufficient buffer size.
      Signed-off-by: default avatarArun Kumar K <arun.kk@samsung.com>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04d49c32
    • Vasily Titskiy's avatar
      HID: usbhid: quirk for N-Trig DuoSense Touch Screen · c2bb0ac1
      Vasily Titskiy authored
      commit 9e0bf92c
      
       upstream.
      
      The DuoSense touchscreen device causes a 10 second timeout. This fix
      removes the delay.
      Signed-off-by: default avatarVasily Titskiy <qehgt0@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2bb0ac1
    • Kees Cook's avatar
      HID: check for NULL field when setting values · b78f2050
      Kees Cook authored
      commit be67b68d
      
       upstream.
      
      Defensively check that the field to be worked on is not NULL.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b78f2050
    • Manoj Chourasia's avatar
      HID: hidraw: correctly deallocate memory on device disconnect · 11c32876
      Manoj Chourasia authored
      commit 212a871a upstream.
      
      This changes puts the commit 4fe9f8e2 back in place
      with the fixes for slab corruption because of the commit.
      
      When a device is unplugged, wait for all processes that
      have opened the device to close before deallocating the device.
      
      This commit was solving kernel crash because of the corruption in
      rb tree of vmalloc. The rootcause was the device data pointer was
      geting excessed after the memory associated with hidraw was freed.
      
      The commit 4fe9f8e2
      
       was buggy as it was also freeing the hidraw
      first and then calling delete operation on the list associated with
      that hidraw leading to slab corruption.
      Signed-off-by: default avatarManoj Chourasia <mchourasia@nvidia.com>
      Tested-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11c32876
    • Jiri Kosina's avatar
      HID: battery: don't do DMA from stack · f0c298af
      Jiri Kosina authored
      commit 6c2794a2
      
       upstream.
      
      Instead of using data from stack for DMA in hidinput_get_battery_property(),
      allocate the buffer dynamically.
      Reported-by: default avatarRichard Ryniker <ryniker@alum.mit.edu>
      Reported-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0c298af
    • Bruno Prémont's avatar
      HID: picolcd: Prevent NULL pointer dereference on _remove() · 67940228
      Bruno Prémont authored
      commit 1cde501b
      
       upstream.
      
      When picolcd is switched into bootloader mode (for FW flashing) make
      sure not to try to dereference NULL-pointers of feature-devices during
      unplug/unbind.
      
      This fixes following BUG:
        BUG: unable to handle kernel NULL pointer dereference at 00000298
        IP: [<f811f56b>] picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
        *pde = 00000000
        Oops: 0000 [#1]
        Modules linked in: hid_picolcd syscopyarea sysfillrect sysimgblt fb_sys_fops
        CPU: 0 PID: 15 Comm: khubd Not tainted 3.11.0-rc7-00002-g50d62d4 #2
        EIP: 0060:[<f811f56b>] EFLAGS: 00010292 CPU: 0
        EIP is at picolcd_exit_framebuffer+0x1b/0x80 [hid_picolcd]
        Call Trace:
         [<f811d1ab>] picolcd_remove+0xcb/0x120 [hid_picolcd]
         [<c1469b09>] hid_device_remove+0x59/0xc0
         [<c13464ca>] __device_release_driver+0x5a/0xb0
         [<c134653f>] device_release_driver+0x1f/0x30
         [<c134603d>] bus_remove_device+0x9d/0xd0
         [<c13439a5>] device_del+0xd5/0x150
         [<c14696a4>] hid_destroy_device+0x24/0x60
         [<c1474cbb>] usbhid_disconnect+0x1b/0x40
         ...
      Signed-off-by: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67940228
    • Kees Cook's avatar
      HID: ntrig: validate feature report details · fced5ced
      Kees Cook authored
      commit 875b4e37
      
       upstream.
      
      A HID device could send a malicious feature report that would cause the
      ntrig HID driver to trigger a NULL dereference during initialization:
      
      [57383.031190] usb 3-1: New USB device found, idVendor=1b96, idProduct=0001
      ...
      [57383.315193] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
      [57383.315308] IP: [<ffffffffa08102de>] ntrig_probe+0x25e/0x420 [hid_ntrig]
      
      CVE-2013-2896
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarRafi Rubin <rafi@seas.upenn.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fced5ced