Skip to content

K
Kernel

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

通知 5
Star 0
Fork 0
K
Kernel

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

切换分支/标签
  1. 31 7月, 2012 2 次提交
  3. 19 7月, 2012 7 次提交
    • S
      raid5: add a per-stripe lock · b17459c0
      由 Shaohua Li 提交于 
      Add a per-stripe lock to protect stripe specific data. The purpose is to reduce
lock contention of conf->device_lock.

stripe ->toread, ->towrite are protected by per-stripe lock.  Accessing bio
list of the stripe is always serialized by this lock, so adding bio to the
lists (add_stripe_bio()) and removing bio from the lists (like
ops_run_biofill()) not race.

If bio in ->read, ->written ... list are not shared by multiple stripes, we
don't need any lock to protect ->read, ->written, because STRIPE_ACTIVE will
protect them. If the bio are shared,  there are two protections:
1. bi_phys_segments acts as a reference count
2. traverse the list uses r5_next_bio, which makes traverse never access bio
not belonging to the stripe

Let's have an example:
|  stripe1 |  stripe2    |  stripe3  |
...bio1......|bio2|bio3|....bio4.....

stripe2 has 4 bios, when it's finished, it will decrement bi_phys_segments for
all bios, but only end_bio for bio2 and bio3. bio1->bi_next still points to
bio2, but this doesn't matter. When stripe1 is finished, it will not touch bio2
because of r5_next_bio check. Next time stripe1 will end_bio for bio1 and
stripe3 will end_bio bio4.

before add_stripe_bio() addes a bio to a stripe, we already increament the bio
bi_phys_segments, so don't worry other stripes release the bio.
Signed-off-by: NShaohua Li <shli@fusionio.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      b17459c0
    • S
      raid5: remove unnecessary bitmap write optimization · 7eaf7e8e
      由 Shaohua Li 提交于 
      Neil pointed out the bitmap write optimization in handle_stripe_clean_event()
is unnecessary, because the chance one stripe gets written twice in the mean
time is rare. We can always do a bitmap_startwrite when a write request is
added to a stripe and bitmap_endwrite after write request is done.  Delete the
optimization. With it, we can delete some cases of device_lock.
Signed-off-by: NShaohua Li <shli@fusionio.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      7eaf7e8e
    • S
      raid5: lockless access raid5 overrided bi_phys_segments · e7836bd6
      由 Shaohua Li 提交于 
      Raid5 overrides bio->bi_phys_segments, accessing it is with device_lock hold,
which is unnecessary, We can make it lockless actually.
Signed-off-by: NShaohua Li <shli@fusionio.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      e7836bd6
    • S
      raid5: reduce chance release_stripe() taking device_lock · 4eb788df
      由 Shaohua Li 提交于 
      release_stripe() is a place conf->device_lock is heavily contended. We take the
lock even stripe count isn't 1, which isn't required.
Signed-off-by: NShaohua Li <shli@fusionio.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      4eb788df
    • N
      md/raid1: close some possible races on write errors during resync · 58e94ae1
      由 NeilBrown 提交于 
      commit 4367af55
   md/raid1: clear bad-block record when write succeeds.

Added a 'reschedule_retry' call possibility at the end of
end_sync_write, but didn't add matching code at the end of
sync_request_write.  So if the writes complete very quickly, or
scheduling makes it seem that way, then we can miss rescheduling
the request and the resync could hang.

Also commit 73d5c38a
    md: avoid races when stopping resync.

Fix a race condition in this same code in end_sync_write but didn't
make the change in sync_request_write.

This patch updates sync_request_write to fix both of those.
Patch is suitable for 3.1 and later kernels.
Reported-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
Original-version-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>
      58e94ae1
    • N
      md: avoid crash when stopping md array races with closing other open fds. · a05b7ea0
      由 NeilBrown 提交于 
      md will refuse to stop an array if any other fd (or mounted fs) is
using it.
When any fs is unmounted of when the last open fd is closed all
pending IO will be flushed (e.g. sync_blockdev call in __blkdev_put)
so there will be no pending IO to worry about when the array is
stopped.

However in order to send the STOP_ARRAY ioctl to stop the array one
must first get and open fd on the block device.
If some fd is being used to write to the block device and it is closed
after mdadm open the block device, but before mdadm issues the
STOP_ARRAY ioctl, then there will be no last-close on the md device so
__blkdev_put will not call sync_blockdev.

If this happens, then IO can still be in-flight while md tears down
the array and bad things can happen (use-after-free and subsequent
havoc).

So in the case where do_md_stop is being called from an open file
descriptor, call sync_block after taking the mutex to ensure there
will be no new openers.

This is needed when setting a read-write device to read-only too.

Cc: stable@vger.kernel.org
Reported-by: Nmajianpeng <majianpeng@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      a05b7ea0
    • N
      md: fix bug in handling of new_data_offset · 25f7fd47
      由 NeilBrown 提交于 
      commit c6563a8c
    md: add possibility to change data-offset for devices.

introduced a 'new_data_offset' attribute which should normally
be the same as 'data_offset', but can be explicitly set to a different
value to allow a reshape operation to move the data.

Unfortunately when the 'data_offset' is explicitly set through
sysfs, the new_data_offset is not also set, so the two would become
out-of-sync incorrectly.

One result of this is that trying to set the 'size' after the
'data_offset' would fail because it is not permitted to set the size
when the 'data_offset' and 'new_data_offset' are different - as that
can be confusing.
Consequently when mdadm tried to do this while assembling an IMSM
array it would fail.

