1. 30 8月, 2017 28 次提交
  2. 21 8月, 2017 1 次提交
  3. 09 8月, 2017 2 次提交
    • M
      mmc: block: fix lockdep splat when removing mmc_block module · 3f8b23a0
      Michał Mirosław 提交于
      Fix lockdep splat introduced in v4.13-rc4.
      
      [  266.297226] ------------[ cut here ]------------
      [  266.300078] WARNING: CPU: 2 PID: 176 at /mnt/src/jaja/git/tf300t/include/linux/blkdev.h:657 mmc_blk_remove_req+0xd0/0xe8 [mmc_block]
      [  266.302937] Modules linked in: mmc_block(-) sdhci_tegra sdhci_pltfm sdhci pwrseq_simple pwrseq_emmc mmc_core
      [  266.305941] CPU: 2 PID: 176 Comm: rmmod Tainted: G        W       4.13.0-rc4mq-00208-gb691e67724b8-dirty #694
      [  266.308852] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
      [  266.311719] [<b011144c>] (unwind_backtrace) from [<b010ca54>] (show_stack+0x18/0x1c)
      [  266.314664] [<b010ca54>] (show_stack) from [<b062e3f4>] (dump_stack+0x84/0x98)
      [  266.317644] [<b062e3f4>] (dump_stack) from [<b01214f4>] (__warn+0xf4/0x10c)
      [  266.320542] [<b01214f4>] (__warn) from [<b01215d4>] (warn_slowpath_null+0x28/0x30)
      [  266.323534] [<b01215d4>] (warn_slowpath_null) from [<af067858>] (mmc_blk_remove_req+0xd0/0xe8 [mmc_block])
      [  266.326568] [<af067858>] (mmc_blk_remove_req [mmc_block]) from [<af068f40>] (mmc_blk_remove_parts.constprop.6+0x50/0x64 [mmc_block])
      [  266.329678] [<af068f40>] (mmc_blk_remove_parts.constprop.6 [mmc_block]) from [<af0693b8>] (mmc_blk_remove+0x24/0x140 [mmc_block])
      [  266.332894] [<af0693b8>] (mmc_blk_remove [mmc_block]) from [<af0052ec>] (mmc_bus_remove+0x20/0x28 [mmc_core])
      [  266.336198] [<af0052ec>] (mmc_bus_remove [mmc_core]) from [<b046aa64>] (device_release_driver_internal+0x164/0x200)
      [  266.339367] [<b046aa64>] (device_release_driver_internal) from [<b046ab54>] (driver_detach+0x40/0x74)
      [  266.342537] [<b046ab54>] (driver_detach) from [<b046982c>] (bus_remove_driver+0x68/0xdc)
      [  266.345660] [<b046982c>] (bus_remove_driver) from [<af06ad40>] (mmc_blk_exit+0xc/0x2cc [mmc_block])
      [  266.348875] [<af06ad40>] (mmc_blk_exit [mmc_block]) from [<b01aee30>] (SyS_delete_module+0x1c4/0x254)
      [  266.352068] [<b01aee30>] (SyS_delete_module) from [<b0108480>] (ret_fast_syscall+0x0/0x34)
      [  266.355308] ---[ end trace f68728a0d3053b72 ]---
      
      Fixes: 7c84b8b4 ("mmc: block: bypass the queue even if usage is present for hotplug")
      Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3f8b23a0
    • H
      mmc: mmc: correct the logic for setting HS400ES signal voltage · 92ddd959
      Haibo Chen 提交于
      Change the default err value to -EINVAL, make sure the card only
      has type EXT_CSD_CARD_TYPE_HS400_1_8V also do the signal voltage
      setting when select hs400es mode.
      
      Fixes: commit 1720d354 ("mmc: core: switch to 1V8 or 1V2 for hs400es mode")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
      Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      92ddd959
  4. 08 8月, 2017 1 次提交
  5. 03 8月, 2017 2 次提交
    • S
      mmc: block: bypass the queue even if usage is present for hotplug · 7c84b8b4
      Shawn Lin 提交于
      The commit 304419d8 ("mmc: core: Allocate per-request data using the
      block layer core") refactored mechanism of queue handling caused
      mmc_init_request() can be called just after mmc_cleanup_queue() caused null
      pointer dereference.
      
      Another commit bbdc74dc ("mmc: block: Prevent new req entering queue
      after its cleanup") tried to fix the problem. However it actually miss one
      corner case.
      
      We could still reproduce the issue mentioned with these steps:
      (1) insert a SD card and mount it
      (2) hotplug it, so it will leave md->usage still be counted
      (3) reboot the system which will sync data and umount the card
      
      [Unable to handle kernel NULL pointer dereference at virtual address
      00000000
      [user pgtable: 4k pages, 48-bit VAs, pgd = ffff80007bab3000
      [[0000000000000000] *pgd=000000007a828003, *pud=0000000078dce003,
      *pmd=000000007aab6003, *pte=0000000000000000
      [Internal error: Oops: 96000007 [#1] PREEMPT SMP
      [Modules linked in:
      [CPU: 3 PID: 3507 Comm: umount Tainted: G        W
      4.13.0-rc1-next-20170720-00012-g9d9bf45 #33
      [Hardware name: Firefly-RK3399 Board (DT)
      [task: ffff80007a1de200 task.stack: ffff80007a01c000
      [PC is at mmc_init_request+0x14/0xc4
      [LR is at alloc_request_size+0x4c/0x74
      [pc : [<ffff0000087d7150>] lr : [<ffff000008378fe0>] pstate: 600001c5
      [sp : ffff80007a01f8f0
      
      ....
      
      [[<ffff0000087d7150>] mmc_init_request+0x14/0xc4
      [[<ffff000008378fe0>] alloc_request_size+0x4c/0x74
      [[<ffff00000817ac28>] mempool_create_node+0xb8/0x17c
      [[<ffff00000837aadc>] blk_init_rl+0x9c/0x120
      [[<ffff000008396580>] blkg_alloc+0x110/0x234
      [[<ffff000008396ac8>] blkg_create+0x424/0x468
      [[<ffff00000839877c>] blkg_lookup_create+0xd8/0x14c
      [[<ffff0000083796bc>] generic_make_request_checks+0x368/0x3b0
      [[<ffff00000837b050>] generic_make_request+0x1c/0x240
      
      So mmc_blk_put wouldn't calling blk_cleanup_queue which actually the
      QUEUE_FLAG_DYING and QUEUE_FLAG_BYPASS should stay. Block core expect
      blk_queue_bypass_{start, end} internally to bypass/drain the queue before
      actually dying the queue, so it didn't expose API to set the queue bypass.
      I think we should set QUEUE_FLAG_BYPASS whenever queue is removed, although
      the md->usage is still counted, as no dispatch queue could be found then.
      
      Fixes: 304419d8 ("mmc: core: Allocate per-request data using the block layer core")
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      7c84b8b4
    • L
      mmc: sdhci-of-at91: force card detect value for non removable devices · 7a1e3f14
      Ludovic Desroches 提交于
      When the device is non removable, the card detect signal is often used
      for another purpose i.e. muxed to another SoC peripheral or used as a
      GPIO. It could lead to wrong behaviors depending the default value of
      this signal if not muxed to the SDHCI controller.
      
      Fixes: bb5f8ea4 ("mmc: sdhci-of-at91: introduce driver for the Atmel SDMMC")
      Signed-off-by: NLudovic Desroches <ludovic.desroches@microchip.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      7a1e3f14
  6. 27 7月, 2017 1 次提交
  7. 17 7月, 2017 2 次提交
  8. 13 7月, 2017 3 次提交
    • C
      mmc: tmio-mmc: fix bad pointer math · 9c284c41
      Chris Brandt 提交于
      The existing code gives an incorrect pointer value.
      The buffer pointer 'buf' was of type unsigned short *, and 'count' was a
      number in bytes. A cast of buf should have been used.
      
      However, instead of casting, just change the code to use u32 pointers.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 8185e51f: ("mmc: tmio-mmc: add support for 32bit data port")
      Signed-off-by: NChris Brandt <chris.brandt@renesas.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9c284c41
    • G
      mmc: block: Prevent new req entering queue after its cleanup · bbdc74dc
      Grzegorz Sluja 提交于
      The commit 304419d8 ("mmc: core: Allocate per-request data using the
      block layer core"), refactored the mechanism of queue handling, but also
      made mmc_init_request() to be called after mmc_cleanup_queue(). This
      triggers a null pointer dereference:
      
      [  683.123791] BUG: unable to handle kernel NULL pointer dereference at (null)
      [  683.123801] IP: mmc_init_request+0x2c/0xf0 [mmc_block]
      ...
      [  683.123905] Call Trace:
      [  683.123913]  alloc_request_size+0x4f/0x70
      [  683.123919]  mempool_alloc+0x5f/0x150
      [  683.123925]  ? __enqueue_entity+0x6c/0x70
      [  683.123928]  get_request+0x3ad/0x720
      [  683.123933]  ? prepare_to_wait_event+0x110/0x110
      [  683.123937]  blk_queue_bio+0xc1/0x3a0
      [  683.123940]  generic_make_request+0xf8/0x2a0
      [  683.123942]  submit_bio+0x75/0x150
      [  683.123947]  submit_bio_wait+0x51/0x70
      [  683.123951]  blkdev_issue_flush+0x5c/0x90
      [  683.123956]  ext4_sync_fs+0x171/0x1b0
      [  683.123961]  sync_filesystem+0x73/0x90
      [  683.123965]  fsync_bdev+0x24/0x50
      [  683.123971]  invalidate_partition+0x24/0x50
      [  683.123973]  del_gendisk+0xb2/0x2a0
      [  683.123977]  mmc_blk_remove_req.part.38+0x71/0xa0 [mmc_block]
      [  683.123980]  mmc_blk_remove+0xba/0x190 [mmc_block]
      [  683.123990]  mmc_bus_remove+0x1a/0x20 [mmc_core]
      [  683.123995]  device_release_driver_internal+0x141/0x200
      [  683.123999]  device_release_driver+0x12/0x20
      [  683.124001]  bus_remove_device+0xfd/0x170
      [  683.124004]  device_del+0x1e8/0x330
      [  683.124012]  mmc_remove_card+0x60/0xc0 [mmc_core]
      [  683.124019]  mmc_remove+0x19/0x30 [mmc_core]
      [  683.124025]  mmc_stop_host+0xfb/0x1a0 [mmc_core]
      [  683.124032]  mmc_remove_host+0x1a/0x40 [mmc_core]
      [  683.124037]  sdhci_remove_host+0x2e/0x1c0 [mmc_sdhci]
      [  683.124042]  sdhci_pci_remove_slot+0x3f/0x80 [sdhci_pci]
      [  683.124045]  sdhci_pci_remove+0x39/0x70 [sdhci_pci]
      [  683.124049]  pci_device_remove+0x39/0xc0
      [  683.124052]  device_release_driver_internal+0x141/0x200
      [  683.124056]  driver_detach+0x3f/0x80
      [  683.124059]  bus_remove_driver+0x55/0xd0
      [  683.124062]  driver_unregister+0x2c/0x50
      [  683.124065]  pci_unregister_driver+0x29/0x90
      [  683.124069]  sdhci_driver_exit+0x10/0x4f3 [sdhci_pci]
      [  683.124073]  SyS_delete_module+0x171/0x250
      [  683.124078]  entry_SYSCALL_64_fastpath+0x1e/0xa9
      
      Fix this by setting the queue DYING flag before cleanup the queue, as it
      prevents new reqs from entering the queue.
      Signed-off-by: NGrzegorz Sluja <grzegorzx.sluja@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Fixes: 304419d8 ("mmc: core: Allocate per-request data using the...")
      [Ulf: Updated the changelog]
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      bbdc74dc
    • M
      mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic · dcda9b04
      Michal Hocko 提交于
      __GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to
      the page allocator.  This has been true but only for allocations
      requests larger than PAGE_ALLOC_COSTLY_ORDER.  It has been always
      ignored for smaller sizes.  This is a bit unfortunate because there is
      no way to express the same semantic for those requests and they are
      considered too important to fail so they might end up looping in the
      page allocator for ever, similarly to GFP_NOFAIL requests.
      
      Now that the whole tree has been cleaned up and accidental or misled
      usage of __GFP_REPEAT flag has been removed for !costly requests we can
      give the original flag a better name and more importantly a more useful
      semantic.  Let's rename it to __GFP_RETRY_MAYFAIL which tells the user
      that the allocator would try really hard but there is no promise of a
      success.  This will work independent of the order and overrides the
      default allocator behavior.  Page allocator users have several levels of
      guarantee vs.  cost options (take GFP_KERNEL as an example)
      
       - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_
         attempt to free memory at all. The most light weight mode which even
         doesn't kick the background reclaim. Should be used carefully because
         it might deplete the memory and the next user might hit the more
         aggressive reclaim
      
       - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic
         allocation without any attempt to free memory from the current
         context but can wake kswapd to reclaim memory if the zone is below
         the low watermark. Can be used from either atomic contexts or when
         the request is a performance optimization and there is another
         fallback for a slow path.
      
       - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) -
         non sleeping allocation with an expensive fallback so it can access
         some portion of memory reserves. Usually used from interrupt/bh
         context with an expensive slow path fallback.
      
       - GFP_KERNEL - both background and direct reclaim are allowed and the
         _default_ page allocator behavior is used. That means that !costly
         allocation requests are basically nofail but there is no guarantee of
         that behavior so failures have to be checked properly by callers
         (e.g. OOM killer victim is allowed to fail currently).
      
       - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior
         and all allocation requests fail early rather than cause disruptive
         reclaim (one round of reclaim in this implementation). The OOM killer
         is not invoked.
      
       - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator
         behavior and all allocation requests try really hard. The request
         will fail if the reclaim cannot make any progress. The OOM killer
         won't be triggered.
      
       - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior
         and all allocation requests will loop endlessly until they succeed.
         This might be really dangerous especially for larger orders.
      
      Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL
      because they already had their semantic.  No new users are added.
      __alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if
      there is no progress and we have already passed the OOM point.
      
      This means that all the reclaim opportunities have been exhausted except
      the most disruptive one (the OOM killer) and a user defined fallback
      behavior is more sensible than keep retrying in the page allocator.
      
      [akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c]
      [mhocko@suse.com: semantic fix]
        Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz
      [mhocko@kernel.org: address other thing spotted by Vlastimil]
        Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz
      Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Alex Belits <alex.belits@cavium.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Darrick J. Wong <darrick.wong@oracle.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: NeilBrown <neilb@suse.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dcda9b04