Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 1月, 2014 3 次提交
    • T
      scsi: use device_remove_file_self() instead of device_schedule_callback() · de1dee78
      由 Tejun Heo 提交于 
      driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal.  Use it
instead of device_schedule_callback().  This makes "delete" behave
synchronously.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de1dee78
    • T
      pci: use device_remove_file_self() instead of device_schedule_callback() · 6716d289
      由 Tejun Heo 提交于 
      driver-core now supports synchrnous self-deletion of attributes and
the asynchrnous removal mechanism is scheduled for removal.  Use it
instead of device_schedule_callback().  This makes "remove" behave
synchronously.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6716d289
    • T
      kernfs, sysfs, driver-core: implement kernfs_remove_self() and its wrappers · 1ae06819
      由 Tejun Heo 提交于 
      Sometimes it's necessary to implement a node which wants to delete
nodes including itself.  This isn't straightforward because of kernfs
active reference.  While a file operation is in progress, an active
reference is held and kernfs_remove() waits for all such references to
drain before completing.  For a self-deleting node, this is a deadlock
as kernfs_remove() ends up waiting for an active reference that itself
is sitting on top of.

This currently is worked around in the sysfs layer using
sysfs_schedule_callback() which makes such removals asynchronous.
While it works, it's rather cumbersome and inherently breaks
synchronicity of the operation - the file operation which triggered
the operation may complete before the removal is finished (or even
started) and the removal may fail asynchronously.  If a removal
operation is immmediately followed by another operation which expects
the specific name to be available (e.g. removal followed by rename
onto the same name), there's no way to make the latter operation
reliable.

The thing is there's no inherent reason for this to be asynchrnous.
All that's necessary to do this synchronous is a dedicated operation
which drops its own active ref and deactivates self.  This patch
implements kernfs_remove_self() and its wrappers in sysfs and driver
core.  kernfs_remove_self() is to be called from one of the file
operations, drops the active ref and deactivates using
__kernfs_deactivate_self(), removes the self node, and restores active
ref to the dead node using __kernfs_reactivate_self() so that the ref
is balanced afterwards.  __kernfs_remove() is updated so that it takes
an early exit if the target node is already fully removed so that the
active ref restored by kernfs_remove_self() after removal doesn't
confuse the deactivation path.

This makes implementing self-deleting nodes very easy.  The normal
removal path doesn't even need to be changed to use
kernfs_remove_self() for the self-deleting node.  The method can
invoke kernfs_remove_self() on itself before proceeding the normal
removal path.  kernfs_remove() invoked on the node by the normal
deletion path will simply be ignored.

This will replace sysfs_schedule_callback().  A subtle feature of
sysfs_schedule_callback() is that it collapses multiple invocations -
even if multiple removals are triggered, the removal callback is run
only once.  An equivalent effect can be achieved by testing the return
value of kernfs_remove_self() - only the one which gets %true return
value should proceed with actual deletion.  All other instances of
kernfs_remove_self() will wait till the enclosing kernfs operation
which invoked the winning instance of kernfs_remove_self() finishes
and then return %false.  This trivially makes all users of
kernfs_remove_self() automatically show correct synchronous behavior
even when there are multiple concurrent operations - all "echo 1 >
delete" instances will finish only after the whole operation is
completed by one of the instances.

v2: For !CONFIG_SYSFS, dummy version kernfs_remove_self() was missing
    and sysfs_remove_file_self() had incorrect return type.  Fix it.
    Reported by kbuild test bot.

v3: Updated to use __kernfs_{de|re}activate_self().
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ae06819
  3. 09 1月, 2014 3 次提交
    • B
      firmware_class: Fix the file size check · 08da2012
      由 Ben Hutchings 提交于 
      We expect to read firmware blobs with a single call to kernel_read(),
which returns int.  Therefore the size must be within the range of
int, not long.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08da2012
    • B
      driver-core: Fix use-after-free triggered by bus_unregister() · 174be70b
      由 Bart Van Assche 提交于 
      Avoid that bus_unregister() triggers a use-after-free with
CONFIG_DEBUG_KOBJECT_RELEASE=y. This patch avoids that the
following sequence triggers a kernel crash with memory poisoning
enabled:
* bus_register()
* driver_register()
* driver_unregister()
* bus_unregister()