This bug was introduced in 3.5-rc1.
Reported-by: NBrian Downing <bdowning@lavos.net>
Bisected-by: NBrian Downing <bdowning@lavos.net>
Tested-by: NBrian Downing <bdowning@lavos.net>
Signed-off-by: NNeilBrown <neilb@suse.de>
      25f7fd47
  5. 15 7月, 2012 1 次提交
  7. 14 7月, 2012 1 次提交
  9. 13 7月, 2012 3 次提交
  11. 12 7月, 2012 7 次提交
  13. 11 7月, 2012 11 次提交
  15. 10 7月, 2012 2 次提交
  17. 09 7月, 2012 6 次提交
    • N
      md/raid1: fix use-after-free bug in RAID1 data-check code. · 2d4f4f33
      由 NeilBrown 提交于 
      This bug has been present ever since data-check was introduce
in 2.6.16.  However it would only fire if a data-check were
done on a degraded array, which was only possible if the array
has 3 or more devices.  This is certainly possible, but is quite
uncommon.

Since hot-replace was added in 3.3 it can happen more often as
the same condition can arise if not all possible replacements are
present.

The problem is that as soon as we submit the last read request, the
'r1_bio' structure could be freed at any time, so we really should
stop looking at it.  If the last device is being read from we will
stop looking at it.  However if the last device is not due to be read
from, we will still check the bio pointer in the r1_bio, but the
r1_bio might already be free.

So use the read_targets counter to make sure we stop looking for bios
to submit as soon as we have submitted them all.

This fix is suitable for any -stable kernel since 2.6.16.

Cc: stable@vger.kernel.org
Reported-by: NArnold Schulz <arnysch@gmx.net>
Signed-off-by: NNeilBrown <neilb@suse.de>
      2d4f4f33
    • M
      virtio-balloon: fix add/get API use · 9c378abc
      由 Michael S. Tsirkin 提交于 
      Since ee7cd898 'virtio: expose added
descriptors immediately.', in virtio balloon virtqueue_get_buf might
now run concurrently with virtqueue_kick.  I audited both and this
seems safe in practice but this is not guaranteed by the API.
Additionally, a spurious interrupt might in theory make
virtqueue_get_buf run in parallel with virtqueue_add_buf, which is
racy.

While we might try to protect against spurious callbacks it's
easier to fix the driver: balloon seems to be the only one
(mis)using the API like this, so let's just fix balloon.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (removed unused var)
      9c378abc
    • G
      mfd: Add missing hunk to change palmas irq to clear on read · b330f85d
      由 Graeme Gregory 提交于 
      During conversion to regmap_irq this hunk was missing being moved
to MFD driver to put the chip into clear on read mode. Also as slave
is now set use it to determine which slave for the register call.
Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      b330f85d
    • G
      mfd: Fix palmas regulator pdata missing · adc20e02
      由 Graeme Gregory 提交于 
      Due to a merge error the section of code passing the pdata for the
regulator driver to the mfd_add_devices via the children structure
was missing. This corrects this problem.
Signed-off-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      adc20e02
    • R
      mfd: USB: Fix the omap-usb EHCI ULPI PHY reset fix issues. · c05995c3
      由 Russ Dill 提交于 
      'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c omap_usbhs_init by releasing reset while the
configuration in that function was done.

This change caused a regression on BB-xM where USB would not function
if 'usb start' had been run from u-boot before booting. A change was
made to release reset a little bit earlier which fixed the issue on
BB-xM and did not cause any regressions on 3430 sdp, the board for
which the fix was originally made.

This new fix, 'USB: EHCI: OMAP: Finish ehci omap phy reset cycle
before adding hcd.', (3aa2ae74) caused a regression on OMAP5.

The original fix to hold the EHCI controller in reset during
initialization was correct, however it appears that changing
omap_usbhs_init to not hold the PHYs in reset during it's
configuration was incorrect. This patch first reverts both fixes, and
then changes ehci_hcd_omap_probe in ehci-omap.c to hold the PHYs in
reset as the original patch had done. It also is sure to incorporate
the _cansleep change that has been made in the meantime.

I've tested this on Beagleboard xM, I'd really like to get an ack from
the 3430 sdp and OMAP5 guys before getting this merged.

v3 - Brown paper bag its too early in the morning actually run
     git commit amend fix
v2 - Put cansleep gpiolib call outside of spinlock
Acked-by: NMantesh Sarashetti <mantesh@ti.com>
Tested-by: NMantesh Sarashetti <mantesh@ti.com>
Acked-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Tested-by: NKeshava Munegowda <keshava_mgowda@ti.com>
Signed-off-by: NRuss Dill <Russ.Dill@gmail.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      c05995c3
    • P
      mfd: Update twl6040 Kconfig to avoid build breakage · 487bae3c
      由 Peter Ujfalusi 提交于 
      twl6040 needs CONFIG_IRQ_DOMAIN to compile, without this we have:
drivers/mfd/twl6040-irq.c: In function 'twl6040_irq_init':
drivers/mfd/twl6040-irq.c:164:2: error: implicit declaration of function 'irq_domain_add_legacy'
drivers/mfd/twl6040-irq.c:165:11: error: 'irq_domain_simple_ops' undeclared (first use in this function)
drivers/mfd/twl6040-irq.c:165:11: note: each undeclared identifier is reported only once for each function it appears in
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      487bae3c