1. 03 Jan, 2017 8 commits
  2. 02 Jan, 2017 25 commits
    • Felix Hädicke's avatar
      usb: gadget: udc: core: fix return code of usb_gadget_probe_driver() · 7b017381
      Felix Hädicke authored
      This fixes a regression which was introduced by commit f1bddbb3, by
      reverting a small fragment of commit 855ed04a.
      
      If the following conditions were met, usb_gadget_probe_driver() returned
      0, although the call was unsuccessful:
      1. A particular UDC was specified by thge gadget driver (using member
      "udc_name" of struct usb_gadget_driver).
      2. The UDC with this name is available.
      3. Another gadget driver is already bound to this gadget.
      4. The gadget driver has the "match_existing_only" flag set.
      In this case, the return code variable "ret" is set to 0, the return
      code of a strcmp() call (to check for the second condition).
      
      This also fixes an oops which could occur in the following scenario:
      1. Two usb gadget instances were configured using configfs.
      2. The first gadget configuration was bound to a UDC (using the configfs
      attribute "UDC").
      3. It was tried to bind the second gadget configuration to the same UDC
      in the same way. This operation was then wrongly reported as being
      successful.
      4. The second gadget configuration's "UDC" attribute is cleared, to
      unbind the (not really bound) second gadget configuration from the UDC.
      
      <BUG: unable to handle kernel NULL pointer dereference
      at           (null)
      IP: [<ffffffff94f5e5e9>] __list_del_entry+0x29/0xc0
      PGD 41b4c5067
      PUD 41a598067
      PMD 0
      
      Oops: 0000 [#1] SMP
      Modules linked in: cdc_acm usb_f_fs usb_f_serial
      usb_f_acm u_serial libcomposite configfs dummy_hcd bnep intel_rapl
      x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
      snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
      ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper
      ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic serio_raw
      uvcvideo videobuf2_vmalloc btusb snd_usb_audio snd_hda_intel
      videobuf2_memops btrtl snd_hda_codec snd_hda_core snd_usbmidi_lib btbcm
      videobuf2_v4l2 btintel snd_hwdep videobuf2_core snd_seq_midi bluetooth
      snd_seq_midi_event videodev xpad efi_pstore snd_pcm_oss rfkill joydev
      media crc16 ff_memless snd_mixer_oss snd_rawmidi nls_ascii snd_pcm
      snd_seq snd_seq_device nls_cp437 mei_me snd_timer vfat sg udc_core
      lpc_ich fat
      efivars mfd_core mei snd soundcore battery nuvoton_cir rc_core evdev
      intel_smartconnect ie31200_edac edac_core shpchp tpm_tis tpm_tis_core
      tpm parport_pc ppdev lp parport efivarfs autofs4 btrfs xor raid6_pq
      hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid uas
      usb_storage sr_mod cdrom sd_mod ahci libahci nouveau i915 crc32c_intel
      i2c_algo_bit psmouse ttm xhci_pci libata scsi_mod ehci_pci
      drm_kms_helper xhci_hcd ehci_hcd r8169 mii usbcore drm nvme nvme_core
      fjes button [last unloaded: net2280]
      CPU: 5 PID: 829 Comm: bash Not tainted 4.9.0-rc7 #1
      Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77
      Extreme3, BIOS P1.50 07/11/2013
      task: ffff880419ce4040 task.stack: ffffc90002ed4000
      RIP: 0010:[<ffffffff94f5e5e9>]  [<ffffffff94f5e5e9>]
      __list_del_entry+0x29/0xc0
      RSP: 0018:ffffc90002ed7d68  EFLAGS: 00010207
      RAX: 0000000000000000 RBX: ffff88041787ec30 RCX: dead000000000200
      RDX: 0000000000000000 RSI: ffff880417482002 RDI: ffff88041787ec30
      RBP: ffffc90002ed7d68 R08: 0000000000000000 R09: 0000000000000010
      R10: 0000000000000000 R11: ffff880419ce4040 R12: ffff88041787eb68
      R13: ffff88041787eaa8 R14: ffff88041560a2c0 R15: 0000000000000001
      FS:  00007fe4e49b8700(0000) GS:ffff88042f340000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 000000041b4c4000 CR4: 00000000001406e0
      Stack:
      ffffc90002ed7d80 ffffffff94f5e68d ffffffffc0ae5ef0 ffffc90002ed7da0
      ffffffffc0ae22aa ffff88041787e800 ffff88041787e800 ffffc90002ed7dc0
      ffffffffc0d7a727 ffffffff952273fa ffff88041aba5760 ffffc90002ed7df8
      Call Trace:
      [<ffffffff94f5e68d>] list_del+0xd/0x30
      [<ffffffffc0ae22aa>] usb_gadget_unregister_driver+0xaa/0xc0 [udc_core]
      [<ffffffffc0d7a727>] unregister_gadget+0x27/0x60 [libcomposite]
      [<ffffffff952273fa>] ? mutex_lock+0x1a/0x30
      [<ffffffffc0d7a9b8>] gadget_dev_desc_UDC_store+0x88/0xe0 [libcomposite]
      [<ffffffffc0af8aa0>] configfs_write_file+0xa0/0x100 [configfs]
      [<ffffffff94e10d27>] __vfs_write+0x37/0x160
      [<ffffffff94e31430>] ? __fd_install+0x30/0xd0
      [<ffffffff95229dae>] ? _raw_spin_unlock+0xe/0x10
      [<ffffffff94e11458>] vfs_write+0xb8/0x1b0
      [<ffffffff94e128f8>] SyS_write+0x58/0xc0
      [<ffffffff94e31594>] ? __close_fd+0x94/0xc0
      [<ffffffff9522a0fb>] entry_SYSCALL_64_fastpath+0x1e/0xad
      Code: 66 90 55 48 8b 07 48 b9 00 01 00 00 00 00 ad de 48 8b 57 08 48 89
      e5 48 39 c8 74 29 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 3a <4c> 8b
      02 4c 39 c7 75 52 4c 8b 40 08 4c 39 c7 75 66 48 89 50 08
      RIP  [<ffffffff94f5e5e9>] __list_del_entry+0x29/0xc0
      RSP <ffffc90002ed7d68>
      CR2: 0000000000000000
      ---[ end trace 99fc090ab3ff6cbc ]---
      
      Fixes: f1bddbb3 ("usb: gadget: Fix binding to UDC via configfs
      interface")
      Signed-off-by: default avatarFelix Hädicke <felixhaedicke@web.de>
      Tested-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      7b017381
    • Heikki Krogerus's avatar
      usb: dwc3: pci: add Intel Gemini Lake PCI ID · 8f8983a5
      Heikki Krogerus authored
      Intel Gemini Lake SoC has the same DWC3 than Broxton. Add
      the new ID to the supported Devices.
      Signed-off-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      8f8983a5
    • Marek Szyprowski's avatar
      usb: dwc2: fix flags for DMA descriptor allocation in dwc2_hsotg_ep_enable · 86e881e7
      Marek Szyprowski authored
      dwc2_hsotg_ep_enable can be called from interrupt context, so all
      allocations should be done with GFP_ATOMIC flags. This fixes following
      issue on ARM architecture:
      
      [<c010d830>] (unwind_backtrace) from [<c010a51c>] (show_stack+0x10/0x14)
      [<c010a51c>] (show_stack) from [<c032930c>] (dump_stack+0x74/0x94)
      [<c032930c>] (dump_stack) from [<c011cd30>] (__warn+0xd4/0x100)
      [<c011cd30>] (__warn) from [<c011cd7c>] (warn_slowpath_null+0x20/0x28)
      [<c011cd7c>] (warn_slowpath_null) from [<c0187e04>] (smp_call_function_many+0xcc/0x2a4)
      [<c0187e04>] (smp_call_function_many) from [<c0188014>] (on_each_cpu_mask+0x38/0xa8)
      [<c0188014>] (on_each_cpu_mask) from [<c01ddfe0>] (start_isolate_page_range+0x134/0x1b8)
      [<c01ddfe0>] (start_isolate_page_range) from [<c01a3c14>] (alloc_contig_range+0xac/0x2f8)
      [<c01a3c14>] (alloc_contig_range) from [<c01de3e4>] (cma_alloc+0xe0/0x1a8)
      [<c01de3e4>] (cma_alloc) from [<c0110acc>] (__alloc_from_contiguous+0x38/0xe0)
      [<c0110acc>] (__alloc_from_contiguous) from [<c0110ba4>] (cma_allocator_alloc+0x30/0x38)
      [<c0110ba4>] (cma_allocator_alloc) from [<c0111034>] (__dma_alloc+0x1c0/0x2c8)
      [<c0111034>] (__dma_alloc) from [<c01111b4>] (arm_dma_alloc+0x3c/0x48)
      [<c01111b4>] (arm_dma_alloc) from [<c04ad800>] (dwc2_hsotg_ep_enable+0xec/0x46c)
      [<c04ad800>] (dwc2_hsotg_ep_enable) from [<c04da610>] (usb_ep_enable+0x2c/0x3c)
      [<c04da610>] (usb_ep_enable) from [<c04dc0c0>] (ecm_set_alt+0xa8/0x154)
      [<c04dc0c0>] (ecm_set_alt) from [<c04d678c>] (composite_setup+0xd74/0x1540)
      [<c04d678c>] (composite_setup) from [<c04ae048>] (dwc2_hsotg_complete_setup+0xb8/0x370)
      [<c04ae048>] (dwc2_hsotg_complete_setup) from [<c04d987c>] (usb_gadget_giveback_request+0xc/0x10)
      [<c04d987c>] (usb_gadget_giveback_request) from [<c04acafc>] (dwc2_hsotg_complete_request+0x78/0x128)
      [<c04acafc>] (dwc2_hsotg_complete_request) from [<c04aed28>] (dwc2_hsotg_epint+0x69c/0x81c)
      [<c04aed28>] (dwc2_hsotg_epint) from [<c04af6c4>] (dwc2_hsotg_irq+0xfc/0x748)
      [<c04af6c4>] (dwc2_hsotg_irq) from [<c0163264>] (__handle_irq_event_percpu+0x58/0x140)
      [<c0163264>] (__handle_irq_event_percpu) from [<c0163368>] (handle_irq_event_percpu+0x1c/0x58)
      [<c0163368>] (handle_irq_event_percpu) from [<c01633dc>] (handle_irq_event+0x38/0x5c)
      [<c01633dc>] (handle_irq_event) from [<c01666e4>] (handle_fasteoi_irq+0xc4/0x19c)
      [<c01666e4>] (handle_fasteoi_irq) from [<c0162a2c>] (generic_handle_irq+0x18/0x28)
      [<c0162a2c>] (generic_handle_irq) from [<c0162b40>] (__handle_domain_irq+0x6c/0xe4)
      [<c0162b40>] (__handle_domain_irq) from [<c0101470>] (gic_handle_irq+0x50/0x9c)
      [<c0101470>] (gic_handle_irq) from [<c010b00c>] (__irq_svc+0x6c/0xa8)
      
      Fixes: 5f54c54b ("usb: dwc2: gadget: Add DDMA chain pointers to
      	dwc2_hsotg_ep structure")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      86e881e7
    • John Youn's avatar
      usb: dwc3: pci: Add "linux,sysdev_is_parent" property · 0eae2fde
      John Youn authored
      Calling platform_device_add_properties() replaces existing properties so
      the "linux,sysdev_is_parent" property doesn't get set. Add this property
      to each platform.
      
      Fixes: d64ff406 ("usb: dwc3: use bus->sysdev for DMA configuration")
      Signed-off-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      0eae2fde
    • Grygorii Strashko's avatar
      usb: dwc3: omap: fix race of pm runtime with irq handler in probe · 12a7f17f
      Grygorii Strashko authored
      Now races can happen between interrupt handler execution and PM runtime in
      error handling code path in probe and in dwc3_omap_remove() which will lead
      to system crash:
      
      in probe:
      ...
       err1:
      	pm_runtime_put_sync(dev);
      ^^ PM runtime can race with IRQ handler when deferred probing happening
         due to extcon
      	pm_runtime_disable(dev);
      
      	return ret;
      
      in dwc3_omap_remove:
      ...
      	dwc3_omap_disable_irqs(omap);
      ^^ IRQs are disabled in HW, but handler may still run
      	of_platform_depopulate(omap->dev);
      	pm_runtime_put_sync(&pdev->dev);
      ^^ PM runtime can race with IRQ handler
      	pm_runtime_disable(&pdev->dev);
      
      	return 0;
      
      So, OMAP DWC3 IRQ need to be disabled before calling
      pm_runtime_put() in probe and in dwc3_omap_remove().
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      12a7f17f
    • Alan Stern's avatar
      USB: gadgetfs: remove unnecessary assignment · 890e6c23
      Alan Stern authored
      The dev_config() routine in gadgetfs has a check that
      dev->dev->bNumConfigurations is equal to 1, and then contains a
      redundant line of code setting the value to 1.  This patch removes the
      unnecessary assignment.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      890e6c23
    • Alan Stern's avatar
      USB: gadgetfs: fix checks of wTotalLength in config descriptors · 1c069b05
      Alan Stern authored
      Andrey Konovalov's fuzz testing of gadgetfs showed that we should
      improve the driver's checks for valid configuration descriptors passed
      in by the user.  In particular, the driver needs to verify that the
      wTotalLength value in the descriptor is not too short (smaller
      than USB_DT_CONFIG_SIZE).  And the check for whether wTotalLength is
      too large has to be changed, because the driver assumes there is
      always enough room remaining in the buffer to hold a device descriptor
      (at least USB_DT_DEVICE_SIZE bytes).
      
      This patch adds the additional check and fixes the existing check.  It
      may do a little more than strictly necessary, but one extra check
      won't hurt.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: Andrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      1c069b05
    • Alan Stern's avatar
      USB: gadgetfs: fix use-after-free bug · add333a8
      Alan Stern authored
      Andrey Konovalov reports that fuzz testing with syzkaller causes a
      KASAN use-after-free bug report in gadgetfs:
      
      BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr ffff88003dfe5bf2
      Read of size 2 by task syz-executor0/22994
      CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88006df06a18 ffffffff81f96aba ffffffffe0528500 1ffff1000dbe0cd6
       ffffed000dbe0cce ffff88006df068f0 0000000041b58ab3 ffffffff8598b4c8
       ffffffff81f96828 1ffff1000dbe0ccd ffff88006df06708 ffff88006df06748
      Call Trace:
       <IRQ> [  201.343209]  [<     inline     >] __dump_stack lib/dump_stack.c:15
       <IRQ> [  201.343209]  [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
       [<     inline     >] print_address_description mm/kasan/report.c:197
       [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
       [<     inline     >] kasan_report mm/kasan/report.c:306
       [<ffffffff817e562a>] __asan_report_load_n_noabort+0x3a/0x40 mm/kasan/report.c:337
       [<     inline     >] config_buf drivers/usb/gadget/legacy/inode.c:1298
       [<ffffffff8322c8fa>] gadgetfs_setup+0x208a/0x20e0 drivers/usb/gadget/legacy/inode.c:1368
       [<ffffffff830fdcd0>] dummy_timer+0x11f0/0x36d0 drivers/usb/gadget/udc/dummy_hcd.c:1858
       [<ffffffff814807c1>] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
       [<     inline     >] expire_timers kernel/time/timer.c:1348
       [<ffffffff81482de6>] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
       [<ffffffff814832c1>] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
       [<ffffffff84f4af8b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
      
      The cause of the bug is subtle.  The dev_config() routine gets called
      twice by the fuzzer.  The first time, the user data contains both a
      full-speed configuration descriptor and a high-speed config
      descriptor, causing dev->hs_config to be set.  But it also contains an
      invalid device descriptor, so the buffer containing the descriptors is
      deallocated and dev_config() returns an error.
      
      The second time dev_config() is called, the user data contains only a
      full-speed config descriptor.  But dev->hs_config still has the stale
      pointer remaining from the first call, causing the routine to think
      that there is a valid high-speed config.  Later on, when the driver
      dereferences the stale pointer to copy that descriptor, we get a
      use-after-free access.
      
      The fix is simple: Clear dev->hs_config if the passed-in data does not
      contain a high-speed config descriptor.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      add333a8
    • Alan Stern's avatar
      USB: gadgetfs: fix unbounded memory allocation bug · faab5098
      Alan Stern authored
      Andrey Konovalov reports that fuzz testing with syzkaller causes a
      KASAN warning in gadgetfs:
      
      BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr ffff88003c47e160
      Write of size 65537 by task syz-executor0/6356
      CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88003c107ad8 ffffffff81f96aba ffffffff3dc11ef0 1ffff10007820eee
       ffffed0007820ee6 ffff88003dc11f00 0000000041b58ab3 ffffffff8598b4c8
       ffffffff81f96828 ffffffff813fb4a0 ffff88003b6eadc0 ffff88003c107738
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96aba>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff817e4dec>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
       [<     inline     >] print_address_description mm/kasan/report.c:197
       [<ffffffff817e5080>] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
       [<ffffffff817e5705>] kasan_report+0x35/0x40 mm/kasan/report.c:306
       [<     inline     >] check_memory_region_inline mm/kasan/kasan.c:308
       [<ffffffff817e3fb9>] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
       [<ffffffff817e4044>] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
       [<     inline     >] copy_from_user arch/x86/include/asm/uaccess.h:689
       [<     inline     >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
       [<ffffffff83228caf>] dev_config+0x86f/0x1190 drivers/usb/gadget/legacy/inode.c:1759
       [<ffffffff817fdd55>] __vfs_write+0x5d5/0x760 fs/read_write.c:510
       [<ffffffff817ff650>] vfs_write+0x170/0x4e0 fs/read_write.c:560
       [<     inline     >] SYSC_write fs/read_write.c:607
       [<ffffffff81803a5b>] SyS_write+0xfb/0x230 fs/read_write.c:599
       [<ffffffff84f47ec1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      
      Indeed, there is a comment saying that the value of len is restricted
      to a 16-bit integer, but the code doesn't actually do this.
      
      This patch fixes the warning.  It replaces the comment with a
      computation that forces the amount of data copied from the user in
      ep0_write() to be no larger than the wLength size for the control
      transfer, which is a 16-bit quantity.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      faab5098
    • Baolin Wang's avatar
      usb: gadget: f_fs: Fix possibe deadlock · b3ce3ce0
      Baolin Wang authored
      When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
      time another core try to attach new UDC, which will cause deadlock as
      below scenario. Thus we should release ffs lock before issuing
      unregister_gadget_item().
      
      [   52.642225] c1 ======================================================
      [   52.642228] c1 [ INFO: possible circular locking dependency detected ]
      [   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
      [   52.642241] c1 -------------------------------------------------------
      [   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
      [   52.642270] c0  (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>]
      		usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642272] c1  but task is already holding lock:
      [   52.642283] c0  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
      		ffs_data_clear+0x30/0x140
      [   52.642285] c1 which lock already depends on the new lock.
      [   52.642287] c1
                     the existing dependency chain (in reverse order) is:
      [   52.642295] c0
      	       -> #1 (ffs_lock){+.+.+.}:
      [   52.642307] c0        [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
      [   52.642314] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642322] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642328] c0        [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
      [   52.642334] c0        [<ffffffc000654004>] usb_add_function+0x84/0x184
      [   52.642340] c0        [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
      [   52.642346] c0        [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
      [   52.642352] c0        [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
      [   52.642358] c0        [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
      [   52.642369] c0        [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
      [   52.642376] c0        [<ffffffc00023c054>] vfs_write+0xb8/0x214
      [   52.642381] c0        [<ffffffc00023cad4>] SyS_write+0x54/0xb0
      [   52.642388] c0        [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
      [   52.642395] c0
                    -> #0 (udc_lock){+.+.+.}:
      [   52.642401] c0        [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
      [   52.642407] c0        [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642412] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642420] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642427] c0        [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642432] c0        [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642439] c0        [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642444] c0        [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642450] c0        [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642454] c0        [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642460] c0        [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642466] c0        [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642473] c0        [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642482] c0        [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642487] c0        [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642494] c0        [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642501] c0        [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642507] c0        [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642512] c0        [<ffffffc000085ee8>] work_pending+0x1c/0x20
      [   52.642514] c1
                    other info that might help us debug this:
      [   52.642517] c1  Possible unsafe locking scenario:
      [   52.642518] c1        CPU0                    CPU1
      [   52.642520] c1        ----                    ----
      [   52.642525] c0   lock(ffs_lock);
      [   52.642529] c0                                lock(udc_lock);
      [   52.642533] c0                                lock(ffs_lock);
      [   52.642537] c0   lock(udc_lock);
      [   52.642539] c1
                            *** DEADLOCK ***
      [   52.642543] c1 1 lock held by usb ffs open/2808:
      [   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
      		ffs_data_clear+0x30/0x140
      [   52.642557] c1 stack backtrace:
      [   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
      [   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
      [   52.642568] c1 Call trace:
      [   52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
      [   52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
      [   52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
      [   52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
      [   52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
      [   52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
      [   52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
      [   52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
      [   52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
      [   52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
      [   52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
      [   52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
      [   52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
      [   52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
      [   52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
      [   52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
      [   52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
      [   52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
      [   52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
      [   52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
      [   52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
      [   52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20
      Acked-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      b3ce3ce0
    • Janusz Dziedzic's avatar
      usb: dwc3: skip interrupt when ep disabled · d7fd41c6
      Janusz Dziedzic authored
      In case EP disabled pass only EPCPLT command
      to be handled. In other case we could hit
      Bug like below.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000003
      IP:
      [<ffffffff81673428>] dwc3_thread_interrupt+0x11c8/0x1790
      
      while dep->endpoint.desc is NULL.
      Signed-off-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      d7fd41c6
    • Greg Kroah-Hartman's avatar
      usb: gadgetfs: restrict upper bound on device configuration size · 0994b0a2
      Greg Kroah-Hartman authored
      Andrey Konovalov reported that we were not properly checking the upper
      limit before of a device configuration size before calling
      memdup_user(), which could cause some problems.
      
      So set the upper limit to PAGE_SIZE * 4, which should be good enough for
      all devices.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      0994b0a2
    • Alan Stern's avatar
      USB: dummy-hcd: fix bug in stop_activity (handle ep0) · bcdbeb84
      Alan Stern authored
      The stop_activity() routine in dummy-hcd is supposed to unlink all
      active requests for every endpoint, among other things.  But it
      doesn't handle ep0.  As a result, fuzz testing can generate a WARNING
      like the following:
      
      WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672 dummy_free_request+0x153/0x170
      Modules linked in:
      CPU: 0 PID: 4410 Comm: syz-executor Not tainted 4.9.0-rc7+ #32
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
       ffff88006a64ed10 ffffffff81f96b8a ffffffff41b58ab3 1ffff1000d4c9d35
       ffffed000d4c9d2d ffff880065f8ac00 0000000041b58ab3 ffffffff8598b510
       ffffffff81f968f8 0000000041b58ab3 ffffffff859410e0 ffffffff813f0590
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff81f96b8a>] dump_stack+0x292/0x398 lib/dump_stack.c:51
       [<ffffffff812b808f>] __warn+0x19f/0x1e0 kernel/panic.c:550
       [<ffffffff812b831c>] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585
       [<ffffffff830fcb13>] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672
       [<ffffffff830ed1b0>] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195
       [<ffffffff83225031>] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612
       [<ffffffff830ebd8f>] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228
       [<ffffffff830ec084>] usb_gadget_unregister_driver+0x154/0x240 drivers/usb/gadget/udc/core.c:1357
      
      This patch fixes the problem by iterating over all the endpoints in
      the driver's ep array instead of iterating over the gadget's ep_list,
      which explicitly leaves out ep0.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      bcdbeb84
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Fix ExtCompat descriptor validation · 354bc45b
      Vincent Pelletier authored
      Reserved1 is documented as expected to be set to 0, but this test fails
      when it it set to 0. Reverse the condition.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      354bc45b
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Document eventfd effect on descriptor format. · 96a420d2
      Vincent Pelletier authored
      When FUNCTIONFS_EVENTFD flag is set, __ffs_data_got_descs reads a 32bits,
      little-endian value right after the fixed structure header, and passes it
      to eventfd_ctx_fdget. Document this.
      
      Also, rephrase a comment to be affirmative about the role of string
      descriptor at index 0. Ref: USB 2.0 spec paragraph "9.6.7 String", and
      also checked to still be current in USB 3.0 spec paragraph "9.6.9 String".
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      96a420d2
    • Krzysztof Opasiak's avatar
      usb: gadget: composite: Test get_alt() presence instead of set_alt() · 7e4da3fc
      Krzysztof Opasiak authored
      By convention (according to doc) if function does not provide
      get_alt() callback composite framework should assume that it has only
      altsetting 0 and should respond with error if host tries to set
      other one.
      
      After commit dd4dff8b ("USB: composite: Fix bug: should test
      set_alt function pointer before use it")
      we started checking set_alt() callback instead of get_alt().
      This check is useless as we check if set_alt() is set inside
      usb_add_function() and fail if it's NULL.
      
      Let's fix this check and move comment about why we check the get
      method instead of set a little bit closer to prevent future false
      fixes.
      
      Fixes: dd4dff8b ("USB: composite: Fix bug: should test set_alt function pointer before use it")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarKrzysztof Opasiak <k.opasiak@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      7e4da3fc
    • Hans de Goede's avatar
      usb: dwc3: pci: Fix dr_mode misspelling · 51c1685d
      Hans de Goede authored
      usb_get_dr_mode() expects the device-property to be spelled
      "dr_mode" not "dr-mode".
      
      Spelling it properly fixes the following warning showing up in dmesg:
      [ 8704.500545] dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget
      
      Signed-off-by: Hans de Goede <hdegoede@redhat.com
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      51c1685d
    • Felipe Balbi's avatar
      usb: dwc3: core: avoid Overflow events · e71d363d
      Felipe Balbi authored
      Now that we're handling so many transfers at a time
      and for some dwc3 revisions LPM events *must* be
      enabled, we can fall into a situation where too many
      events fire and we start receiving Overflow events.
      
      Let's do what XHCI does and allocate a full page for
      the Event Ring, this will avoid any future issues.
      
      Cc: <stable@vger.kernel.org> # v4.9
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      e71d363d
    • Felipe Balbi's avatar
      usb: dwc3: gadget: always unmap EP0 requests · d6214592
      Felipe Balbi authored
      commit 0416e494 ("usb: dwc3: ep0: correct cache
      sync issue in case of ep0_bounced") introduced a bug
      where we would leak DMA resources which would cause
      us to starve the system of them resulting in failing
      DMA transfers.
      
      Fix the bug by making sure that we always unmap EP0
      requests since those are *always* mapped.
      
      Fixes: 0416e494 ("usb: dwc3: ep0: correct cache
      	sync issue in case of ep0_bounced")
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarTomasz Medrek <tomaszx.medrek@intel.com>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      d6214592
    • Felipe Balbi's avatar
      usb: dwc3: ep0: explicitly call dwc3_ep0_prepare_one_trb() · 19ec3123
      Felipe Balbi authored
      Let's call dwc3_ep0_prepare_one_trb() explicitly
      because there are occasions where we will need more
      than one TRB to handle an EP0 transfer.
      
      A follow-up patch will fix one bug related to
      multiple-TRB Data Phases when it comes to
      mapping/unmapping requests for DMA.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      19ec3123
    • Felipe Balbi's avatar
      usb: dwc3: ep0: add dwc3_ep0_prepare_one_trb() · 7931ec86
      Felipe Balbi authored
      For now this is just a cleanup patch, no functional
      changes. We will be using the new function to fix a
      bug introduced long ago by commit 0416e494
      ("usb: dwc3: ep0: correct cache sync issue in case
      of ep0_bounced") and further worsened by commit
      c0bd5456 ("usb: dwc3: ep0: handle non maxpacket
      aligned transfers > 512")
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      7931ec86
    • Stefan Wahren's avatar
      usb: dwc2: gadget: fix default value for gadget-dma-desc · efc95b2c
      Stefan Wahren authored
      The current default for gadget DMA descriptor results on bcm2835 in a
      unnecessary error message:
      
        Invalid value 1 for param gadget-dma-desc
      
      So fix this by using hw->dma_desc_enable as default value.
      
      Fixes: dec4b556 ("usb: dwc2: gadget: Add descriptor DMA parameter")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      efc95b2c
    • Stefan Wahren's avatar
      usb: dwc2: fix default value for DMA support · 6118d064
      Stefan Wahren authored
      The current defaults for DMA results on a non-DMA platform in a unnecessary
      error message:
      
        Invalid value 0 for param gadget-dma
      
      So fix this by using dma_capable as default value.
      
      Fixes: 9962b62f ("usb: dwc2: Deprecate g-use-dma binding")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      6118d064
    • Stefan Wahren's avatar
      usb: dwc2: fix dwc2_get_device_property for u8 and u16 · de02238d
      Stefan Wahren authored
      According to the Devicetree ePAPR [1] the datatypes u8 and u16 are
      not defined. So using device_property_read_u16() would result in
      a partial read of a 32-bit big-endian integer which is not intended.
      So we better read the complete 32-bit value. This fixes a regression
      on bcm2835 where the values for g-rx-fifo-size and g-np-tx-fifo-size
      always read as zero:
      
        Invalid value 0 for param g-rx-fifo-size
        Invalid value 0 for param g-np-tx-fifo-size
      
      [1] - http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
      
      Fixes: 05ee799f ("usb: dwc2: Move gadget settings into core_params")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      de02238d
    • Stefan Wahren's avatar
      usb: dwc2: Do not set host parameter in peripheral mode · f3419735
      Stefan Wahren authored
      Since commit "usb: dwc2: Improve handling of host and device hwparams" the
      host mode specific hardware parameter aren't initialized in peripheral mode
      from the register settings anymore. So we better do not set them in this
      case which avoids the following warnings on bcm2835:
      
        256 invalid for host_nperio_tx_fifo_size. Check HW configuration.
        512 invalid for host_perio_tx_fifo_size. Check HW configuration.
      
      Fixes: 55e1040e ("usb: dwc2: Improve handling of host and device hwparams")
      Acked-by: default avatarJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      f3419735
  3. 01 Jan, 2017 2 commits
    • Linus Torvalds's avatar
      Linux 4.10-rc2 · 0c744ea4
      Linus Torvalds authored
      0c744ea4
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 4759d386
      Linus Torvalds authored
      Pull DAX updates from Dan Williams:
       "The completion of Jan's DAX work for 4.10.
      
        As I mentioned in the libnvdimm-for-4.10 pull request, these are some
        final fixes for the DAX dirty-cacheline-tracking invalidation work
        that was merged through the -mm, ext4, and xfs trees in -rc1. These
        patches were prepared prior to the merge window, but we waited for
        4.10-rc1 to have a stable merge base after all the prerequisites were
        merged.
      
        Quoting Jan on the overall changes in these patches:
      
           "So I'd like all these 6 patches to go for rc2. The first three
            patches fix invalidation of exceptional DAX entries (a bug which
            is there for a long time) - without these patches data loss can
            occur on power failure even though user called fsync(2). The other
            three patches change locking of DAX faults so that ->iomap_begin()
            is called in a more relaxed locking context and we are safe to
            start a transaction there for ext4"
      
        These have received a build success notification from the kbuild
        robot, and pass the latest libnvdimm unit tests. There have not been
        any -next releases since -rc1, so they have not appeared there"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        ext4: Simplify DAX fault path
        dax: Call ->iomap_begin without entry lock during dax fault
        dax: Finish fault completely when loading holes
        dax: Avoid page invalidation races and unnecessary radix tree traversals
        mm: Invalidate DAX radix tree entries only if appropriate
        ext2: Return BH_New buffers for zeroed blocks
      4759d386
  4. 30 Dec, 2016 2 commits
  5. 29 Dec, 2016 2 commits
    • Olof Johansson's avatar
      mm/filemap: fix parameters to test_bit() · 98473f9f
      Olof Johansson authored
       mm/filemap.c: In function 'clear_bit_unlock_is_negative_byte':
        mm/filemap.c:933:9: error: too few arguments to function 'test_bit'
          return test_bit(PG_waiters);
               ^~~~~~~~
      
      Fixes: b91e1302 ('mm: optimize PageWaiters bit use for unlock_page()')
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Brown-paper-bag-by: default avatarLinus Torvalds <dummy@duh.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98473f9f
    • Linus Torvalds's avatar
      mm: optimize PageWaiters bit use for unlock_page() · b91e1302
      Linus Torvalds authored
      In commit 62906027 ("mm: add PageWaiters indicating tasks are
      waiting for a page bit") Nick Piggin made our page locking no longer
      unconditionally touch the hashed page waitqueue, which not only helps
      performance in general, but is particularly helpful on NUMA machines
      where the hashed wait queues can bounce around a lot.
      
      However, the "clear lock bit atomically and then test the waiters bit"
      sequence turns out to be much more expensive than it needs to be,
      because you get a nasty stall when trying to access the same word that
      just got updated atomically.
      
      On architectures where locking is done with LL/SC, this would be trivial
      to fix with a new primitive that clears one bit and tests another
      atomically, but that ends up not working on x86, where the only atomic
      operations that return the result end up being cmpxchg and xadd.  The
      atomic bit operations return the old value of the same bit we changed,
      not the value of an unrelated bit.
      
      On x86, we could put the lock bit in the high bit of the byte, and use
      "xadd" with that bit (where the overflow ends up not touching other
      bits), and look at the other bits of the result.  However, an even
      simpler model is to just use a regular atomic "and" to clear the lock
      bit, and then the sign bit in eflags will indicate the resulting state
      of the unrelated bit #7.
      
      So by moving the PageWaiters bit up to bit #7, we can atomically clear
      the lock bit and test the waiters bit on x86 too.  And architectures
      with LL/SC (which is all the usual RISC suspects), the particular bit
      doesn't matter, so they are fine with this approach too.
      
      This avoids the extra access to the same atomic word, and thus avoids
      the costly stall at page unlock time.
      
      The only downside is that the interface ends up being a bit odd and
      specialized: clear a bit in a byte, and test the sign bit.  Nick doesn't
      love the resulting name of the new primitive, but I'd rather make the
      name be descriptive and very clear about the limitation imposed by
      trying to work across all relevant architectures than make it be some
      generic thing that doesn't make the odd semantics explicit.
      
      So this introduces the new architecture primitive
      
          clear_bit_unlock_is_negative_byte();
      
      and adds the trivial implementation for x86.  We have a generic
      non-optimized fallback (that just does a "clear_bit()"+"test_bit(7)"
      combination) which can be overridden by any architecture that can do
      better.  According to Nick, Power has the same hickup x86 has, for
      example, but some other architectures may not even care.
      
      All these optimizations mean that my page locking stress-test (which is
      just executing a lot of small short-lived shell scripts: "make test" in
      the git source tree) no longer makes our page locking look horribly bad.
      Before all these optimizations, just the unlock_page() costs were just
      over 3% of all CPU overhead on "make test".  After this, it's down to
      0.66%, so just a quarter of the cost it used to be.
      
      (The difference on NUMA is bigger, but there this micro-optimization is
      likely less noticeable, since the big issue on NUMA was not the accesses
      to 'struct page', but the waitqueue accesses that were already removed
      by Nick's earlier commit).
      Acked-by: default avatarNick Piggin <npiggin@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Bob Peterson <rpeterso@redhat.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andreas Gruenbacher <agruenba@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b91e1302
  6. 28 Dec, 2016 1 commit