The above sequence causes the bus private data to be freed from
inside the bus_unregister() call although it is not guaranteed in
that function that the reference count on the bus private data has
dropped to zero. As an example, with CONFIG_DEBUG_KOBJECT_RELEASE=y
the ${bus}/drivers kobject is still holding a reference on
bus->p->subsys.kobj via its parent pointer at the time the bus
private data is freed. Fix this by deferring freeing the bus private
data until the last kobject_put() call on bus->p->subsys.kobj.

The kernel oops triggered by the above sequence and with memory
poisoning enabled and that is fixed by this patch is as follows:

general protection fault: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 2711 Comm: kworker/3:32 Tainted: G        W  O 3.13.0-rc4-debug+ #1
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: events kobject_delayed_cleanup
task: ffff880037f866d0 ti: ffff88003b638000 task.ti: ffff88003b638000
Call Trace:
 [<ffffffff81263105>] ? kobject_get_path+0x25/0x100
 [<ffffffff81264354>] kobject_uevent_env+0x134/0x600
 [<ffffffff8126482b>] kobject_uevent+0xb/0x10
 [<ffffffff81262fa2>] kobject_delayed_cleanup+0xc2/0x1b0
 [<ffffffff8106c047>] process_one_work+0x217/0x700
 [<ffffffff8106bfdb>] ? process_one_work+0x1ab/0x700
 [<ffffffff8106c64b>] worker_thread+0x11b/0x3a0
 [<ffffffff8106c530>] ? process_one_work+0x700/0x700
 [<ffffffff81074b70>] kthread+0xf0/0x110
 [<ffffffff81074a80>] ? insert_kthread_work+0x80/0x80
 [<ffffffff815673bc>] ret_from_fork+0x7c/0xb0
 [<ffffffff81074a80>] ? insert_kthread_work+0x80/0x80
Code: 89 f8 48 89 e5 f6 82 c0 27 63 81 20 74 15 0f 1f 44 00 00 48 83 c0 01 0f b6 10 f6 82 c0 27 63 81 20 75 f0 5d c3 66 0f 1f 44 00 00 <80> 3f 00 55 48 89 e5 74 15 48 89 f8 0f 1f 40 00 48 83 c0 01 80
RIP  [<ffffffff81267ed0>] strlen+0x0/0x30
 RSP <ffff88003b639c70>
---[ end trace 210f883ef80376aa ]---
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      174be70b
    • B
      firmware loader: Add sparse annotation · 98233b21
      由 Bart Van Assche 提交于 
      Avoid that sparse reports the following warning on __fw_free_buf():

drivers/base/firmware_class.c:230:9: warning: context imbalance in '__fw_free_buf' - unexpected unlock
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Acked-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98233b21
  5. 21 12月, 2013 1 次提交
  7. 20 12月, 2013 3 次提交
  9. 19 12月, 2013 6 次提交
    • N
      target/file: Update hw_max_sectors based on current block_size · 95cadace
      由 Nicholas Bellinger 提交于 
      This patch allows FILEIO to update hw_max_sectors based on the current
max_bytes_per_io.  This is required because vfs_[writev,readv]() can accept
a maximum of 2048 iovecs per call, so the enforced hw_max_sectors really
needs to be calculated based on block_size.

This addresses a >= v3.5 bug where block_size=512 was rejecting > 1M
sized I/O requests, because FD_MAX_SECTORS was hardcoded to 2048 for
the block_size=4096 case.

(v2: Use max_bytes_per_io instead of ->update_hw_max_sectors)
Reported-by: NHenrik Goldman <hg@x-formation.com>
Cc: <stable@vger.kernel.org> #3.5+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      95cadace
    • N
      iser-target: Move INIT_WORK setup into isert_create_device_ib_res · 2853c2b6
      由 Nicholas Bellinger 提交于 
      This patch moves INIT_WORK setup for cq_desc->cq_[rx,tx]_work into
isert_create_device_ib_res(), instead of being done each callback
invocation in isert_cq_[rx,tx]_callback().

This also fixes a 'INFO: trying to register non-static key' warning
when cancel_work_sync() is called before INIT_WORK has setup the
struct work_struct.
Reported-by: NOr Gerlitz <ogerlitz@mellanox.com>
Cc: <stable@vger.kernel.org> #3.12+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      2853c2b6
    • N
      iscsi-target: Fix incorrect np->np_thread NULL assignment · db6077fd
      由 Nicholas Bellinger 提交于 
      When shutting down a target there is a race condition between
iscsit_del_np() and __iscsi_target_login_thread().
The latter sets the thread pointer to NULL, and the former
tries to issue kthread_stop() on that pointer without any
synchronization.

