1. 13 3月, 2013 1 次提交
    • M
      device: separate all subsys mutexes · be871b7e
      Michal Hocko 提交于
      ca22e56d (driver-core: implement 'sysdev' functionality for regular
      devices and buses) has introduced bus_register macro with a static
      key to distinguish different subsys mutex classes.
      
      This however doesn't work for different subsys which use a common
      registering function. One example is subsys_system_register (and
      mce_device and cpu_device).
      
      In the end this leads to the following lockdep splat:
      [  207.271924] ======================================================
      [  207.271932] [ INFO: possible circular locking dependency detected ]
      [  207.271942] 3.9.0-rc1-0.7-default+ #34 Not tainted
      [  207.271948] -------------------------------------------------------
      [  207.271957] bash/10493 is trying to acquire lock:
      [  207.271963]  (subsys mutex){+.+.+.}, at: [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.271987]
      [  207.271987] but task is already holding lock:
      [  207.271995]  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60
      [  207.272012]
      [  207.272012] which lock already depends on the new lock.
      [  207.272012]
      [  207.272023]
      [  207.272023] the existing dependency chain (in reverse order) is:
      [  207.272033]
      [  207.272033] -> #4 (cpu_hotplug.lock){+.+.+.}:
      [  207.272044]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272056]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272069]        [<ffffffff81046ba9>] get_online_cpus+0x29/0x40
      [  207.272082]        [<ffffffff81185210>] drain_all_stock+0x30/0x150
      [  207.272094]        [<ffffffff811853da>] mem_cgroup_reclaim+0xaa/0xe0
      [  207.272104]        [<ffffffff8118775e>] __mem_cgroup_try_charge+0x51e/0xcf0
      [  207.272114]        [<ffffffff81188486>] mem_cgroup_charge_common+0x36/0x60
      [  207.272125]        [<ffffffff811884da>] mem_cgroup_newpage_charge+0x2a/0x30
      [  207.272135]        [<ffffffff81150531>] do_wp_page+0x231/0x830
      [  207.272147]        [<ffffffff8115151e>] handle_pte_fault+0x19e/0x8d0
      [  207.272157]        [<ffffffff81151da8>] handle_mm_fault+0x158/0x1e0
      [  207.272166]        [<ffffffff814b6153>] do_page_fault+0x2a3/0x4e0
      [  207.272178]        [<ffffffff814b2578>] page_fault+0x28/0x30
      [  207.272189]
      [  207.272189] -> #3 (&mm->mmap_sem){++++++}:
      [  207.272199]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272208]        [<ffffffff8114c5ad>] might_fault+0x6d/0x90
      [  207.272218]        [<ffffffff811a11e3>] filldir64+0xb3/0x120
      [  207.272229]        [<ffffffffa013fc19>] call_filldir+0x89/0x130 [ext3]
      [  207.272248]        [<ffffffffa0140377>] ext3_readdir+0x6b7/0x7e0 [ext3]
      [  207.272263]        [<ffffffff811a1519>] vfs_readdir+0xa9/0xc0
      [  207.272273]        [<ffffffff811a15cb>] sys_getdents64+0x9b/0x110
      [  207.272284]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272296]
      [  207.272296] -> #2 (&type->i_mutex_dir_key#3){+.+.+.}:
      [  207.272309]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272319]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272329]        [<ffffffff8119c254>] link_path_walk+0x6f4/0x9a0
      [  207.272339]        [<ffffffff8119e7fa>] path_openat+0xba/0x470
      [  207.272349]        [<ffffffff8119ecf8>] do_filp_open+0x48/0xa0
      [  207.272358]        [<ffffffff8118d81c>] file_open_name+0xdc/0x110
      [  207.272369]        [<ffffffff8118d885>] filp_open+0x35/0x40
      [  207.272378]        [<ffffffff8135c76e>] _request_firmware+0x52e/0xb20
      [  207.272389]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20
      [  207.272399]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]
      [  207.272416]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]
      [  207.272431]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]
      [  207.272444]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100
      [  207.272457]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4
      [  207.272472]        [<ffffffff81000202>] do_one_initcall+0x42/0x180
      [  207.272485]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70
      [  207.272499]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130
      [  207.272511]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272523]
      [  207.272523] -> #1 (umhelper_sem){++++.+}:
      [  207.272537]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272548]        [<ffffffff814ae9c4>] down_read+0x34/0x50
      [  207.272559]        [<ffffffff81062bff>] usermodehelper_read_trylock+0x4f/0x100
      [  207.272575]        [<ffffffff8135c7dd>] _request_firmware+0x59d/0xb20
      [  207.272587]        [<ffffffff8135cdd6>] request_firmware+0x16/0x20
      [  207.272599]        [<ffffffffa03bdb91>] request_microcode_fw+0x61/0xd0 [microcode]
      [  207.272613]        [<ffffffffa03bd554>] microcode_init_cpu+0x104/0x150 [microcode]
      [  207.272627]        [<ffffffffa03bd61c>] mc_device_add+0x7c/0xb0 [microcode]
      [  207.272641]        [<ffffffff8134a419>] subsys_interface_register+0xc9/0x100
      [  207.272654]        [<ffffffffa04fc0f4>] 0xffffffffa04fc0f4
      [  207.272666]        [<ffffffff81000202>] do_one_initcall+0x42/0x180
      [  207.272678]        [<ffffffff810bbeff>] load_module+0x19df/0x1b70
      [  207.272690]        [<ffffffff810bc376>] sys_init_module+0xe6/0x130
      [  207.272702]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272715]
      [  207.272715] -> #0 (subsys mutex){+.+.+.}:
      [  207.272729]        [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0
      [  207.272740]        [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.272751]        [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.272763]        [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.272775]        [<ffffffff81349114>] device_del+0x134/0x1f0
      [  207.272786]        [<ffffffff813491f2>] device_unregister+0x22/0x60
      [  207.272798]        [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad
      [  207.272812]        [<ffffffff814b6402>] notifier_call_chain+0x72/0x130
      [  207.272824]        [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10
      [  207.272839]        [<ffffffff81498f76>] _cpu_down+0x1d6/0x350
      [  207.272851]        [<ffffffff81499130>] cpu_down+0x40/0x60
      [  207.272862]        [<ffffffff8149cc55>] store_online+0x75/0xe0
      [  207.272874]        [<ffffffff813474a0>] dev_attr_store+0x20/0x30
      [  207.272886]        [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150
      [  207.272900]        [<ffffffff8118e10b>] vfs_write+0xcb/0x130
      [  207.272911]        [<ffffffff8118e924>] sys_write+0x64/0xa0
      [  207.272923]        [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      [  207.272936]
      [  207.272936] other info that might help us debug this:
      [  207.272936]
      [  207.272952] Chain exists of:
      [  207.272952]   subsys mutex --> &mm->mmap_sem --> cpu_hotplug.lock
      [  207.272952]
      [  207.272973]  Possible unsafe locking scenario:
      [  207.272973]
      [  207.272984]        CPU0                    CPU1
      [  207.272992]        ----                    ----
      [  207.273000]   lock(cpu_hotplug.lock);
      [  207.273009]                                lock(&mm->mmap_sem);
      [  207.273020]                                lock(cpu_hotplug.lock);
      [  207.273031]   lock(subsys mutex);
      [  207.273040]
      [  207.273040]  *** DEADLOCK ***
      [  207.273040]
      [  207.273055] 5 locks held by bash/10493:
      [  207.273062]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81209049>] sysfs_write_file+0x49/0x150
      [  207.273080]  #1:  (s_active#150){.+.+.+}, at: [<ffffffff812090c2>] sysfs_write_file+0xc2/0x150
      [  207.273099]  #2:  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81027557>] cpu_hotplug_driver_lock+0x17/0x20
      [  207.273121]  #3:  (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8149911c>] cpu_down+0x2c/0x60
      [  207.273140]  #4:  (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81046ccf>] cpu_hotplug_begin+0x2f/0x60
      [  207.273158]
      [  207.273158] stack backtrace:
      [  207.273170] Pid: 10493, comm: bash Not tainted 3.9.0-rc1-0.7-default+ #34
      [  207.273180] Call Trace:
      [  207.273192]  [<ffffffff810ab373>] print_circular_bug+0x223/0x310
      [  207.273204]  [<ffffffff810ae002>] __lock_acquire+0x13b2/0x15f0
      [  207.273216]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0
      [  207.273227]  [<ffffffff810ae329>] lock_acquire+0xe9/0x120
      [  207.273239]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0
      [  207.273251]  [<ffffffff814ad807>] mutex_lock_nested+0x37/0x360
      [  207.273263]  [<ffffffff8134af27>] ? bus_remove_device+0x37/0x1c0
      [  207.273274]  [<ffffffff812086b0>] ? sysfs_hash_and_remove+0x60/0xc0
      [  207.273286]  [<ffffffff8134af27>] bus_remove_device+0x37/0x1c0
      [  207.273298]  [<ffffffff81349114>] device_del+0x134/0x1f0
      [  207.273309]  [<ffffffff813491f2>] device_unregister+0x22/0x60
      [  207.273321]  [<ffffffff814a24ea>] mce_cpu_callback+0x15e/0x1ad
      [  207.273332]  [<ffffffff814b6402>] notifier_call_chain+0x72/0x130
      [  207.273344]  [<ffffffff81073d6e>] __raw_notifier_call_chain+0xe/0x10
      [  207.273356]  [<ffffffff81498f76>] _cpu_down+0x1d6/0x350
      [  207.273368]  [<ffffffff81027557>] ? cpu_hotplug_driver_lock+0x17/0x20
      [  207.273380]  [<ffffffff81499130>] cpu_down+0x40/0x60
      [  207.273391]  [<ffffffff8149cc55>] store_online+0x75/0xe0
      [  207.273402]  [<ffffffff813474a0>] dev_attr_store+0x20/0x30
      [  207.273413]  [<ffffffff812090d9>] sysfs_write_file+0xd9/0x150
      [  207.273425]  [<ffffffff8118e10b>] vfs_write+0xcb/0x130
      [  207.273436]  [<ffffffff8118e924>] sys_write+0x64/0xa0
      [  207.273447]  [<ffffffff814bb599>] system_call_fastpath+0x16/0x1b
      
      Which reports a false possitive deadlock because it sees:
      1) load_module -> subsys_interface_register -> mc_deveice_add (*) -> subsys->p->mutex -> link_path_walk -> lookup_slow -> i_mutex
      2) sys_write -> _cpu_down -> cpu_hotplug_begin -> cpu_hotplug.lock -> mce_cpu_callback -> mce_device_remove(**) -> device_unregister -> bus_remove_device -> subsys mutex
      3) vfs_readdir -> i_mutex -> filldir64 -> might_fault -> might_lock_read(mmap_sem) -> page_fault -> mmap_sem -> drain_all_stock -> cpu_hotplug.lock
      
      but
      1) takes cpu_subsys subsys (*) but 2) takes mce_device subsys (**) so
      the deadlock is not possible AFAICS.
      
      The fix is quite simple. We can pull the key inside bus_type structure
      because they are defined per device so the pointer will be unique as
      well. bus_register doesn't need to be a macro anymore so change it
      to the inline. We could get rid of __bus_register as there is no other
      caller but maybe somebody will want to use a different key so keep it
      around for now.
      Reported-by: NLi Zefan <lizefan@huawei.com>
      Signed-off-by: NMichal Hocko <mhocko@suse.cz>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be871b7e
  2. 09 3月, 2013 1 次提交
  3. 04 3月, 2013 2 次提交
    • K
      eCryptfs: allow userspace messaging to be disabled · 290502be
      Kees Cook 提交于
      When the userspace messaging (for the less common case of userspace key
      wrap/unwrap via ecryptfsd) is not needed, allow eCryptfs to build with
      it removed. This saves on kernel code size and reduces potential attack
      surface by removing the /dev/ecryptfs node.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NTyler Hicks <tyhicks@canonical.com>
      290502be
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  4. 03 3月, 2013 3 次提交
    • J
      mm: define VM_GROWSUP for CONFIG_METAG · 9ca52ed9
      James Hogan 提交于
      Commit cc2383ec ("mm: introduce
      arch-specific vma flag VM_ARCH_1") merged in v3.7-rc1.
      
      The above commit combined several arch-specific vma flags into one, and
      in the process it changed the VM_GROWSUP definition to depend on
      specific architectures rather than CONFIG_STACK_GROWSUP. Therefore add
      an ifdef for CONFIG_METAG to also set VM_GROWSUP.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-mm@kvack.org
      9ca52ed9
    • J
      metag: Internal and external irqchips · 5698c50d
      James Hogan 提交于
      Meta core internal interrupts (from HWSTATMETA and friends) are vectored
      onto the TR1 core trigger for the current thread. This is demultiplexed
      in irq-metag.c to individual Linux IRQs for each internal interrupt.
      
      External SoC interrupts (from HWSTATEXT and friends) are vectored onto
      the TR2 core trigger for the current thread. This is demultiplexed in
      irq-metag-ext.c to individual Linux IRQs for each external SoC interrupt.
      The external irqchip has devicetree bindings for configuring the number
      of irq banks and the type of masking available.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Rob Landley <rob@landley.net>
      Cc: Dom Cobley <popcornmix@gmail.com>
      Cc: Simon Arlott <simon@fire.lp0.eu>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
      Cc: devicetree-discuss@lists.ozlabs.org
      Cc: linux-doc@vger.kernel.org
      5698c50d
    • Y
      x86, ACPI, mm: Revert movablemem_map support · 20e6926d
      Yinghai Lu 提交于
      Tim found:
      
        WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x80()
        Hardware name: S2600CP
        sched: CPU #1's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
        smpboot: Booting Node   1, Processors  #1
        Modules linked in:
        Pid: 0, comm: swapper/1 Not tainted 3.9.0-0-generic #1
        Call Trace:
          set_cpu_sibling_map+0x279/0x449
          start_secondary+0x11d/0x1e5
      
      Don Morris reproduced on a HP z620 workstation, and bisected it to
      commit e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock
      is ready")
      
      It turns out movable_map has some problems, and it breaks several things
      
      1. numa_init is called several times, NOT just for srat. so those
      	nodes_clear(numa_nodes_parsed)
      	memset(&numa_meminfo, 0, sizeof(numa_meminfo))
         can not be just removed.  Need to consider sequence is: numaq, srat, amd, dummy.
         and make fall back path working.
      
      2. simply split acpi_numa_init to early_parse_srat.
         a. that early_parse_srat is NOT called for ia64, so you break ia64.
         b.  for (i = 0; i < MAX_LOCAL_APIC; i++)
      	     set_apicid_to_node(i, NUMA_NO_NODE)
           still left in numa_init. So it will just clear result from early_parse_srat.
           it should be moved before that....
         c.  it breaks ACPI_TABLE_OVERIDE...as the acpi table scan is moved
             early before override from INITRD is settled.
      
      3. that patch TITLE is total misleading, there is NO x86 in the title,
         but it changes critical x86 code. It caused x86 guys did not
         pay attention to find the problem early. Those patches really should
         be routed via tip/x86/mm.
      
      4. after that commit, following range can not use movable ram:
        a. real_mode code.... well..funny, legacy Node0 [0,1M) could be hot-removed?
        b. initrd... it will be freed after booting, so it could be on movable...
        c. crashkernel for kdump...: looks like we can not put kdump kernel above 4G
      	anymore.
        d. init_mem_mapping: can not put page table high anymore.
        e. initmem_init: vmemmap can not be high local node anymore. That is
           not good.
      
      If node is hotplugable, the mem related range like page table and
      vmemmap could be on the that node without problem and should be on that
      node.
      
      We have workaround patch that could fix some problems, but some can not
      be fixed.
      
      So just remove that offending commit and related ones including:
      
       f7210e6c ("mm/memblock.c: use CONFIG_HAVE_MEMBLOCK_NODE_MAP to
          protect movablecore_map in memblock_overlaps_region().")
      
       01a178a9 ("acpi, memory-hotplug: support getting hotplug info from
          SRAT")
      
       27168d38 ("acpi, memory-hotplug: extend movablemem_map ranges to
          the end of node")
      
       e8d19552 ("acpi, memory-hotplug: parse SRAT before memblock is
          ready")
      
       fb06bc8e ("page_alloc: bootmem limit with movablecore_map")
      
       42f47e27 ("page_alloc: make movablemem_map have higher priority")
      
       6981ec31 ("page_alloc: introduce zone_movable_limit[] to keep
          movable limit for nodes")
      
       34b71f1e ("page_alloc: add movable_memmap kernel parameter")
      
       4d59a751 ("x86: get pg_data_t's memory from other node")
      
      Later we should have patches that will make sure kernel put page table
      and vmemmap on local node ram instead of push them down to node0.  Also
      need to find way to put other kernel used ram to local node ram.
      Reported-by: NTim Gardner <tim.gardner@canonical.com>
      Reported-by: NDon Morris <don.morris@hp.com>
      Bisected-by: NDon Morris <don.morris@hp.com>
      Tested-by: NDon Morris <don.morris@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      20e6926d
  5. 02 3月, 2013 7 次提交
    • A
      constify path_get/path_put and fs_struct.c stuff · dcf787f3
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      dcf787f3
    • A
      cache the value of file_inode() in struct file · dd37978c
      Al Viro 提交于
      Note that this thing does *not* contribute to inode refcount;
      it's pinned down by dentry.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      dd37978c
    • A
      dm: add target num_write_bios fn · b0d8ed4d
      Alasdair G Kergon 提交于
      Add a num_write_bios function to struct target.
      
      If an instance of a target sets this, it will be queried before the
      target's mapping function is called on a write bio, and the response
      controls the number of copies of the write bio that the target will
      receive.
      
      This provides a convenient way for a target to send the same data to
      more than one device.  The new cache target uses this in writethrough
      mode, to send the data both to the cache and the backing device.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      b0d8ed4d
    • M
      dm kcopyd: introduce configurable throttling · df5d2e90
      Mikulas Patocka 提交于
      This patch allows the administrator to reduce the rate at which kcopyd
      issues I/O.
      
      Each module that uses kcopyd acquires a throttle parameter that can be
      set in /sys/module/*/parameters.
      
      We maintain a history of kcopyd usage by each module in the variables
      io_period and total_period in struct dm_kcopyd_throttle. The actual
      kcopyd activity is calculated as a percentage of time equal to
      "(100 * io_period / total_period)".  This is compared with the user-defined
      throttle percentage threshold and if it is exceeded, we sleep.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      df5d2e90
    • A
      dm: rename request variables to bios · 55a62eef
      Alasdair G Kergon 提交于
      Use 'bio' in the name of variables and functions that deal with
      bios rather than 'request' to avoid confusion with the normal
      block layer use of 'request'.
      
      No functional changes.
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      55a62eef
    • M
      dm: fix truncated status strings · fd7c092e
      Mikulas Patocka 提交于
      Avoid returning a truncated table or status string instead of setting
      the DM_BUFFER_FULL_FLAG when the last target of a table fills the
      buffer.
      
      When processing a table or status request, the function retrieve_status
      calls ti->type->status. If ti->type->status returns non-zero,
      retrieve_status assumes that the buffer overflowed and sets
      DM_BUFFER_FULL_FLAG.
      
      However, targets don't return non-zero values from their status method
      on overflow. Most targets returns always zero.
      
      If a buffer overflow happens in a target that is not the last in the
      table, it gets noticed during the next iteration of the loop in
      retrieve_status; but if a buffer overflow happens in the last target, it
      goes unnoticed and erroneously truncated data is returned.
      
      In the current code, the targets behave in the following way:
      * dm-crypt returns -ENOMEM if there is not enough space to store the
        key, but it returns 0 on all other overflows.
      * dm-thin returns errors from the status method if a disk error happened.
        This is incorrect because retrieve_status doesn't check the error
        code, it assumes that all non-zero values mean buffer overflow.
      * all the other targets always return 0.
      
      This patch changes the ti->type->status function to return void (because
      most targets don't use the return code). Overflow is detected in
      retrieve_status: if the status method fills up the remaining space
      completely, it is assumed that buffer overflow happened.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      fd7c092e
    • R
      hsi: fix kernel-doc warnings · 8eae508b
      Randy Dunlap 提交于
      Fix kernel-doc warnings in hsi files:
      
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'e_handler' description in 'hsi_client'
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'pclaimed' description in 'hsi_client'
        Warning(include/linux/hsi/hsi.h:136): Excess struct/union/enum/typedef member 'nb' description in 'hsi_client'
        Warning(drivers/hsi/hsi.c:434): No description found for parameter 'handler'
        Warning(drivers/hsi/hsi.c:434): Excess function parameter 'cb' description in 'hsi_register_port_event'
      
      Don't document "private:" fields with kernel-doc notation.
      If you want to leave them fully documented, that's OK, but
      then don't mark them as "private:".
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Carlos Chinea <carlos.chinea@nokia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Acked-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8eae508b
  6. 01 3月, 2013 6 次提交
  7. 28 2月, 2013 20 次提交
    • A
      dmaengine: dw_dmac: move to generic DMA binding · f9c6a655
      Arnd Bergmann 提交于
      The original device tree binding for this driver, from Viresh Kumar
      unfortunately conflicted with the generic DMA binding, and did not allow
      to completely seperate slave device configuration from the controller.
      
      This is an attempt to replace it with an implementation of the generic
      binding, but it is currently completely untested, because I do not have
      any hardware with this particular controller.
      
      The patch applies on top of the slave-dma tree, which contains both the base
      support for the generic DMA binding, as well as the earlier attempt from
      Viresh. Both of these are currently not merged upstream however.
      
      This version incorporates feedback from Viresh Kumar, Andy Shevchenko
      and Russell King.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Vinod Koul <vinod.koul@linux.intel.com>
      Cc: devicetree-discuss@lists.ozlabs.org
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      f9c6a655
    • S
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin 提交于
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: NPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
    • M
      include/linux/eventfd.h: fix incorrect filename is a comment · 1d730c49
      Martin Sustrik 提交于
      Comment in eventfd.h referred to 'include/asm-generic/fcntl.h'
      while the correct path is 'include/uapi/asm-generic/fcntl.h'.
      Signed-off-by: NMartin Sustrik <sustrik@250bpm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d730c49
    • R
      ipmi: remove superfluous kernel/userspace explanation · 59fb1b9f
      Robert P. J. Day 提交于
      Given the obvious distinction between kernel and userspace supported
      by uapi/, it seems unnecessary to comment on that.
      Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      59fb1b9f
    • T
      idr: implement lookup hint · 0ffc2a9c
      Tejun Heo 提交于
      While idr lookup isn't a particularly heavy operation, it still is too
      substantial to use in hot paths without worrying about the performance
      implications.  With recent changes, each idr_layer covers 256 slots
      which should be enough to cover most use cases with single idr_layer
      making lookup hint very attractive.
      
      This patch adds idr->hint which points to the idr_layer which
      allocated an ID most recently and the fast path lookup becomes
      
      	if (look up target's prefix matches that of the hinted layer)
      		return hint->ary[ID's offset in the leaf layer];
      
      which can be inlined.
      
      idr->hint is set to the leaf node on idr_fill_slot() and cleared from
      free_layer().
      
      [andriy.shevchenko@linux.intel.com: always do slow path when hint is uninitialized]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ffc2a9c
    • T
      idr: add idr_layer->prefix · 54616283
      Tejun Heo 提交于
      Add a field which carries the prefix of ID the idr_layer covers.  This
      will be used to implement lookup hint.
      
      This patch doesn't make use of the new field and doesn't introduce any
      behavior difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54616283
    • T
      idr: make idr_layer larger · 050a6b47
      Tejun Heo 提交于
      With recent preloading changes, idr no longer keeps full layer cache per
      each idr instance (used to be ~6.5k per idr on 64bit) and the previous
      patch removed restriction on the bitmap size.  Both now allow us to have
      larger layers.
      
      Increase IDR_BITS to 8 regardless of BITS_PER_LONG.  Each layer is
      slightly larger than 2k on 64bit and 1k on 32bit and carries 256 entries.
      The size isn't too large, especially compared to what we used to waste on
      per-idr caches, and 256 entries should be able to serve most use cases
      with single layer.  The max tree depth is 4 which is much better than the
      previous 6 on 64bit and 7 on 32bit.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      050a6b47
    • T
      idr: remove length restriction from idr_layer->bitmap · 1d9b2e1e
      Tejun Heo 提交于
      Currently, idr->bitmap is declared as an unsigned long which restricts
      the number of bits an idr_layer can contain.  All bitops can handle
      arbitrary positive integer bit number and there's no reason for this
      restriction.
      
      Declare idr_layer->bitmap using DECLARE_BITMAP() instead of a single
      unsigned long.
      
      * idr_layer->bitmap is now an array.  '&' dropped from params to
        bitops.
      
      * Replaced "== IDR_FULL" tests with bitmap_full() and removed
        IDR_FULL.
      
      * Replaced find_next_bit() on ~bitmap with find_next_zero_bit().
      
      * Replaced "bitmap = 0" with bitmap_clear().
      
      This patch doesn't (or at least shouldn't) introduce any behavior
      changes.
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d9b2e1e
    • T
      idr: remove MAX_IDR_MASK and move left MAX_IDR_* into idr.c · e8c8d1bc
      Tejun Heo 提交于
      MAX_IDR_MASK is another weirdness in the idr interface.  As idr covers
      whole positive integer range, it's defined as 0x7fffffff or INT_MAX.
      
      Its usage in idr_find(), idr_replace() and idr_remove() is bizarre.
      They basically mask off the sign bit and operate on the rest, so if
      the caller, by accident, passes in a negative number, the sign bit
      will be masked off and the remaining part will be used as if that was
      the input, which is worse than crashing.
      
      The constant is visible in idr.h and there are several users in the
      kernel.
      
      * drivers/i2c/i2c-core.c:i2c_add_numbered_adapter()
      
        Basically used to test if adap->nr is a negative number which isn't
        -1 and returns -EINVAL if so.  idr_alloc() already has negative
        @start checking (w/ WARN_ON_ONCE), so this can go away.
      
      * drivers/infiniband/core/cm.c:cm_alloc_id()
        drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()
      
        Used to wrap cyclic @start.  Can be replaced with max(next, 0).
        Note that this type of cyclic allocation using idr is buggy.  These
        are prone to spurious -ENOSPC failure after the first wraparound.
      
      * fs/super.c:get_anon_bdev()
      
        The ID allocated from ida is masked off before being tested whether
        it's inside valid range.  ida allocated ID can never be a negative
        number and the masking is unnecessary.
      
      Update idr_*() functions to fail with -EINVAL when negative @id is
      specified and update other MAX_IDR_MASK users as described above.
      
      This leaves MAX_IDR_MASK without any user, remove it and relocate
      other MAX_IDR_* constants to lib/idr.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: "Marciniszyn, Mike" <mike.marciniszyn@intel.com>
      Cc: Jack Morgenstein <jackm@dev.mellanox.co.il>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Acked-by: NWolfram Sang <wolfram@the-dreams.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8c8d1bc
    • T
      idr: implement idr_preload[_end]() and idr_alloc() · d5c7409f
      Tejun Heo 提交于
      The current idr interface is very cumbersome.
      
      * For all allocations, two function calls - idr_pre_get() and
        idr_get_new*() - should be made.
      
      * idr_pre_get() doesn't guarantee that the following idr_get_new*()
        will not fail from memory shortage.  If idr_get_new*() returns
        -EAGAIN, the caller is expected to retry pre_get and allocation.
      
      * idr_get_new*() can't enforce upper limit.  Upper limit can only be
        enforced by allocating and then freeing if above limit.
      
      * idr_layer buffer is unnecessarily per-idr.  Each idr ends up keeping
        around MAX_IDR_FREE idr_layers.  The memory consumed per idr is
        under two pages but it makes it difficult to make idr_layer larger.
      
      This patch implements the following new set of allocation functions.
      
      * idr_preload[_end]() - Similar to radix preload but doesn't fail.
        The first idr_alloc() inside preload section can be treated as if it
        were called with @gfp_mask used for idr_preload().
      
      * idr_alloc() - Allocate an ID w/ lower and upper limits.  Takes
        @gfp_flags and can be used w/o preloading.  When used inside
        preloaded section, the allocation mask of preloading can be assumed.
      
      If idr_alloc() can be called from a context which allows sufficiently
      relaxed @gfp_mask, it can be used by itself.  If, for example,
      idr_alloc() is called inside spinlock protected region, preloading can
      be used like the following.
      
      	idr_preload(GFP_KERNEL);
      	spin_lock(lock);
      
      	id = idr_alloc(idr, ptr, start, end, GFP_NOWAIT);
      
      	spin_unlock(lock);
      	idr_preload_end();
      	if (id < 0)
      		error;
      
      which is much simpler and less error-prone than idr_pre_get and
      idr_get_new*() loop.
      
      The new interface uses per-pcu idr_layer buffer and thus the number of
      idr's in the system doesn't affect the amount of memory used for
      preloading.
      
      idr_layer_alloc() is introduced to handle idr_layer allocations for
      both old and new ID allocation paths.  This is a bit hairy now but the
      new interface is expected to replace the old and the internal
      implementation eventually will become simpler.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d5c7409f
    • T
      idr: remove _idr_rc_to_errno() hack · 12d1b439
      Tejun Heo 提交于
      idr uses -1, IDR_NEED_TO_GROW and IDR_NOMORE_SPACE to communicate
      exception conditions internally.  The return value is later translated
      to errno values using _idr_rc_to_errno().
      
      This is confusing.  Drop the custom ones and consistently use -EAGAIN
      for "tree needs to grow", -ENOMEM for "need more memory" and -ENOSPC for
      "ran out of ID space".
      
      Due to the weird memory preloading mechanism, [ra]_get_new*() return
      -EAGAIN on memory shortage, so we need to substitute -ENOMEM w/
      -EAGAIN on those interface functions.  They'll eventually be cleaned
      up and the translations will go away.
      
      This patch doesn't introduce any functional changes.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      12d1b439
    • T
      idr: relocate idr_for_each_entry() and reorganize id[r|a]_get_new() · 49038ef4
      Tejun Heo 提交于
      * Move idr_for_each_entry() definition next to other idr related
        definitions.
      
      * Make id[r|a]_get_new() inline wrappers of id[r|a]_get_new_above().
      
      This changes the implementation of idr_get_new() but the new
      implementation is trivial.  This patch doesn't introduce any
      functional change.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      49038ef4
    • T
      idr: cosmetic updates to struct / initializer definitions · 4106ecaf
      Tejun Heo 提交于
      * Tab align fields like a normal person.
      
      * Drop the unnecessary 0 inits from IDR_INIT().
      
      This patch is purely cosmetic.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4106ecaf
    • T
      idr: deprecate idr_remove_all() · fe6e24ec
      Tejun Heo 提交于
      There was only one legitimate use of idr_remove_all() and a lot more of
      incorrect uses (or lack of it).  Now that idr_destroy() implies
      idr_remove_all() and all the in-kernel users updated not to use it,
      there's no reason to keep it around.  Mark it deprecated so that we can
      later unexport it.
      
      idr_remove_all() is made an inline function calling __idr_remove_all()
      to avoid triggering deprecated warning on EXPORT_SYMBOL().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fe6e24ec
    • M
      lockdep: check that no locks held at freeze time · 6aa97070
      Mandeep Singh Baines 提交于
      We shouldn't try_to_freeze if locks are held.  Holding a lock can cause a
      deadlock if the lock is later acquired in the suspend or hibernate path
      (e.g.  by dpm).  Holding a lock can also cause a deadlock in the case of
      cgroup_freezer if a lock is held inside a frozen cgroup that is later
      acquired by a process outside that group.
      
      [akpm@linux-foundation.org: export debug_check_no_locks_held]
      Signed-off-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Ben Chan <benchan@chromium.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Ingo Molnar <mingo@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6aa97070
    • K
      coredump: remove redundant defines for dumpable states · e579d2c2
      Kees Cook 提交于
      The existing SUID_DUMP_* defines duplicate the newer SUID_DUMPABLE_*
      defines introduced in 54b50199 ("coredump: warn about unsafe
      suid_dumpable / core_pattern combo").  Remove the new ones, and use the
      prior values instead.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reported-by: NChen Gang <gang.chen@asianux.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e579d2c2
    • I
      lib/scatterlist: use page iterator in the mapping iterator · 4225fc85
      Imre Deak 提交于
      For better code reuse use the newly added page iterator to iterate
      through the pages.  The offset, length within the page is still
      calculated by the mapping iterator as well as the actual mapping.  Idea
      from Tejun Heo.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4225fc85
    • I
      lib/scatterlist: add simple page iterator · a321e91b
      Imre Deak 提交于
      Add an iterator to walk through a scatter list a page at a time starting
      at a specific page offset.  As opposed to the mapping iterator this is
      meant to be small, performing well even in simple loops like collecting
      all pages on the scatterlist into an array or setting up an iommu table
      based on the pages' DMA address.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Cc: Maxim Levitsky <maximlevitsky@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NStephen Warren <swarren@wwwdotorg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a321e91b
    • K
      backlight: add new lp8788 backlight driver · c5a51053
      Kim, Milo 提交于
      TI LP8788 PMU supports regulators, battery charger, RTC, ADC, backlight
      dri= ver and current sinks.  This patch enables LP8788 backlight module.
      
      (Brightness mode)
      The brightness is controlled by PWM input or I2C register.
      All modes are supported in the driver.
      
      (Platform data)
      Configurable data can be defined in the platform side.
       name                  : backlight driver name. (default: "lcd-backlight")
       initial_brightness    : initial value of backlight brightness
       bl_mode               : brightness control by PWM or lp8788 register
       dim_mode              : dimming mode selection
       full_scale            : full scale current setting
       rise_time             : brightness ramp up step time
       fall_time             : brightness ramp down step time
       pwm_pol               : PWM polarity setting when bl_mode is PWM based
       period_ns             : platform specific PWM period value. unit is nano.
      
      The default values are set in case no platform data is defined.
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Thierry Reding <thierry.reding@avionic-design.de>
      Cc: "devendra.aaru" <devendra.aaru@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c5a51053
    • M
      dmaengine: add dma_request_slave_channel_compat() · 864ef69b
      Matt Porter 提交于
      Adds a dma_request_slave_channel_compat() wrapper which accepts
      both the arguments from dma_request_channel() and
      dma_request_slave_channel(). Based on whether the driver is
      instantiated via DT, the appropriate channel request call will be
      made.
      
      This allows for a much cleaner migration of drivers to the
      dmaengine DT API as platforms continue to be mixed between those
      that boot using DT and those that do not.
      Suggested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NMatt Porter <mporter@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      864ef69b