1. 08 4月, 2013 15 次提交
  2. 03 4月, 2013 13 次提交
  3. 02 4月, 2013 2 次提交
    • A
      loop: prevent bdev freeing while device in use · c1681bf8
      Anatol Pomozov 提交于
      struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
      block_device allocated first time we access /dev/loopXX and deallocated on
      bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
      we want that block_device stay alive until we destroy the loop device
      with "losetup -d".
      
      But because we do not hold /dev/loopXX inode its counter goes 0, and
      inode/bdev can be destroyed at any moment. Usually it happens at memory
      pressure or when user drops inode cache (like in the test below). When later in
      loop_clr_fd() we want to use bdev we have use-after-free error with following
      stack:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
        bd_set_size+0x10/0xa0
        loop_clr_fd+0x1f8/0x420 [loop]
        lo_ioctl+0x200/0x7e0 [loop]
        lo_compat_ioctl+0x47/0xe0 [loop]
        compat_blkdev_ioctl+0x341/0x1290
        do_filp_open+0x42/0xa0
        compat_sys_ioctl+0xc1/0xf20
        do_sys_open+0x16e/0x1d0
        sysenter_dispatch+0x7/0x1a
      
      To prevent use-after-free we need to grab the device in loop_set_fd()
      and put it later in loop_clr_fd().
      
      The issue is reprodusible on current Linus head and v3.3. Here is the test:
      
        dd if=/dev/zero of=loop.file bs=1M count=1
        while [ true ]; do
          losetup /dev/loop0 loop.file
          echo 2 > /proc/sys/vm/drop_caches
          losetup -d /dev/loop0
        done
      
      [ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
        time we call loop_set_fd() we check that loop_device->lo_state is
        Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
        it will get EBUSY.  And if we try to loop_clr_fd() on unbound loop
        device we'll get ENXIO.
      
        loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
        loop_device->lo_ctl_mutex. ]
      Signed-off-by: NAnatol Pomozov <anatol.pomozov@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c1681bf8
    • T
      clk: tegra: Allow PLLE training to succeed · 0f1bc12e
      Thierry Reding 提交于
      Under some circumstances the PLLE needs to be retrained, in which case
      access to the PMC registers is required. Fix this by passing a pointer
      to the PMC registers instead of NULL when registering the PLLE clock.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      Acked-By: NPeter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: NMike Turquette <mturquette@linaro.org>
      0f1bc12e
  4. 01 4月, 2013 4 次提交
    • J
      DM9000B: driver initialization upgrade · 6741f40d
      Joseph CHANG 提交于
      Fix bug for DM9000 revision B which contain a DSP PHY
      
      DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY,
      So need extra change in initialization, For
      explicity PHY Reset and PHY init parameter, and
      first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe().
      
      Following DM9000_NCR reset cause by dm9000_open() clear the
      NCR_MAC_LBK bit.
      
      Without this fix, Power-up FIFO pointers error happen around 2%
      rate among Davicom's customers' boards. With this fix, All above
      cases can be solved.
      Signed-off-by: NJoseph CHANG <josright123@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6741f40d
    • S
      sh_eth: make 'link' field of 'struct sh_eth_private' *int* · 3340d2aa
      Sergei Shtylyov 提交于
      The 'link' field of 'struct sh_eth_private' has type 'enum phy_state' while the
      'link' field of 'struct phy_device' is merely *int* (having values 0 and 1) and
      the former field gets assigned from the latter. Make the field match, getting
      rid of incorrectly used PHY_DOWN value in assignments/comparisons.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3340d2aa
    • S
      sh_eth: workaround for spurious ECI interrupt · 3893b273
      Sergei Shtylyov 提交于
      At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its
      mask in EESIPR register. I can 100% reproduce it with the following scenario:
      target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device
      but doesn't get a proper reply and then succeeds with on-board SMC chip; then
      I login and try to bring up the SoC Ether device with 'ifconfig', and I get
      an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt
      mask in EESIPR register is all 0), if that interrupt is accompanied by a pending
      EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx()
      because sh_eth_ring_init() hasn't been called yet!
      
      The solution I worked out is the following: in sh_eth_interrupt(), mask the
      interrupt status from EESR register with the interrupt mask from EESIPR register
      in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit
      in this mask set because we always need to fully handle EESR.ECI interrupt in
      sh_eth_error() in order to quench it (as it doesn't get cleared by just writing
      1 to the this bit as all the other interrupts).
      
      While at it, remove unneeded initializer for 'intr_status' variable and give it
      *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: NMax Filippov <max.filippov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3893b273
    • S
      sh_eth: fix handling of no LINK signal · 1e1b812b
      Sergei Shtylyov 提交于
      The code handling the absent LINK signal (or the absent PSR register -- which
      reflects the state of this signal) is quite naive and has probably never really
      worked.  It's probably enough to say that this code is executed only on the LINK
      change interrupt (sic!) but even if we actually have the signal and choose to
      ignore it (it might be connected to PHY's link/activity LED output as on the
      Renesas BOCK-W board), sh_eth_adjust_link() on which this code relies to update
      'mdp->link' gets executed later than the LINK change interrupt where it is
      checked, and so RX/TX never get enabled via ECMR register.
      
      So, ignore the LINK changed interrupt iff LINK signal is absent (or just chosen
      not to be used) or PSR register is absent, and enable/disable RX/TX directly in
      sh_eth_adjust_link() in this case.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e1b812b
  5. 31 3月, 2013 2 次提交
  6. 30 3月, 2013 4 次提交