This patch moves the np->np_thread NULL assignment into
iscsit_del_np(), after kthread_stop() has completed. It also
removes the signal_pending() + np_state check, and only
exits when kthread_should_stop() is true.
Reported-by: NHannes Reinecke <hare@suse.de>
Cc: <stable@vger.kernel.org> #3.12+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      db6077fd
    • R
      Driver core: Fix device_add_attrs() error code path · ecfbf6fd
      由 Rafael J. Wysocki 提交于 
      If the addition of dev_attr_online fails, device_add_attrs() should
remove device attribute groups as well as type and class attribute
groups before returning an error code.  Make that happen.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecfbf6fd
    • D
      net_dma: mark broken · 77873803
      由 Dan Williams 提交于 
      net_dma can cause data to be copied to a stale mapping if a
copy-on-write fault occurs during dma.  The application sees missing
data.

The following trace is triggered by modifying the kernel to WARN if it
ever triggers copy-on-write on a page that is undergoing dma:

 WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
 ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
 Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
 CPU: 24 PID: 2529 Comm: linbug Tainted: G        W    3.13.0-rc1+ #353
  00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
  ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
  ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
 Call Trace:
  [<ffffffff81751041>] dump_stack+0x46/0x58
  [<ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
  [<ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
  [<ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
  [<ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
  [<ffffffff81154a40>] do_wp_page+0xd0/0x790
  [<ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
  [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
  [<ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
  [<ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
  [<ffffffff810f3539>] ? trace_clock_local+0x9/0x10
  [<ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
  [<ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
  [<ffffffff8175ffce>] do_page_fault+0xe/0x10
  [<ffffffff8175c862>] page_fault+0x22/0x30
  [<ffffffff81643991>] ? __kfree_skb+0x51/0xd0
  [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
  [<ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
  [<ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
  [<ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
  [<ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
  [..]
 ---[ end trace e30e3b01191b7617 ]---
 Mapped at:
  [<ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
  [<ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
  [<ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
  [<ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
  [<ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:

...the problem is that the receive path falls back to cpu-copy in
several locations and this trace is just one of the areas.  A few
options were considered to fix this:

1/ sync all dma whenever a cpu copy branch is taken

2/ modify the page fault handler to hold off while dma is in-flight

Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
with cpu-copy.  Option 2 adds checks for behavior that is already documented as
broken when using get_user_pages().  At a minimum a debug mode is warranted to
catch and flag these violations of the dma-api vs get_user_pages().

Thanks to David for his reproducer.

Cc: <stable@vger.kernel.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
Reported-by: NDavid Whipple <whipple@securedatainnovations.ch>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      77873803
    • W
      dma: pl330: ensure DMA descriptors are zero-initialised · 0baf8f6a
      由 Will Deacon 提交于 
      I see the following splat with 3.13-rc1 when attempting to perform DMA:

[  253.004516] Alignment trap: not handling instruction e1902f9f at [<c0204b40>]
[  253.004583] Unhandled fault: alignment exception (0x221) at 0xdfdfdfd7
[  253.004646] Internal error: : 221 [#1] PREEMPT SMP ARM
[  253.004691] Modules linked in: dmatest(+) [last unloaded: dmatest]
[  253.004798] CPU: 0 PID: 671 Comm: kthreadd Not tainted 3.13.0-rc1+ #2
[  253.004864] task: df9b0900 ti: df03e000 task.ti: df03e000
[  253.004937] PC is at dmaengine_unmap_put+0x14/0x34
[  253.005010] LR is at pl330_tasklet+0x3c8/0x550
[  253.005087] pc : [<c0204b44>]    lr : [<c0207478>]    psr: a00e0193
[  253.005087] sp : df03fe48  ip : 00000000  fp : df03bf18
[  253.005178] r10: bf00e108  r9 : 00000001  r8 : 00000000
[  253.005245] r7 : df837040  r6 : dfb41800  r5 : df837048  r4 : df837000
[  253.005316] r3 : dfdfdfcf  r2 : dfb41f80  r1 : df837048  r0 : dfdfdfd7
[  253.005384] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  253.005459] Control: 30c5387d  Table: 9fb9ba80  DAC: fffffffd
[  253.005520] Process kthreadd (pid: 671, stack limit = 0xdf03e248)

This is due to desc->txd.unmap containing garbage (uninitialised memory).

Rather than add another dummy initialisation to _init_desc, instead
ensure that the descriptors are zero-initialised during allocation and
remove the dummy, per-field initialisation.

Cc: Andriy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      0baf8f6a
  11. 18 12月, 2013 24 次提交