* Re: [PATCH] md: don't use flush_signals in userspace processes
From: NeilBrown @ 2017-06-08 6:59 UTC (permalink / raw)
To: Mikulas Patocka, Shaohua Li
Cc: linux-raid, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LRH.2.02.1706071834250.22850@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]
On Wed, Jun 07 2017, Mikulas Patocka wrote:
> The function flush_signals clears all pending signals for the process. It
> may be used by kernel threads when we need to prepare a kernel thread for
> responding to signals. However using this function for an userspaces
> processes is incorrect - clearing signals without the program expecting it
> can cause misbehavior.
>
> The raid1 and raid5 code uses flush_signals in its request routine because
> it wants to prepare for an interruptible wait. This patch drops
> flush_signals and uses sigprocmask instead to block all signals (including
> SIGKILL) around the schedule() call. The signals are not lost, but the
> schedule() call won't respond to them.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable@vger.kernel.org
Thanks for catching that!
Acked-by: NeilBrown <neilb@suse.com>
NeilBrown
>
> ---
> drivers/md/raid1.c | 5 ++++-
> drivers/md/raid5.c | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> Index: linux-4.12-rc4/drivers/md/raid1.c
> ===================================================================
> --- linux-4.12-rc4.orig/drivers/md/raid1.c
> +++ linux-4.12-rc4/drivers/md/raid1.c
> @@ -1335,7 +1335,7 @@ static void raid1_write_request(struct m
> */
> DEFINE_WAIT(w);
> for (;;) {
> - flush_signals(current);
> + sigset_t full, old;
> prepare_to_wait(&conf->wait_barrier,
> &w, TASK_INTERRUPTIBLE);
> if (bio_end_sector(bio) <= mddev->suspend_lo ||
> @@ -1345,7 +1345,10 @@ static void raid1_write_request(struct m
> bio->bi_iter.bi_sector,
> bio_end_sector(bio))))
> break;
> + sigfillset(&full);
> + sigprocmask(SIG_BLOCK, &full, &old);
> schedule();
> + sigprocmask(SIG_SETMASK, &old, NULL);
> }
> finish_wait(&conf->wait_barrier, &w);
> }
> Index: linux-4.12-rc4/drivers/md/raid5.c
> ===================================================================
> --- linux-4.12-rc4.orig/drivers/md/raid5.c
> +++ linux-4.12-rc4/drivers/md/raid5.c
> @@ -5693,12 +5693,15 @@ static void raid5_make_request(struct md
> * userspace, we want an interruptible
> * wait.
> */
> - flush_signals(current);
> prepare_to_wait(&conf->wait_for_overlap,
> &w, TASK_INTERRUPTIBLE);
> if (logical_sector >= mddev->suspend_lo &&
> logical_sector < mddev->suspend_hi) {
> + sigset_t full, old;
> + sigfillset(&full);
> + sigprocmask(SIG_BLOCK, &full, &old);
> schedule();
> + sigprocmask(SIG_SETMASK, &old, NULL);
> do_prepare = true;
> }
> goto retry;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH 2/3 v1] mdadm/test: Refactor the codes of 'test' script
From: Zhilong Liu @ 2017-06-08 9:20 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-raid, Zhilong Liu
In-Reply-To: <1496827888-17118-3-git-send-email-zlliu@suse.com>
Adding functions:
die()
uniform the abnormal situations that have to abort.
check_env()
do various basic checking before running test suite.
save_log()
collect array infos, include of dmesg, superblock,
bitmap and /proc/mdstat.
main()
the core function of this script.
Improve functions:
cleanup()
clear dmesg and remove the /vat/tmp/mdtest* files.
mdadm()
clear superblock once creating or building arrays
every time, because it's always creating arrays
many times in a test case.
check()
just tidy up with die(), didn't change code meanings.
testdev()
add checking $1 must be a block device, add 'return 0'
in final because this function exists in last line of
test case, such as tests/05r6tor0.
do_test()
add checking abnormal dmesg and changing log management.
do_help()
just recommend a better way to print Usage.
parse_args()
just tidy up.
Signed-off-by: Zhilong Liu <zlliu@suse.com>
---
test | 346 +++++++++++++++++++++++++++++++++++++------------------------------
1 file changed, 191 insertions(+), 155 deletions(-)
diff --git a/test b/test
index 7942d6e..37b3096 100755
--- a/test
+++ b/test
@@ -1,35 +1,17 @@
#!/bin/bash
#
# run test suite for mdadm
-user=`id -un`
-if [ " $user" != " root" ]
-then
- echo >&2 "test: testing can only be done as 'root'."
- exit 1
-fi
-
-prefix='[0-9][0-9]'
-
-dir=`pwd`
+dir=$(pwd)
mdadm=$dir/mdadm
-if [ \! -x $mdadm ]
-then
- echo >&2 "test: $mdadm isn't usable."
-fi
-
testdir="tests"
-logdir="$testdir/logs"
-logsave=0
-exitonerror=1
+targetdir="/var/tmp"
+logdir="$targetdir"
+config=/tmp/mdadm.conf
-echo "Testing on linux-$(uname -r) kernel"
+savelogs=0
+exitonerror=1
+prefix='[0-9][0-9]'
-# Check whether to run multipath tests
-modprobe multipath 2> /dev/null
-if grep -s 'Personalities : .*multipath' > /dev/null /proc/mdstat
-then
- MULTIPATH="yes"
-fi
INTEGRITY=yes
DEVTYPE=loop
LVM_VOLGROUP=mdtest
@@ -46,7 +28,6 @@ mdp1=/dev/md_d1
# We test mdadm on loop-back block devices.
# dir for storing files should be settable by command line maybe
-targetdir=/var/tmp
size=20000
# super0, round down to multiple of 64 and substract 64
mdsize0=19904
@@ -68,7 +49,51 @@ mdsize12=19988
# ddf needs bigger devices as 32Meg is reserved!
ddfsize=65536
-config=/tmp/mdadm.conf
+# $1 is optional parameter, it shows why to save log
+save_log() {
+ status=$1
+ logfile="$status""$_basename".log
+
+ cat $targetdir/stderr >> $targetdir/log
+ cp $targetdir/log $logdir/$_basename.log
+ echo "## $HOSTNAME: saving dmesg." >> $logdir/$logfile
+ dmesg -c >> $logdir/$logfile
+ $mdadm -As 2> /dev/null
+ echo "## $HOSTNAME: saving proc mdstat." >> $logdir/$logfile
+ cat /proc/mdstat >> $logdir/$logfile
+ array=($(mdadm -Ds | cut -d' ' -f2))
+ echo "## $HOSTNAME: mdadm -D ${array[@]}" >> $logdir/$logfile
+ $mdadm -D ${array[@]} >> $logdir/$logfile
+ [ "$1" == "fail" ] &&
+ echo "FAILED - see $logdir/$_basename.log and $logdir/$logfile for details"
+ # ignore saving external(external file, imsm...) bitmap
+ cat /proc/mdstat | grep -q "linear\|external" && return 0
+ if [ $DEVTYPE == 'lvm' ]
+ then
+ # not supported lvm type yet
+ echo
+ elif [ $DEVTYPE == 'loop' ]
+ then
+ if [ ! -z ${array[@]} -a ${#array[@]} -ge 1 ]
+ then
+ md_disks=($($mdadm -D -Y ${array[@]} | grep "/dev/$DEVTYPE" | cut -d'=' -f2))
+ cat /proc/mdstat | grep -q "bitmap"
+ if [ $? -eq 0 ]
+ then
+ echo "## $HOSTNAME: mdadm -X ${md_disks[@]}" >> $logdir/$logfile
+ $mdadm -X ${md_disks[@]} >> $logdir/$logfile
+ fi
+ else
+ echo "## $HOSTNAME: no array assembled!" >> $logdir/$logfile
+ fi
+ fi
+}
+
+die() {
+ echo -e "\n\tERROR: $* \n"
+ save_log fail
+ exit 2
+}
cleanup() {
udevadm settle
@@ -77,8 +102,9 @@ cleanup() {
loop)
for d in 0 1 2 3 4 5 6 7 8 9 10 11 12 13
do
- losetup -d /dev/loop$d # rm -f $targetdir/mdtest$d
+ losetup -d /dev/loop$d
rm -f /dev/disk/by-path/loop*
+ rm -f /var/tmp/mdtest$d
done
;;
lvm)
@@ -88,6 +114,7 @@ cleanup() {
done
;;
esac
+ dmesg -c > /dev/null
}
ctrl_c() {
@@ -98,23 +125,21 @@ do_setup() {
trap cleanup 0 1 3 15
trap ctrl_c 2
+ [ -d $logdir ] || mkdir -p $logdir
# make sure there are no loop devices remaining.
# udev started things can sometimes prevent them being stopped
# immediately
while grep loop /proc/partitions > /dev/null 2>&1
do
- mdadm -Ss
+ $mdadm -Ssq
losetup -d /dev/loop[0-9]* 2> /dev/null
- sleep 1
+ sleep 0.2
done
devlist=
for d in 0 1 2 3 4 5 6 7 8 9 10 11 12 13
do
sz=$size
- if [ $d -gt 7 ]
- then
- sz=$ddfsize
- fi
+ [ $d -gt 7 ] && sz=$ddfsize
case $DEVTYPE in
loop)
[ -f $targetdir/mdtest$d ] ||
@@ -169,7 +194,17 @@ mdadm() {
;;
esac
case $* in
- *-C* )
+ *-C* | *--create* | *-B* | *--build* )
+ # clear superblock every time once creating or
+ # building arrays, because it's always creating
+ # and building array many times in a test case.
+ for args in $*
+ do
+ [[ $args =~ "/dev/" ]] && {
+ [[ $args =~ "md" ]] ||
+ $mdadm --zero $args > /dev/null
+ }
+ done
$mdadm 2> $targetdir/stderr --quiet "$@" --auto=yes
;;
* )
@@ -191,39 +226,28 @@ mdadm() {
check() {
case $1 in
spares )
- spares=`tr '] ' '\012\012' < /proc/mdstat | grep -c '(S)' || exit 0`
- if [ $spares -ne $2 ]
- then
- echo >&2 "ERROR expected $2 spares, found $spares"
- exit 1
- fi
+ spares=$(tr '] ' '\012\012' < /proc/mdstat | grep -c '(S)' || exit 0)
+ [ $spares -ne $2 ] &&
+ die "expected $2 spares, found $spares"
;;
raid* | linear )
- grep -s "active $1 " /proc/mdstat > /dev/null || {
- echo >&2 "ERROR active $1 not found"
- cat /proc/mdstat
- exit 1
- }
+ grep -sq "active $1 " /proc/mdstat ||
+ die "active $1 not found"
;;
algorithm )
- grep -s " algorithm $2 " /proc/mdstat > /dev/null || {
- echo >&2 "ERROR algorithm $2 not found"
- cat /proc/mdstat
- exit 1
- }
+ grep -sq " algorithm $2 " /proc/mdstat ||
+ die "algorithm $2 not found"
;;
resync | recovery | reshape )
cnt=5
- while ! grep -s $1 /proc/mdstat > /dev/null
+ while ! grep -sq $1 /proc/mdstat
do
if [ $cnt -gt 0 ] && grep -v idle /sys/block/md*/md/sync_action > /dev/null
then # Something isn't idle - wait a bit
sleep 0.5
cnt=$[cnt-1]
else
- echo >&2 ERROR no $1 happening
- cat /proc/mdstat
- exit 1
+ die "no $1 happening"
fi
done
;;
@@ -234,22 +258,18 @@ check() {
# to do can still take a little longer than expected.
# add an extra check: is sync_completed shows the end is reached, assume
# there is no recovery.
- if grep -s -E '(resync|recovery|reshape) *=' > /dev/null /proc/mdstat
+ if grep -sq -E '(resync|recovery|reshape) *=' /proc/mdstat
then
incomplete=`grep / /sys/block/md*/md/sync_completed 2> /dev/null | sed '/^ *\([0-9]*\) \/ \1/d'`
- if [ -n "$incomplete" ]
- then
- echo >&2 "ERROR resync or recovery is happening!"
- cat /proc/mdstat
- exit 1
- fi
+ [ -n "$incomplete" ] &&
+ die "resync or recovery is happening!"
fi
;;
wait )
p=`cat /proc/sys/dev/raid/speed_limit_max`
echo 2000000 > /proc/sys/dev/raid/speed_limit_max
sleep 0.1
- while grep -E '(resync|recovery|reshape|check|repair) *=' > /dev/null /proc/mdstat ||
+ while grep -Eq '(resync|recovery|reshape|check|repair) *=' /proc/mdstat ||
grep -v idle > /dev/null /sys/block/md*/md/sync_action
do
sleep 0.5
@@ -257,45 +277,28 @@ check() {
echo $p > /proc/sys/dev/raid/speed_limit_max
;;
state )
- grep -s "blocks.*\[$2\]\$" /proc/mdstat > /dev/null || {
- echo >&2 "ERROR state $2 not found!"
- cat /proc/mdstat
- exit 1
- }
+ grep -sq "blocks.*\[$2\]\$" /proc/mdstat ||
+ die "state $2 not found!"
sleep 0.5
;;
bitmap )
- grep -s bitmap > /dev/null /proc/mdstat || {
- echo >&2 ERROR no bitmap
- cat /proc/mdstat
- exit 1
- }
+ grep -sq bitmap /proc/mdstat ||
+ die "no bitmap"
;;
nobitmap )
- if grep -s "bitmap" > /dev/null /proc/mdstat
- then
- echo >&2 ERROR bitmap present
- cat /proc/mdstat
- exit 1
- fi
+ grep -sq "bitmap" /proc/mdstat &&
+ die "bitmap present"
;;
readonly )
- grep -s "read-only" > /dev/null /proc/mdstat || {
- echo >&2 "ERROR array is not read-only!"
- cat /proc/mdstat
- exit 1
- }
+ grep -sq "read-only" /proc/mdstat ||
+ die "array is not read-only!"
;;
inactive )
- grep -s "inactive" > /dev/null /proc/mdstat || {
- echo >&2 "ERROR array is not inactive!"
- cat /proc/mdstat
- exit 1
- }
+ grep -sq "inactive" /proc/mdstat ||
+ die "array is not inactive!"
;;
* )
- echo >&2 ERROR unknown check $1
- exit 1
+ die "unknown check $1"
;;
esac
}
@@ -311,6 +314,8 @@ no_errors() {
# basic device test
testdev() {
+ # $1 must be a block device
+ [ -b $1 ] || die "$1 isn't a block device."
udevadm settle
dev=$1
cnt=$2
@@ -329,20 +334,11 @@ testdev() {
rasize=$[rasize/DEV_ROUND_K/2]
rasize=$[rasize*DEV_ROUND_K*2]
fi
- if [ `/sbin/blockdev --getsize $dev` -eq 0 ]
- then
- sleep 2
- fi
+ [ `/sbin/blockdev --getsize $dev` -eq 0 ] && sleep 2
_sz=`/sbin/blockdev --getsize $dev`
- if [ $rasize -lt $_sz -o $[rasize*4/5] -gt $_sz ]
- then
- echo "ERROR: size is wrong for $dev: $cnt * $dvsize (chunk=$chunk) = $rasize, not $_sz"
- exit 1
- fi
-}
-
-fast_sync() {
- echo 200000 > /proc/sys/dev/raid/speed_limit_max
+ [ $rasize -lt $_sz -o $[rasize*4/5] -gt $_sz ] &&
+ die "size is wrong for $dev: $cnt * $dvsize (chunk=$chunk) = $rasize, not $_sz"
+ return 0
}
rotest() {
@@ -359,7 +355,6 @@ do_test() {
# stop all arrays, just incase some script left an array active.
$mdadm -Ssq 2> /dev/null
mdadm --zero $devlist 2> /dev/null
- mdadm --zero $devlist 2> /dev/null
# this might have been reset: restore the default.
echo 2000 > /proc/sys/dev/raid/speed_limit_max
# source script in a subshell, so it has access to our
@@ -367,45 +362,40 @@ do_test() {
echo -ne "$_script... "
if ( set -ex ; . $_script ) &> $targetdir/log
then
+ dmesg | grep -iq "error\|call trace\|segfault" &&
+ die "dmesg prints errors when testing $_basename!"
echo "succeeded"
_fail=0
else
- log=log
- cat $targetdir/stderr >> $targetdir/log
- echo "=======================dmesg=================" >> $targetdir/log
- dmesg | tail -n 200 >> $targetdir/log
- if [ $exitonerror == 0 ]; then
- log=log-`basename $_script`
- mv $targetdir/log $logdir/$log
- fi
- echo "FAILED - see $logdir/$log for details"
+ save_log fail
_fail=1
fi
if [ "$savelogs" == "1" ]
then
- cp $targetdir/log $logdir/$_basename.log
- fi
- if [ "$_fail" == "1" -a "$exitonerror" == "1" ]
- then
- exit 1
+ [ "$targetdir" != "$logdir" ] &&
+ mv -f $targetdir/log $logdir/$_basename.log
fi
+ [ "$_fail" == "1" -a "$exitonerror" == "1" ] && exit 1
fi
}
do_help() {
- echo "Usage: $0 [options]"
- echo " Options:"
- echo " --tests=<test1,test2,..> Comma separated list of tests to run"
- echo " --disable-multipath Disable any tests involving multipath"
- echo " --disable-integrity Disable slow tests of RAID[56] consistency"
- echo " --logdir=<directory> Directory to save logfiles in"
- echo " --save-logs Save all logs in <logdir>"
- echo " --keep-going Don't stop on error, ie. run all tests"
- echo " --dev=[loop|lvm|ram] Use loop devices (default), LVM, or RAM disk"
- echo " --volgroup=<name> LVM volume group for LVM test"
- echo " setup Setup test environment and exit"
- echo " cleanup Cleanup test environment"
- echo " <prefix> Run tests with <prefix>"
+ cat <<-EOF
+ Usage: $0 [options]
+ Options:
+ --tests=<test1,test2,..> Comma separated list of tests to run
+ --disable-multipath Disable any tests involving multipath
+ --disable-integrity Disable slow tests of RAID[56] consistency
+ --logdir=<directory> Directory to save all logfiles in
+ --save-logs Usually use with --logdir together
+ --keep-going Don't stop on error, ie. run all tests
+ --dev=[loop|lvm|ram] Use loop devices (default), LVM, or RAM disk
+ --volgroup=<name> LVM volume group for LVM test
+ setup Setup test environment and exit
+ cleanup Cleanup test environment
+ <prefix> Run tests with <prefix>
+ EOF
+ exit 0
}
parse_args() {
@@ -457,38 +447,84 @@ parse_args() {
;;
--help )
do_help
- exit 0
;;
-* )
echo " $0: Unknown argument: $i"
do_help
- exit 0
;;
esac
done
}
-logdir=$targetdir
-parse_args $@
+check_env() {
+ user=$(id -un)
+ [ "X$user" != "Xroot" ] && {
+ echo "test: testing can only be done as 'root'."
+ exit 1
+ }
+ [ -x "raid6check" -a -x $mdadm ] || {
+ echo "test: please run 'make everything' before perform testing."
+ exit 1
+ }
+ for cmd in mdadm lsblk df udevadm losetup mkfs.ext3
+ do
+ which $cmd > /dev/null || {
+ echo "$cmd command not found!"
+ exit 1
+ }
+ done
+ mdadm_src_ver="$($mdadm -V 2>&1)"
+ mdadm_sbin_ver="$($(which mdadm) -V 2>&1)"
+ if [ "$mdadm_src_ver" != "$mdadm_sbin_ver" ]
+ then
+ # it's nessesary to 'make install' mdadm to /SBIN/DIR,
+ # such as systemd/mdadm-grow-continue@.service, would
+ # run as an instance by systemd when reshape happens,
+ # thus ensure that the correct mdadm is in testing.
+ echo "test: please run 'make install' before testing."
+ exit 1
+ fi
+ if ! $(df -T . | grep -iq ext)
+ then
+ # 'external file' bitmap only supports with ext[2-4] file system
+ echo "test: please run test suite with ext[2-4] file system."
+ exit 1
+ fi
+ if $(lsblk -a | grep -iq raid)
+ then
+ # For test purpose, it's better to make environment simple,
+ # donot run mdadm -Ss directly if there are RAIDs working.
+ echo "test: please run test suite without running RAIDs environment."
+ exit 1
+ fi
+ # Check whether to run multipath tests
+ modprobe multipath 2> /dev/null
+ grep -sq 'Personalities : .*multipath' /proc/mdstat &&
+ MULTIPATH="yes"
+}
-do_setup
-mkdir -p $logdir
+main() {
+ check_env
+ do_setup
+
+ echo "Testing on linux-$(uname -r) kernel"
+ [ "$savelogs" == "1" ] &&
+ echo "Saving logs to $logdir"
+ if [ "x$TESTLIST" != "x" ]
+ then
+ for script in $TESTLIST
+ do
+ do_test $testdir/$script
+ done
+ else
+ for script in $testdir/$prefix $testdir/$prefix*[^~]
+ do
+ do_test $script
+ done
+ fi
-if [ "$savelogs" == "1" ]
-then
- echo "Saving logs to $logdir"
-fi
+ exit 0
+}
-if [ "x$TESTLIST" != "x" ]
-then
- for script in $TESTLIST
- do
- do_test $testdir/$script
- done
-else
- for script in $testdir/$prefix $testdir/$prefix*[^~]
- do
- do_test $script
- done
-fi
-exit 0
+parse_args $@
+main
--
2.6.6
^ permalink raw reply related
* Re: kernel BUG at lib/percpu-refcount.c:192
From: Mike Snitzer @ 2017-06-08 13:38 UTC (permalink / raw)
To: Marian Csontos; +Cc: linux-raid, Heinz Mauelshagen, device-mapper development
In-Reply-To: <9dcf0086-6d8a-29db-2a27-6c63af988388@redhat.com>
On Thu, Jun 08 2017 at 4:29am -0400,
Marian Csontos <mcsontos@redhat.com> wrote:
> Mike, Heinz, help please!
>
> RC4 and still present:
>
> [ 248.815709] CPU: 0 PID: 21 Comm: rcuos/1 Not tainted
> 4.12.0-0.rc4.git2.1.fc27.x86_64 #1
> [ 248.816841] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
>
> ...and it affects RAID1 as well.
>
> Is this md wrong or is there a more serious issue? And if so is it a
> known one?
> I have not found any reference anywhere except this dm-devel thread.
> Is this a problem in LVM RAID only?
Unclear.
> Where to forward this? LKML? Fedora Bugzilla?
Certainly linux-raid (now cc'd).
> Is there anything else I should provide?
The linewrapping makes it hard to read these logs, but I'll defer to
others to weigh-in on any additional info needed.
Mike
> -- Martian
>
> On 05/18/2017 10:33 AM, Marian Csontos wrote:
> >When running `lvm lvcreate --type raid5 --size 4194304B --name
> >meta_r5 LVMTEST12279nqymhamb_vg --yes` there's a warning followed
> >by the bug.
> >
> >Also at [ 192.140142] it looks like there is an uninitialized
> >variable somewhere.
> >
> >env: rawhide, kvm, 2 (V)CPUs
> >lvm2: upstream
> >kernel: 4.12.0-0.rc1.git1.1.fc27.x86_64
> >
> >----
> >
> >[ 192.131076] mdX: bitmap file is out of date, doing full recovery
> >
> >[ 192.140142] percpu ref ( (null)) <= 0
> >(-9223372036854775807) after switching to atomic
> >
> >[ 192.140180] ------------[ cut here ]------------
> >[ 192.143734] WARNING: CPU: 0 PID: 10 at
> >lib/percpu-refcount.c:155
> >percpu_ref_switch_to_atomic_rcu+0x1cd/0x1f0
> >[ 192.146353] Modules linked in: dm_raid raid456
> >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> >[ 192.154276] CPU: 0 PID: 10 Comm: rcuos/0 Not tainted
> >4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> >[ 192.155684] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> >[ 192.156741] task: ffff8d5bb6e73100 task.stack: ffffa9a3c0360000
> >[ 192.157830] RIP: 0010:percpu_ref_switch_to_atomic_rcu+0x1cd/0x1f0
> >[ 192.158956] RSP: 0018:ffffa9a3c0363e50 EFLAGS: 00010282
> >[ 192.159899] RAX: 0000000000000053 RBX: 8000000000000000 RCX:
> >0000000000000000
> >[ 192.161192] RDX: 0000000000000000 RSI: ffff8d5bb6e73d90 RDI:
> >0000000000000247
> >[ 192.162483] RBP: ffffa9a3c0363e68 R08: 0000000000000000 R09:
> >0000000000000000
> >[ 192.163762] R10: ffffa9a3c0363e00 R11: 0000000000000000 R12:
> >0000000000000000
> >[ 192.165144] R13: ffff8d5bb5252580 R14: ffff8d5bb5252580 R15:
> >0000000000000000
> >[ 192.166437] FS: 0000000000000000(0000)
> >GS:ffff8d5bb7800000(0000) knlGS:0000000000000000
> >[ 192.169392] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >[ 192.171893] CR2: 00007ffc83d87d98 CR3: 0000000013e11000 CR4:
> >00000000000006f0
> >[ 192.174692] Call Trace:
> >[ 192.176627] ? percpu_ref_reinit+0x140/0x140
> >[ 192.178875] rcu_nocb_kthread+0x1ae/0x580
> >[ 192.181174] kthread+0x133/0x150
> >[ 192.183305] ? rcu_eqs_enter_common.constprop.68+0x1c0/0x1c0
> >[ 192.185813] ? kthread_create_on_node+0x70/0x70
> >[ 192.188110] ret_from_fork+0x31/0x40
> >[ 192.190338] Code: ff ff ff 80 3d a6 71 b9 00 00 0f 85 c1 fe ff
> >ff 49 8b 55 d8 49 8b 75 e8 48 c7 c7 f0 2b ce 8b c6 05 8a 71 b9 00
> >...|01 e8 89 95 d4 ff <0f> ff e9 9f fe ff ff f0 49 83 6d d8 01 0f
> >85 05 ff ff ff 48 89
> >[ 192.196842] ---[ end trace fbf926294c454ffa ]---
> >
> >[ 192.199425] ------------[ cut here ]------------
> >[ 192.200346] kernel BUG at lib/percpu-refcount.c:192!
> >[ 192.200346] invalid opcode: 0000 [#1] SMP
> >[ 192.200346] Modules linked in: dm_raid raid456
> >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> >[ 192.211647] CPU: 0 PID: 13767 Comm: mdX_raid5 Tainted: G
> >W 4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> >[ 192.211647] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> >[ 192.211647] task: ffff8d5bb15f3100 task.stack: ffffa9a3c0d10000
> >[ 192.211647] RIP: 0010:__percpu_ref_switch_mode+0x278/0x280
> >[ 192.211647] RSP: 0018:ffffa9a3c0d13ce8 EFLAGS: 00010046
> >[ 192.211647] RAX: 0000000000000001 RBX: ffff8d5bb5252558 RCX:
> >0000000000000000
> >[ 192.211647] RDX: 0000000000000001 RSI: ffffffff8c05a098 RDI:
> >0000000000000046
> >[ 192.211647] RBP: ffffa9a3c0d13d30 R08: 0000000000000001 R09:
> >0000000000000000
> >[ 192.211647] R10: ffffa9a3c0d13ca0 R11: ffffffff8c05a098 R12:
> >0000000000000000
> >[ 192.211647] R13: 0000000000000000 R14: ffff8d5bb15f3100 R15:
> >ffff8d5bb508f000
> >[ 192.211647] FS: 0000000000000000(0000)
> >GS:ffff8d5bb7800000(0000) knlGS:0000000000000000
> >[ 192.211647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >[ 192.211647] CR2: 00007ffc83d87d98 CR3: 0000000013e11000 CR4:
> >00000000000006f0
> >[ 192.211647] Call Trace:
> >[ 192.211647] percpu_ref_switch_to_percpu+0x27/0x40
> >[ 192.211647] set_in_sync+0xd4/0xe0
> >[ 192.211647] md_check_recovery+0x1f5/0x4e0
> >[ 192.211647] raid5d+0x56/0x6a0 [raid456]
> >[ 192.211647] ? finish_wait+0x72/0x90
> >[ 192.211647] ? trace_hardirqs_on_caller+0xf4/0x190
> >[ 192.211647] ? trace_hardirqs_on+0xd/0x10
> >[ 192.211647] md_thread+0x138/0x180
> >[ 192.211647] ? md_thread+0x138/0x180
> >[ 192.211647] ? finish_wait+0x90/0x90
> >[ 192.211647] kthread+0x133/0x150
> >[ 192.211647] ? find_pers+0x70/0x70
> >[ 192.211647] ? kthread_create_on_node+0x70/0x70
> >[ 192.211647] ret_from_fork+0x31/0x40
> >[ 192.211647] Code: f0 4a c8 8b be d5 03 00 00 48 c7 c7 b1 75 c7
> >8b c6 05 ef 75 b9 00 01 e8 97 d2 c4 ff e9 e8 fe ff ff f0 48 83 03
> >...|01 e9 bf fe ff ff <0f> 0b e8 21 d9 be ff 90 55 48 89 e5 41 55
> >41 54 53 48 89 fb 48
> >[ 192.211647] RIP: __percpu_ref_switch_mode+0x278/0x280 RSP:
> >ffffa9a3c0d13ce8
> >[ 192.211647] ---[ end trace fbf926294c454ffb ]---
> >
> >[ 192.211647] BUG: sleeping function called from invalid context
> >at ./include/linux/percpu-rwsem.h:33
> >[ 192.211647] in_atomic(): 1, irqs_disabled(): 1, pid: 13767,
> >name: mdX_raid5
> >[ 192.211647] INFO: lockdep is turned off.
> >[ 192.211647] irq event stamp: 68
> >[ 192.211647] hardirqs last enabled at (67):
> >[<ffffffff8b983586>] _raw_spin_unlock_irqrestore+0x36/0x60
> >[ 192.211647] hardirqs last disabled at (68):
> >[<ffffffff8b983c47>] _raw_spin_lock_irqsave+0x27/0x90
> >[ 192.211647] softirqs last enabled at (0): [<ffffffff8b0ae308>]
> >copy_process.part.26+0x618/0x1ee0
> >[ 192.211647] softirqs last disabled at (0): [< (null)>]
> >(null)
> >[ 192.211647] CPU: 0 PID: 13767 Comm: mdX_raid5 Tainted: G D
> >W 4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> >[ 192.211647] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> >[ 192.211647] Call Trace:
> >[ 192.211647] dump_stack+0x8e/0xcd
> >[ 192.211647] ___might_sleep+0x144/0x260
> >[ 192.211647] __might_sleep+0x4a/0x80
> >[ 192.211647] exit_signals+0x33/0x240
> >[ 192.211647] do_exit+0xb4/0xd30
> >[ 192.211647] ? kthread+0x133/0x150
> >[ 192.211647] ? find_pers+0x70/0x70
> >[ 192.211647] rewind_stack_do_exit+0x17/0x20
> >
> >[ 192.211647] note: mdX_raid5[13767] exited with preempt_count 2
> >
> >[ 220.071005] NMI watchdog: BUG: soft lockup - CPU#1 stuck for
> >22s! [lvm:13678]
> >[ 220.071079] Modules linked in: dm_raid raid456
> >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> >[ 220.083131] irq event stamp: 313716
> >[ 220.087117] hardirqs last enabled at (313715):
> >[<ffffffff8b983da7>] entry_SYSCALL_64_fastpath+0x5/0xbe
> >[ 220.091109] hardirqs last disabled at (313716):
> >[<ffffffff8b97afe4>] __schedule+0xc4/0xb40
> >[ 220.091109] softirqs last enabled at (301518):
> >[<ffffffff8b988d52>] __do_softirq+0x382/0x4ed
> >[ 220.095114] softirqs last disabled at (301511):
> >[<ffffffff8b0b8e7f>] irq_exit+0x10f/0x120
> >[ 220.099150] CPU: 1 PID: 13678 Comm: lvm Tainted: G D W
> >4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> >[ 220.103049] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> >[ 220.103049] task: ffff8d5bb3c03100 task.stack: ffffa9a3c155c000
> >[ 220.107103] RIP: 0010:queued_spin_lock_slowpath+0x25/0x1b0
> >[ 220.107103] RSP: 0018:ffffa9a3c155f720 EFLAGS: 00000202
> >ORIG_RAX: ffffffffffffff10
> >[ 220.111144] RAX: 0000000000000001 RBX: ffff8d5bb5252448 RCX:
> >0000000000000000
> >[ 220.115126] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
> >ffff8d5bb5252448
> >[ 220.115126] RBP: ffffa9a3c155f720 R08: 0000000000000000 R09:
> >0000000000000000
> >[ 220.119130] R10: ffffa9a3c155f6d0 R11: ffff8d5bb3c03100 R12:
> >ffff8d5bb5252448
> >[ 220.123139] R13: ffff8d5bb5252448 R14: ffff8d5bb379ca20 R15:
> >ffff8d5bb5252058
> >[ 220.127118] FS: 00007f1f8253b880(0000)
> >GS:ffff8d5bb7a00000(0000) knlGS:0000000000000000
> >[ 220.127118] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >[ 220.131158] CR2: 00007fe2715ae000 CR3: 0000000075108000 CR4:
> >00000000000006e0
> >[ 220.135114] Call Trace:
> >[ 220.135114] do_raw_spin_lock+0xb2/0xc0
> >[ 220.139145] _raw_spin_lock+0x55/0x70
> >[ 220.139145] md_write_start+0x143/0x360
> >[ 220.143126] ? probe_sched_wakeup+0x1c/0x20
> >[ 220.143126] ? check_preempt_curr+0x27/0xb0
> >[ 220.147147] raid5_make_request+0xd0/0x1060 [raid456]
> >[ 220.147147] ? _raw_spin_unlock_irqrestore+0x5b/0x60
> >[ 220.151162] ? try_to_wake_up+0x58/0x520
> >[ 220.151162] ? finish_wait+0x90/0x90
> >[ 220.155099] ? mempool_alloc_slab+0x1d/0x30
> >[ 220.155099] ? finish_wait+0x90/0x90
> >[ 220.159136] raid_map+0x2b/0x40 [dm_raid]
> >[ 220.159136] __map_bio+0xc9/0x2b0
> >[ 220.163115] ? dm_put_table_device+0xd0/0xd0
> >[ 220.163115] __split_and_process_bio+0x293/0x590
> >[ 220.167133] dm_make_request+0x7f/0x120
> >[ 220.167133] ? generic_make_request+0xf9/0x3b0
> >[ 220.171131] generic_make_request+0x126/0x3b0
> >[ 220.171131] ? iov_iter_get_pages+0xc9/0x300
> >[ 220.175138] submit_bio+0x73/0x150
> >[ 220.175138] ? submit_bio+0x73/0x150
> >[ 220.179132] ? bio_iov_iter_get_pages+0xe0/0x120
> >[ 220.179132] ? __blkdev_direct_IO_simple+0x168/0x320
> >[ 220.183114] __blkdev_direct_IO_simple+0x184/0x320
> >[ 220.183114] ? lock_acquire+0xa3/0x1f0
> >[ 220.187129] ? bdput+0x20/0x20
> >[ 220.187129] blkdev_direct_IO+0x3b1/0x3e0
> >[ 220.191112] ? blkdev_direct_IO+0x3b1/0x3e0
> >[ 220.191112] ? current_time+0x1a/0x70
> >[ 220.195108] ? trace_hardirqs_on+0xd/0x10
> >[ 220.195108] generic_file_direct_write+0x9c/0x110
> >[ 220.199114] ? generic_file_direct_write+0x9c/0x110
> >[ 220.199114] __generic_file_write_iter+0xbe/0x1d0
> >[ 220.199114] blkdev_write_iter+0x96/0x110
> >[ 220.203115] __vfs_write+0xe8/0x160
> >[ 220.203115] ? __vfs_write+0xe8/0x160
> >[ 220.207211] vfs_write+0xc6/0x1c0
> >[ 220.207211] SyS_write+0x58/0xc0
> >[ 220.207211] entry_SYSCALL_64_fastpath+0x1f/0xbe
> >[ 220.211130] RIP: 0033:0x7f1f81309290
> >[ 220.211130] RSP: 002b:00007fffba453af8 EFLAGS: 00000246
> >ORIG_RAX: 0000000000000001
> >[ 220.215116] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
> >00007f1f81309290
> >[ 220.215116] RDX: 0000000000001000 RSI: 000055f0c4ab4000 RDI:
> >000000000000000c
> >[ 220.219114] RBP: 00007f1f815d5583 R08: fffffffffffffff0 R09:
> >0000000000000000
> >[ 220.219114] R10: 00007f1f815d4b38 R11: 0000000000000246 R12:
> >0000000000000001
> >[ 220.223148] R13: 0000000000000001 R14: 00007f1f815d5500 R15:
> >00007f1f815d08c0
> >[ 220.223148] Code: 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5
> >66 66 90 66 90 ba 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0
> >...|75 f2 5d c3 f3 90 <eb> ec 81 fe 00 01 00 00 0f 84 1a 01 00 00
> >41 b8 01 01 00 00 b9
> >
> >--
> >dm-devel mailing list
> >dm-devel@redhat.com
> >https://www.redhat.com/mailman/listinfo/dm-devel
>
^ permalink raw reply
* [PATCH] Grow: don't allow array geometry change with ppl enabled
From: Tomasz Majchrzak @ 2017-06-08 14:05 UTC (permalink / raw)
To: linux-raid; +Cc: jes.sorensen, Tomasz Majchrzak
Don't allow array geometry change (size expand, disk adding) when PPL
consistency policy is enabled. Current PPL implementation doesn't work when
reshape is taking place.
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Grow.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Grow.c b/Grow.c
index 4ecb1d8..f7325cb 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1880,6 +1880,13 @@ int Grow_reshape(char *devname, int fd,
free(subarray);
return 1;
}
+ if (content->consistency_policy ==
+ CONSISTENCY_POLICY_PPL) {
+ pr_err("Operation not supported when ppl consistency policy is enabled\n");
+ sysfs_free(cc);
+ free(subarray);
+ return 1;
+ }
}
sysfs_free(cc);
}
--
1.8.3.1
^ permalink raw reply related
* Re: kernel BUG at lib/percpu-refcount.c:192
From: Shaohua Li @ 2017-06-08 17:07 UTC (permalink / raw)
To: Mike Snitzer
Cc: Marian Csontos, device-mapper development, Heinz Mauelshagen,
linux-raid
In-Reply-To: <20170608133829.GA32626@redhat.com>
On Thu, Jun 08, 2017 at 09:38:29AM -0400, Mike Snitzer wrote:
> On Thu, Jun 08 2017 at 4:29am -0400,
> Marian Csontos <mcsontos@redhat.com> wrote:
>
> > Mike, Heinz, help please!
> >
> > RC4 and still present:
> >
> > [ 248.815709] CPU: 0 PID: 21 Comm: rcuos/1 Not tainted
> > 4.12.0-0.rc4.git2.1.fc27.x86_64 #1
> > [ 248.816841] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> >
> > ...and it affects RAID1 as well.
> >
> > Is this md wrong or is there a more serious issue? And if so is it a
> > known one?
> > I have not found any reference anywhere except this dm-devel thread.
> > Is this a problem in LVM RAID only?
>
> Unclear.
>
> > Where to forward this? LKML? Fedora Bugzilla?
>
> Certainly linux-raid (now cc'd).
>
> > Is there anything else I should provide?
>
> The linewrapping makes it hard to read these logs, but I'll defer to
> others to weigh-in on any additional info needed.
Neil fixed a bug in this side recently, which is pretty similar like the
reported, I'll push the patch to upstream soon. Could you please try my
for-next tree, and check if you still have the issue?
Thanks,
Shaohua
>
> > -- Martian
> >
> > On 05/18/2017 10:33 AM, Marian Csontos wrote:
> > >When running `lvm lvcreate --type raid5 --size 4194304B --name
> > >meta_r5 LVMTEST12279nqymhamb_vg --yes` there's a warning followed
> > >by the bug.
> > >
> > >Also at [ 192.140142] it looks like there is an uninitialized
> > >variable somewhere.
> > >
> > >env: rawhide, kvm, 2 (V)CPUs
> > >lvm2: upstream
> > >kernel: 4.12.0-0.rc1.git1.1.fc27.x86_64
> > >
> > >----
> > >
> > >[ 192.131076] mdX: bitmap file is out of date, doing full recovery
> > >
> > >[ 192.140142] percpu ref ( (null)) <= 0
> > >(-9223372036854775807) after switching to atomic
> > >
> > >[ 192.140180] ------------[ cut here ]------------
> > >[ 192.143734] WARNING: CPU: 0 PID: 10 at
> > >lib/percpu-refcount.c:155
> > >percpu_ref_switch_to_atomic_rcu+0x1cd/0x1f0
> > >[ 192.146353] Modules linked in: dm_raid raid456
> > >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> > >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> > >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> > >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> > >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> > >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> > >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> > >[ 192.154276] CPU: 0 PID: 10 Comm: rcuos/0 Not tainted
> > >4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> > >[ 192.155684] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > >[ 192.156741] task: ffff8d5bb6e73100 task.stack: ffffa9a3c0360000
> > >[ 192.157830] RIP: 0010:percpu_ref_switch_to_atomic_rcu+0x1cd/0x1f0
> > >[ 192.158956] RSP: 0018:ffffa9a3c0363e50 EFLAGS: 00010282
> > >[ 192.159899] RAX: 0000000000000053 RBX: 8000000000000000 RCX:
> > >0000000000000000
> > >[ 192.161192] RDX: 0000000000000000 RSI: ffff8d5bb6e73d90 RDI:
> > >0000000000000247
> > >[ 192.162483] RBP: ffffa9a3c0363e68 R08: 0000000000000000 R09:
> > >0000000000000000
> > >[ 192.163762] R10: ffffa9a3c0363e00 R11: 0000000000000000 R12:
> > >0000000000000000
> > >[ 192.165144] R13: ffff8d5bb5252580 R14: ffff8d5bb5252580 R15:
> > >0000000000000000
> > >[ 192.166437] FS: 0000000000000000(0000)
> > >GS:ffff8d5bb7800000(0000) knlGS:0000000000000000
> > >[ 192.169392] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > >[ 192.171893] CR2: 00007ffc83d87d98 CR3: 0000000013e11000 CR4:
> > >00000000000006f0
> > >[ 192.174692] Call Trace:
> > >[ 192.176627] ? percpu_ref_reinit+0x140/0x140
> > >[ 192.178875] rcu_nocb_kthread+0x1ae/0x580
> > >[ 192.181174] kthread+0x133/0x150
> > >[ 192.183305] ? rcu_eqs_enter_common.constprop.68+0x1c0/0x1c0
> > >[ 192.185813] ? kthread_create_on_node+0x70/0x70
> > >[ 192.188110] ret_from_fork+0x31/0x40
> > >[ 192.190338] Code: ff ff ff 80 3d a6 71 b9 00 00 0f 85 c1 fe ff
> > >ff 49 8b 55 d8 49 8b 75 e8 48 c7 c7 f0 2b ce 8b c6 05 8a 71 b9 00
> > >...|01 e8 89 95 d4 ff <0f> ff e9 9f fe ff ff f0 49 83 6d d8 01 0f
> > >85 05 ff ff ff 48 89
> > >[ 192.196842] ---[ end trace fbf926294c454ffa ]---
> > >
> > >[ 192.199425] ------------[ cut here ]------------
> > >[ 192.200346] kernel BUG at lib/percpu-refcount.c:192!
> > >[ 192.200346] invalid opcode: 0000 [#1] SMP
> > >[ 192.200346] Modules linked in: dm_raid raid456
> > >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> > >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> > >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> > >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> > >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> > >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> > >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> > >[ 192.211647] CPU: 0 PID: 13767 Comm: mdX_raid5 Tainted: G
> > >W 4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> > >[ 192.211647] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > >[ 192.211647] task: ffff8d5bb15f3100 task.stack: ffffa9a3c0d10000
> > >[ 192.211647] RIP: 0010:__percpu_ref_switch_mode+0x278/0x280
> > >[ 192.211647] RSP: 0018:ffffa9a3c0d13ce8 EFLAGS: 00010046
> > >[ 192.211647] RAX: 0000000000000001 RBX: ffff8d5bb5252558 RCX:
> > >0000000000000000
> > >[ 192.211647] RDX: 0000000000000001 RSI: ffffffff8c05a098 RDI:
> > >0000000000000046
> > >[ 192.211647] RBP: ffffa9a3c0d13d30 R08: 0000000000000001 R09:
> > >0000000000000000
> > >[ 192.211647] R10: ffffa9a3c0d13ca0 R11: ffffffff8c05a098 R12:
> > >0000000000000000
> > >[ 192.211647] R13: 0000000000000000 R14: ffff8d5bb15f3100 R15:
> > >ffff8d5bb508f000
> > >[ 192.211647] FS: 0000000000000000(0000)
> > >GS:ffff8d5bb7800000(0000) knlGS:0000000000000000
> > >[ 192.211647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > >[ 192.211647] CR2: 00007ffc83d87d98 CR3: 0000000013e11000 CR4:
> > >00000000000006f0
> > >[ 192.211647] Call Trace:
> > >[ 192.211647] percpu_ref_switch_to_percpu+0x27/0x40
> > >[ 192.211647] set_in_sync+0xd4/0xe0
> > >[ 192.211647] md_check_recovery+0x1f5/0x4e0
> > >[ 192.211647] raid5d+0x56/0x6a0 [raid456]
> > >[ 192.211647] ? finish_wait+0x72/0x90
> > >[ 192.211647] ? trace_hardirqs_on_caller+0xf4/0x190
> > >[ 192.211647] ? trace_hardirqs_on+0xd/0x10
> > >[ 192.211647] md_thread+0x138/0x180
> > >[ 192.211647] ? md_thread+0x138/0x180
> > >[ 192.211647] ? finish_wait+0x90/0x90
> > >[ 192.211647] kthread+0x133/0x150
> > >[ 192.211647] ? find_pers+0x70/0x70
> > >[ 192.211647] ? kthread_create_on_node+0x70/0x70
> > >[ 192.211647] ret_from_fork+0x31/0x40
> > >[ 192.211647] Code: f0 4a c8 8b be d5 03 00 00 48 c7 c7 b1 75 c7
> > >8b c6 05 ef 75 b9 00 01 e8 97 d2 c4 ff e9 e8 fe ff ff f0 48 83 03
> > >...|01 e9 bf fe ff ff <0f> 0b e8 21 d9 be ff 90 55 48 89 e5 41 55
> > >41 54 53 48 89 fb 48
> > >[ 192.211647] RIP: __percpu_ref_switch_mode+0x278/0x280 RSP:
> > >ffffa9a3c0d13ce8
> > >[ 192.211647] ---[ end trace fbf926294c454ffb ]---
> > >
> > >[ 192.211647] BUG: sleeping function called from invalid context
> > >at ./include/linux/percpu-rwsem.h:33
> > >[ 192.211647] in_atomic(): 1, irqs_disabled(): 1, pid: 13767,
> > >name: mdX_raid5
> > >[ 192.211647] INFO: lockdep is turned off.
> > >[ 192.211647] irq event stamp: 68
> > >[ 192.211647] hardirqs last enabled at (67):
> > >[<ffffffff8b983586>] _raw_spin_unlock_irqrestore+0x36/0x60
> > >[ 192.211647] hardirqs last disabled at (68):
> > >[<ffffffff8b983c47>] _raw_spin_lock_irqsave+0x27/0x90
> > >[ 192.211647] softirqs last enabled at (0): [<ffffffff8b0ae308>]
> > >copy_process.part.26+0x618/0x1ee0
> > >[ 192.211647] softirqs last disabled at (0): [< (null)>]
> > >(null)
> > >[ 192.211647] CPU: 0 PID: 13767 Comm: mdX_raid5 Tainted: G D
> > >W 4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> > >[ 192.211647] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > >[ 192.211647] Call Trace:
> > >[ 192.211647] dump_stack+0x8e/0xcd
> > >[ 192.211647] ___might_sleep+0x144/0x260
> > >[ 192.211647] __might_sleep+0x4a/0x80
> > >[ 192.211647] exit_signals+0x33/0x240
> > >[ 192.211647] do_exit+0xb4/0xd30
> > >[ 192.211647] ? kthread+0x133/0x150
> > >[ 192.211647] ? find_pers+0x70/0x70
> > >[ 192.211647] rewind_stack_do_exit+0x17/0x20
> > >
> > >[ 192.211647] note: mdX_raid5[13767] exited with preempt_count 2
> > >
> > >[ 220.071005] NMI watchdog: BUG: soft lockup - CPU#1 stuck for
> > >22s! [lvm:13678]
> > >[ 220.071079] Modules linked in: dm_raid raid456
> > >async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> > >raid6_pq ...|dm_thin_pool dm_cache_smq dm_cache dm_persistent_data
> > >dm_bio_prison libcrc32c loop crct10dif_pclmul crc32_pclmul
> > >crc32c_intel ...|ppdev ghash_clmulni_intel acpi_cpufreq
> > >virtio_net virtio_balloon tpm_tis joydev tpm_tis_core parport_pc
> > >parport tpm i2c_piix4 ...|virtio_blk cirrus drm_kms_helper ttm
> > >drm serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
> > >[ 220.083131] irq event stamp: 313716
> > >[ 220.087117] hardirqs last enabled at (313715):
> > >[<ffffffff8b983da7>] entry_SYSCALL_64_fastpath+0x5/0xbe
> > >[ 220.091109] hardirqs last disabled at (313716):
> > >[<ffffffff8b97afe4>] __schedule+0xc4/0xb40
> > >[ 220.091109] softirqs last enabled at (301518):
> > >[<ffffffff8b988d52>] __do_softirq+0x382/0x4ed
> > >[ 220.095114] softirqs last disabled at (301511):
> > >[<ffffffff8b0b8e7f>] irq_exit+0x10f/0x120
> > >[ 220.099150] CPU: 1 PID: 13678 Comm: lvm Tainted: G D W
> > >4.12.0-0.rc1.git1.1.fc27.x86_64 #1
> > >[ 220.103049] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > >[ 220.103049] task: ffff8d5bb3c03100 task.stack: ffffa9a3c155c000
> > >[ 220.107103] RIP: 0010:queued_spin_lock_slowpath+0x25/0x1b0
> > >[ 220.107103] RSP: 0018:ffffa9a3c155f720 EFLAGS: 00000202
> > >ORIG_RAX: ffffffffffffff10
> > >[ 220.111144] RAX: 0000000000000001 RBX: ffff8d5bb5252448 RCX:
> > >0000000000000000
> > >[ 220.115126] RDX: 0000000000000001 RSI: 0000000000000001 RDI:
> > >ffff8d5bb5252448
> > >[ 220.115126] RBP: ffffa9a3c155f720 R08: 0000000000000000 R09:
> > >0000000000000000
> > >[ 220.119130] R10: ffffa9a3c155f6d0 R11: ffff8d5bb3c03100 R12:
> > >ffff8d5bb5252448
> > >[ 220.123139] R13: ffff8d5bb5252448 R14: ffff8d5bb379ca20 R15:
> > >ffff8d5bb5252058
> > >[ 220.127118] FS: 00007f1f8253b880(0000)
> > >GS:ffff8d5bb7a00000(0000) knlGS:0000000000000000
> > >[ 220.127118] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > >[ 220.131158] CR2: 00007fe2715ae000 CR3: 0000000075108000 CR4:
> > >00000000000006e0
> > >[ 220.135114] Call Trace:
> > >[ 220.135114] do_raw_spin_lock+0xb2/0xc0
> > >[ 220.139145] _raw_spin_lock+0x55/0x70
> > >[ 220.139145] md_write_start+0x143/0x360
> > >[ 220.143126] ? probe_sched_wakeup+0x1c/0x20
> > >[ 220.143126] ? check_preempt_curr+0x27/0xb0
> > >[ 220.147147] raid5_make_request+0xd0/0x1060 [raid456]
> > >[ 220.147147] ? _raw_spin_unlock_irqrestore+0x5b/0x60
> > >[ 220.151162] ? try_to_wake_up+0x58/0x520
> > >[ 220.151162] ? finish_wait+0x90/0x90
> > >[ 220.155099] ? mempool_alloc_slab+0x1d/0x30
> > >[ 220.155099] ? finish_wait+0x90/0x90
> > >[ 220.159136] raid_map+0x2b/0x40 [dm_raid]
> > >[ 220.159136] __map_bio+0xc9/0x2b0
> > >[ 220.163115] ? dm_put_table_device+0xd0/0xd0
> > >[ 220.163115] __split_and_process_bio+0x293/0x590
> > >[ 220.167133] dm_make_request+0x7f/0x120
> > >[ 220.167133] ? generic_make_request+0xf9/0x3b0
> > >[ 220.171131] generic_make_request+0x126/0x3b0
> > >[ 220.171131] ? iov_iter_get_pages+0xc9/0x300
> > >[ 220.175138] submit_bio+0x73/0x150
> > >[ 220.175138] ? submit_bio+0x73/0x150
> > >[ 220.179132] ? bio_iov_iter_get_pages+0xe0/0x120
> > >[ 220.179132] ? __blkdev_direct_IO_simple+0x168/0x320
> > >[ 220.183114] __blkdev_direct_IO_simple+0x184/0x320
> > >[ 220.183114] ? lock_acquire+0xa3/0x1f0
> > >[ 220.187129] ? bdput+0x20/0x20
> > >[ 220.187129] blkdev_direct_IO+0x3b1/0x3e0
> > >[ 220.191112] ? blkdev_direct_IO+0x3b1/0x3e0
> > >[ 220.191112] ? current_time+0x1a/0x70
> > >[ 220.195108] ? trace_hardirqs_on+0xd/0x10
> > >[ 220.195108] generic_file_direct_write+0x9c/0x110
> > >[ 220.199114] ? generic_file_direct_write+0x9c/0x110
> > >[ 220.199114] __generic_file_write_iter+0xbe/0x1d0
> > >[ 220.199114] blkdev_write_iter+0x96/0x110
> > >[ 220.203115] __vfs_write+0xe8/0x160
> > >[ 220.203115] ? __vfs_write+0xe8/0x160
> > >[ 220.207211] vfs_write+0xc6/0x1c0
> > >[ 220.207211] SyS_write+0x58/0xc0
> > >[ 220.207211] entry_SYSCALL_64_fastpath+0x1f/0xbe
> > >[ 220.211130] RIP: 0033:0x7f1f81309290
> > >[ 220.211130] RSP: 002b:00007fffba453af8 EFLAGS: 00000246
> > >ORIG_RAX: 0000000000000001
> > >[ 220.215116] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
> > >00007f1f81309290
> > >[ 220.215116] RDX: 0000000000001000 RSI: 000055f0c4ab4000 RDI:
> > >000000000000000c
> > >[ 220.219114] RBP: 00007f1f815d5583 R08: fffffffffffffff0 R09:
> > >0000000000000000
> > >[ 220.219114] R10: 00007f1f815d4b38 R11: 0000000000000246 R12:
> > >0000000000000001
> > >[ 220.223148] R13: 0000000000000001 R14: 00007f1f815d5500 R15:
> > >00007f1f815d08c0
> > >[ 220.223148] Code: 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5
> > >66 66 90 66 90 ba 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0
> > >...|75 f2 5d c3 f3 90 <eb> ec 81 fe 00 01 00 00 0f 84 1a 01 00 00
> > >41 b8 01 01 00 00 b9
> > >
> > >--
> > >dm-devel mailing list
> > >dm-devel@redhat.com
> > >https://www.redhat.com/mailman/listinfo/dm-devel
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: Shaohua Li @ 2017-06-08 17:15 UTC (permalink / raw)
To: NeilBrown; +Cc: Mikulas Patocka, linux-raid
In-Reply-To: <87h8zrart4.fsf@notabene.neil.brown.name>
On Thu, Jun 08, 2017 at 04:59:03PM +1000, Neil Brown wrote:
> On Wed, Jun 07 2017, Mikulas Patocka wrote:
>
> > The function flush_signals clears all pending signals for the process. It
> > may be used by kernel threads when we need to prepare a kernel thread for
> > responding to signals. However using this function for an userspaces
> > processes is incorrect - clearing signals without the program expecting it
> > can cause misbehavior.
> >
> > The raid1 and raid5 code uses flush_signals in its request routine because
> > it wants to prepare for an interruptible wait. This patch drops
> > flush_signals and uses sigprocmask instead to block all signals (including
> > SIGKILL) around the schedule() call. The signals are not lost, but the
> > schedule() call won't respond to them.
> >
> > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > Cc: stable@vger.kernel.org
>
> Thanks for catching that!
>
> Acked-by: NeilBrown <neilb@suse.com>
Applied, thanks!
Neil,
Not about the patch itself. I had question about that part of code. Dropped
others since this is raid related. I didn't get the point why it's a
TASK_INTERRUPTIBLE sleep. It seems suggesting the thread will bail out if a
signal is sent. But I didn't see we check the signal and exit the loop. What's
the correct behavior here? Since the suspend range is controlled by userspace,
I think the correct behavior is if user kills the thread, we exit the loop. So
it seems like to be we check if there is fatal signal pending, exit the loop,
and return IO error. Not sure if we should return IO error though.
Thanks,
Shaohua
^ permalink raw reply
* HW RAID with ASM 1062R
From: Jean-Michel Hautbois @ 2017-06-08 17:41 UTC (permalink / raw)
To: linux-raid
Hi !
I am quite new with HW RAID drivers, and I want to support a PCIe /
2xSATA board based on ASM1062R chip.
It is seen as AHCI so Linux can see the disks and that's something.
But now, I want to modify the configuration to use RAID-0 or RAID-1,
and there is nothing right now, according to my search ?
This chip understands vendor commands using a CMD/ACK message with MMIO offsets.
I now have several questions (maybe irrelevant :)) :
- Where should this driver be ? md ? scsi ?
- These vendor commands are under NDA right now, so I think it should
not be written in the driver obviously, but I am pretty sure there is
a nice way to do it ;-) ?
Basically, this is a 32 bits word with CMD and some args, and an ACK
with some args, which should be parsed.
Should it be in a specific proprietary user space application (yuck !) ?
Thanks for your help, this is a very early stage exploration, so feel
free to give any idea :D.
JM
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: Mikulas Patocka @ 2017-06-08 20:51 UTC (permalink / raw)
To: Shaohua Li
Cc: NeilBrown, linux-raid, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20170608171551.ytxk3yz6xxsfbqma@kernel.org>
On Thu, 8 Jun 2017, Shaohua Li wrote:
> On Thu, Jun 08, 2017 at 04:59:03PM +1000, Neil Brown wrote:
> > On Wed, Jun 07 2017, Mikulas Patocka wrote:
> >
> > > The function flush_signals clears all pending signals for the process. It
> > > may be used by kernel threads when we need to prepare a kernel thread for
> > > responding to signals. However using this function for an userspaces
> > > processes is incorrect - clearing signals without the program expecting it
> > > can cause misbehavior.
> > >
> > > The raid1 and raid5 code uses flush_signals in its request routine because
> > > it wants to prepare for an interruptible wait. This patch drops
> > > flush_signals and uses sigprocmask instead to block all signals (including
> > > SIGKILL) around the schedule() call. The signals are not lost, but the
> > > schedule() call won't respond to them.
> > >
> > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > > Cc: stable@vger.kernel.org
> >
> > Thanks for catching that!
> >
> > Acked-by: NeilBrown <neilb@suse.com>
>
> Applied, thanks!
>
> Neil,
> Not about the patch itself. I had question about that part of code. Dropped
> others since this is raid related. I didn't get the point why it's a
> TASK_INTERRUPTIBLE sleep. It seems suggesting the thread will bail out if a
> signal is sent. But I didn't see we check the signal and exit the loop. What's
> the correct behavior here? Since the suspend range is controlled by userspace,
As I understand the code - the purpose is to have an UNINTERRUPTIBLE sleep
that isn't accounted in load average and that doesn't trigger the hung
task warning.
There should really be something like TASK_UNINTERRUPTIBLE_LONG for this
purpose.
> I think the correct behavior is if user kills the thread, we exit the loop. So
> it seems like to be we check if there is fatal signal pending, exit the loop,
> and return IO error. Not sure if we should return IO error though.
No, this is not correct - if we report an I/O error for the affected bio,
it could corrupt filesystem or confuse other device mapper targets that
could be on the top of MD. It is not right to corrupt filesystem if the
user kills a process.
> Thanks,
> Shaohua
Mikulas
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: NeilBrown @ 2017-06-08 21:24 UTC (permalink / raw)
To: Mikulas Patocka, Shaohua Li
Cc: linux-raid, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LRH.2.02.1706081641160.12323@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]
On Thu, Jun 08 2017, Mikulas Patocka wrote:
> On Thu, 8 Jun 2017, Shaohua Li wrote:
>
>> On Thu, Jun 08, 2017 at 04:59:03PM +1000, Neil Brown wrote:
>> > On Wed, Jun 07 2017, Mikulas Patocka wrote:
>> >
>> > > The function flush_signals clears all pending signals for the process. It
>> > > may be used by kernel threads when we need to prepare a kernel thread for
>> > > responding to signals. However using this function for an userspaces
>> > > processes is incorrect - clearing signals without the program expecting it
>> > > can cause misbehavior.
>> > >
>> > > The raid1 and raid5 code uses flush_signals in its request routine because
>> > > it wants to prepare for an interruptible wait. This patch drops
>> > > flush_signals and uses sigprocmask instead to block all signals (including
>> > > SIGKILL) around the schedule() call. The signals are not lost, but the
>> > > schedule() call won't respond to them.
>> > >
>> > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>> > > Cc: stable@vger.kernel.org
>> >
>> > Thanks for catching that!
>> >
>> > Acked-by: NeilBrown <neilb@suse.com>
>>
>> Applied, thanks!
>>
>> Neil,
>> Not about the patch itself. I had question about that part of code. Dropped
>> others since this is raid related. I didn't get the point why it's a
>> TASK_INTERRUPTIBLE sleep. It seems suggesting the thread will bail out if a
>> signal is sent. But I didn't see we check the signal and exit the loop. What's
>> the correct behavior here? Since the suspend range is controlled by userspace,
>
> As I understand the code - the purpose is to have an UNINTERRUPTIBLE sleep
> that isn't accounted in load average and that doesn't trigger the hung
> task warning.
Exactly my reason - yes.
>
> There should really be something like TASK_UNINTERRUPTIBLE_LONG for this
> purpose.
That would be nice.
>
>> I think the correct behavior is if user kills the thread, we exit the loop. So
>> it seems like to be we check if there is fatal signal pending, exit the loop,
>> and return IO error. Not sure if we should return IO error though.
>
> No, this is not correct - if we report an I/O error for the affected bio,
> it could corrupt filesystem or confuse other device mapper targets that
> could be on the top of MD. It is not right to corrupt filesystem if the
> user kills a process.
Yes, we are too deep to even return something like ERESTARTSYS.
Blocking is the only option.
Thanks,
NeilBrown
>
>> Thanks,
>> Shaohua
>
> Mikulas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: Mikulas Patocka @ 2017-06-08 22:52 UTC (permalink / raw)
To: NeilBrown
Cc: Shaohua Li, linux-raid, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <87h8zrart4.fsf@notabene.neil.brown.name>
On Thu, 8 Jun 2017, NeilBrown wrote:
> On Wed, Jun 07 2017, Mikulas Patocka wrote:
>
> > The function flush_signals clears all pending signals for the process. It
> > may be used by kernel threads when we need to prepare a kernel thread for
> > responding to signals. However using this function for an userspaces
> > processes is incorrect - clearing signals without the program expecting it
> > can cause misbehavior.
> >
> > The raid1 and raid5 code uses flush_signals in its request routine because
> > it wants to prepare for an interruptible wait. This patch drops
> > flush_signals and uses sigprocmask instead to block all signals (including
> > SIGKILL) around the schedule() call. The signals are not lost, but the
> > schedule() call won't respond to them.
> >
> > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > Cc: stable@vger.kernel.org
>
> Thanks for catching that!
>
> Acked-by: NeilBrown <neilb@suse.com>
>
> NeilBrown
BTW. why does md_thread do "allow_signal(SIGKILL)" and then
"if (signal_pending(current)) flush_signals(current)"?
Does userspace really send SIGKILL to MD kernel threads? The SIGKILL will
be lost when flush_signals is called, so it looks quite dubious.
Mikulas
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: Shaohua Li @ 2017-06-08 22:58 UTC (permalink / raw)
To: NeilBrown
Cc: Mikulas Patocka, linux-raid, linux-kernel, Ingo Molnar,
Peter Zijlstra
In-Reply-To: <877f0mb2b6.fsf@notabene.neil.brown.name>
On Fri, Jun 09, 2017 at 07:24:29AM +1000, Neil Brown wrote:
> On Thu, Jun 08 2017, Mikulas Patocka wrote:
>
> > On Thu, 8 Jun 2017, Shaohua Li wrote:
> >
> >> On Thu, Jun 08, 2017 at 04:59:03PM +1000, Neil Brown wrote:
> >> > On Wed, Jun 07 2017, Mikulas Patocka wrote:
> >> >
> >> > > The function flush_signals clears all pending signals for the process. It
> >> > > may be used by kernel threads when we need to prepare a kernel thread for
> >> > > responding to signals. However using this function for an userspaces
> >> > > processes is incorrect - clearing signals without the program expecting it
> >> > > can cause misbehavior.
> >> > >
> >> > > The raid1 and raid5 code uses flush_signals in its request routine because
> >> > > it wants to prepare for an interruptible wait. This patch drops
> >> > > flush_signals and uses sigprocmask instead to block all signals (including
> >> > > SIGKILL) around the schedule() call. The signals are not lost, but the
> >> > > schedule() call won't respond to them.
> >> > >
> >> > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> >> > > Cc: stable@vger.kernel.org
> >> >
> >> > Thanks for catching that!
> >> >
> >> > Acked-by: NeilBrown <neilb@suse.com>
> >>
> >> Applied, thanks!
> >>
> >> Neil,
> >> Not about the patch itself. I had question about that part of code. Dropped
> >> others since this is raid related. I didn't get the point why it's a
> >> TASK_INTERRUPTIBLE sleep. It seems suggesting the thread will bail out if a
> >> signal is sent. But I didn't see we check the signal and exit the loop. What's
> >> the correct behavior here? Since the suspend range is controlled by userspace,
> >
> > As I understand the code - the purpose is to have an UNINTERRUPTIBLE sleep
> > that isn't accounted in load average and that doesn't trigger the hung
> > task warning.
>
> Exactly my reason - yes.
>
> >
> > There should really be something like TASK_UNINTERRUPTIBLE_LONG for this
> > purpose.
>
> That would be nice.
>
> >
> >> I think the correct behavior is if user kills the thread, we exit the loop. So
> >> it seems like to be we check if there is fatal signal pending, exit the loop,
> >> and return IO error. Not sure if we should return IO error though.
> >
> > No, this is not correct - if we report an I/O error for the affected bio,
> > it could corrupt filesystem or confuse other device mapper targets that
> > could be on the top of MD. It is not right to corrupt filesystem if the
> > user kills a process.
>
> Yes, we are too deep to even return something like ERESTARTSYS.
> Blocking is the only option.
My concern is if the app controlling the suspend range dies, other threads
will block in the kernel side forever. We can't even force kill them. This
is an unfortunate behavior. Would adding a timeout here make sense? The app
controlling the suspend range looks part of the disk firmware now. If the
firmware doesn't respond, returning IO timeout is normal.
Thanks,
Shaohua
^ permalink raw reply
* My md won't assemble even when disks are in clean state.
From: Ram Ramesh @ 2017-06-09 1:44 UTC (permalink / raw)
To: Linux Raid
Hi,
Today my host had a power outage due to user mistake in the middle of
a disk replacement. The replacement was simply to replace an old/smaller
disk with new/larger one. No drive had failed prior to replacement. My
/dev/md0 is a RAID6 with 6 disks prior to replacement (sd{b,c,e,f,g,h}1)
I started replacement with this following commands
1. mdadm /dev/md0 --add /dev/sdi1
2. echo want-replacement > /sys/block/md0/md/dev-sdg1/state
It was going to take about 6hr for the rebuild to complete. Then the
power outage happened about 1hr in to the replacement.
On reboot the array has all 7 (old 6+new 1) as spares and failed to
assemble. The disk names have also changed which did not surprise me.
mdadm --assemble -force did not work. It reported that all spares are
busy. I suspect that it has 7 disk for 6 array raid6 and does not know
which 6 to pick to bring up the array. Looking at the disk vendor and
serial numbers, I think the replacement is /dev/sdf1 and the one getting
replaced is /dev/sdi1 in the following details (Note that pre crash this
was called /dev/sdg1)
zym [root] 27 > mdadm --version
mdadm - v3.2.5 - 18th May 2012
zym [root] 28 > uname -a
Linux zym 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 15:44:32 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
zym [root] 29 > cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
zym [root] 31 > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
[raid4] [raid10]
md0 : inactive sdi1[7](S) sdg1[11](S) sdh1[6](S) sdf1[12](S)
sde1[10](S) sdd1[8](S) sdc1[9](S)
39069229300 blocks super 1.2
unused devices: <none>
foreach i ( /dev/sd{c,d,e,f,h,i}1 )
sudo mdadm --examine $i >> /tmp/examine
end
zym [root] 32 > cat /tmp/examine
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 05bb9634:4ecf803a:c519c886:cf3f4867
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : cdf085c0 - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 5
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 7e16d55d:3f00c22b:44a750ab:b50a4b5d
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : 2fb6a8f - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 7e035b56:d1e1882b:e78a08ad:3ba50667
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : 6bbb74c - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 2
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 94251d51:a616e735:e7baccdb:3610013b
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : e9aab94 - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : ad285b4d:222eea5e:0baad052:02eeb7d2
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : 429690b8 - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 3
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x13
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Recovery Offset : 1192713176 sectors
State : clean
Device UUID : 0ddd2a83:872da375:c7cb7a93:c5bd2ea1
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : e55791e1 - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 4
Array State : AAAA?A ('A' == active, '.' == missing)
/dev/sdi1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
Name : zym:0 (local to host zym)
Creation Time : Mon Apr 22 00:08:12 2013
Raid Level : raid6
Raid Devices : 6
Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 6c35eb93:149c874e:48f7572b:fc6161cc
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Jun 8 19:11:59 2017
Checksum : 6214969b - correct
Events : 290068
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 4
Array State : AAAA?A ('A' == active, '.' == missing)
zym [root] 33 >
***smartctl output omitted as all disks are healthy with no errors***
Thanks in advance for your help.
Ramesh
^ permalink raw reply
* Re: My md won't assemble even when disks are in clean state.
From: Adam Goryachev @ 2017-06-09 1:48 UTC (permalink / raw)
To: Ram Ramesh, Linux Raid
In-Reply-To: <f8d51bbd-6df7-2ea0-ba6f-8831a2b3e390@gmail.com>
On 09/06/17 11:44, Ram Ramesh wrote:
> Hi,
>
> Today my host had a power outage due to user mistake in the middle
> of a disk replacement. The replacement was simply to replace an
> old/smaller disk with new/larger one. No drive had failed prior to
> replacement. My /dev/md0 is a RAID6 with 6 disks prior to replacement
> (sd{b,c,e,f,g,h}1) I started replacement with this following commands
>
> 1. mdadm /dev/md0 --add /dev/sdi1
> 2. echo want-replacement > /sys/block/md0/md/dev-sdg1/state
>
> It was going to take about 6hr for the rebuild to complete. Then the
> power outage happened about 1hr in to the replacement.
> On reboot the array has all 7 (old 6+new 1) as spares and failed to
> assemble. The disk names have also changed which did not surprise me.
> mdadm --assemble -force did not work. It reported that all spares are
> busy. I suspect that it has 7 disk for 6 array raid6 and does not know
> which 6 to pick to bring up the array. Looking at the disk vendor and
> serial numbers, I think the replacement is /dev/sdf1 and the one
> getting replaced is /dev/sdi1 in the following details (Note that pre
> crash this was called /dev/sdg1)
>
> zym [root] 27 > mdadm --version
> mdadm - v3.2.5 - 18th May 2012
>
> zym [root] 28 > uname -a
> Linux zym 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 15:44:32 UTC
> 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> zym [root] 29 > cat /etc/os-release
> NAME="Ubuntu"
> VERSION="14.04.5 LTS, Trusty Tahr"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 14.04.5 LTS"
> VERSION_ID="14.04"
> HOME_URL="http://www.ubuntu.com/"
> SUPPORT_URL="http://help.ubuntu.com/"
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
>
> zym [root] 31 > cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
> [raid4] [raid10]
> md0 : inactive sdi1[7](S) sdg1[11](S) sdh1[6](S) sdf1[12](S)
> sde1[10](S) sdd1[8](S) sdc1[9](S)
> 39069229300 blocks super 1.2
>
> unused devices: <none>
>
> foreach i ( /dev/sd{c,d,e,f,h,i}1 )
> sudo mdadm --examine $i >> /tmp/examine
> end
>
> zym [root] 32 > cat /tmp/examine
> /dev/sdc1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 05bb9634:4ecf803a:c519c886:cf3f4867
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : cdf085c0 - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 5
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sdd1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 7e16d55d:3f00c22b:44a750ab:b50a4b5d
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : 2fb6a8f - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 0
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sde1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 7e035b56:d1e1882b:e78a08ad:3ba50667
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : 6bbb74c - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 2
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sdf1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 94251d51:a616e735:e7baccdb:3610013b
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : e9aab94 - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 1
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sdg1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : ad285b4d:222eea5e:0baad052:02eeb7d2
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : 429690b8 - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 3
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sdh1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x13
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> Recovery Offset : 1192713176 sectors
> State : clean
> Device UUID : 0ddd2a83:872da375:c7cb7a93:c5bd2ea1
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : e55791e1 - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 4
> Array State : AAAA?A ('A' == active, '.' == missing)
>
> /dev/sdi1:
> Magic : a92b4efc
> Version : 1.2
> Feature Map : 0x1
> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
> Name : zym:0 (local to host zym)
> Creation Time : Mon Apr 22 00:08:12 2013
> Raid Level : raid6
> Raid Devices : 6
>
> Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
> Data Offset : 262144 sectors
> Super Offset : 8 sectors
> State : clean
> Device UUID : 6c35eb93:149c874e:48f7572b:fc6161cc
>
> Internal Bitmap : 8 sectors from superblock
> Update Time : Thu Jun 8 19:11:59 2017
> Checksum : 6214969b - correct
> Events : 290068
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Device Role : Active device 4
> Array State : AAAA?A ('A' == active, '.' == missing)
> zym [root] 33 >
>
> ***smartctl output omitted as all disks are healthy with no errors***
>
> Thanks in advance for your help.
You might need to do a "mdadm --stop /dev/md0" before trying to do a
start again (ie, they are busy because they are already used by MD, stop
md0 so that they are all unused, then try to assemble again.
Just remember, don't re-create the array without a full backup, or
specific advice from someone (else) on the list.
Hope that helps :)
Regards,
Adam
--
Adam Goryachev Website Managers www.websitemanagers.com.au
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: NeilBrown @ 2017-06-09 1:49 UTC (permalink / raw)
To: Shaohua Li
Cc: Mikulas Patocka, linux-raid, linux-kernel, Ingo Molnar,
Peter Zijlstra
In-Reply-To: <20170608225858.z23vabbkzsf3lgl5@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]
On Thu, Jun 08 2017, Shaohua Li wrote:
> On Fri, Jun 09, 2017 at 07:24:29AM +1000, Neil Brown wrote:
>> On Thu, Jun 08 2017, Mikulas Patocka wrote:
>>
>> > On Thu, 8 Jun 2017, Shaohua Li wrote:
>> >
>> >> On Thu, Jun 08, 2017 at 04:59:03PM +1000, Neil Brown wrote:
>> >> > On Wed, Jun 07 2017, Mikulas Patocka wrote:
>> >> >
>> >> > > The function flush_signals clears all pending signals for the process. It
>> >> > > may be used by kernel threads when we need to prepare a kernel thread for
>> >> > > responding to signals. However using this function for an userspaces
>> >> > > processes is incorrect - clearing signals without the program expecting it
>> >> > > can cause misbehavior.
>> >> > >
>> >> > > The raid1 and raid5 code uses flush_signals in its request routine because
>> >> > > it wants to prepare for an interruptible wait. This patch drops
>> >> > > flush_signals and uses sigprocmask instead to block all signals (including
>> >> > > SIGKILL) around the schedule() call. The signals are not lost, but the
>> >> > > schedule() call won't respond to them.
>> >> > >
>> >> > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>> >> > > Cc: stable@vger.kernel.org
>> >> >
>> >> > Thanks for catching that!
>> >> >
>> >> > Acked-by: NeilBrown <neilb@suse.com>
>> >>
>> >> Applied, thanks!
>> >>
>> >> Neil,
>> >> Not about the patch itself. I had question about that part of code. Dropped
>> >> others since this is raid related. I didn't get the point why it's a
>> >> TASK_INTERRUPTIBLE sleep. It seems suggesting the thread will bail out if a
>> >> signal is sent. But I didn't see we check the signal and exit the loop. What's
>> >> the correct behavior here? Since the suspend range is controlled by userspace,
>> >
>> > As I understand the code - the purpose is to have an UNINTERRUPTIBLE sleep
>> > that isn't accounted in load average and that doesn't trigger the hung
>> > task warning.
>>
>> Exactly my reason - yes.
>>
>> >
>> > There should really be something like TASK_UNINTERRUPTIBLE_LONG for this
>> > purpose.
>>
>> That would be nice.
>>
>> >
>> >> I think the correct behavior is if user kills the thread, we exit the loop. So
>> >> it seems like to be we check if there is fatal signal pending, exit the loop,
>> >> and return IO error. Not sure if we should return IO error though.
>> >
>> > No, this is not correct - if we report an I/O error for the affected bio,
>> > it could corrupt filesystem or confuse other device mapper targets that
>> > could be on the top of MD. It is not right to corrupt filesystem if the
>> > user kills a process.
>>
>> Yes, we are too deep to even return something like ERESTARTSYS.
>> Blocking is the only option.
>
> My concern is if the app controlling the suspend range dies, other threads
> will block in the kernel side forever. We can't even force kill them. This
> is an unfortunate behavior. Would adding a timeout here make sense? The app
> controlling the suspend range looks part of the disk firmware now. If the
> firmware doesn't respond, returning IO timeout is normal.
Yes, this happens.
You can write to /sys/block/mdXX/md/suspend_lo to unblock it, but most
people don't know this.
A timeout might be appropriate, but I would want it to be quite a long
one. Several minutes at least...
Though if I found I wanted to do some careful raid6repair surgery on an
array, and so suspending the problematic region and started work, I
might get annoyed if I/O started getting errors, instead of just waiting
like I asked.... but maybe that is a rather far-fetched scenario.
Thanks,
NeilBrown
>
> Thanks,
> Shaohua
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: NeilBrown @ 2017-06-09 1:55 UTC (permalink / raw)
To: Mikulas Patocka
Cc: Shaohua Li, linux-raid, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LRH.2.02.1706081847150.3603@file01.intranet.prod.int.rdu2.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]
On Thu, Jun 08 2017, Mikulas Patocka wrote:
> On Thu, 8 Jun 2017, NeilBrown wrote:
>
>> On Wed, Jun 07 2017, Mikulas Patocka wrote:
>>
>> > The function flush_signals clears all pending signals for the process. It
>> > may be used by kernel threads when we need to prepare a kernel thread for
>> > responding to signals. However using this function for an userspaces
>> > processes is incorrect - clearing signals without the program expecting it
>> > can cause misbehavior.
>> >
>> > The raid1 and raid5 code uses flush_signals in its request routine because
>> > it wants to prepare for an interruptible wait. This patch drops
>> > flush_signals and uses sigprocmask instead to block all signals (including
>> > SIGKILL) around the schedule() call. The signals are not lost, but the
>> > schedule() call won't respond to them.
>> >
>> > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
>> > Cc: stable@vger.kernel.org
>>
>> Thanks for catching that!
>>
>> Acked-by: NeilBrown <neilb@suse.com>
>>
>> NeilBrown
>
> BTW. why does md_thread do "allow_signal(SIGKILL)" and then
> "if (signal_pending(current)) flush_signals(current)"?
>
> Does userspace really send SIGKILL to MD kernel threads? The SIGKILL will
> be lost when flush_signals is called, so it looks quite dubious.
>
This is for md_check_recovery() which does do something on a signal.
Chances are good that it will get to handle the signal before
md_thread() flushed them, but not guaranteed. I could be improved I
guess.
Or maybe it could be discarded - the md_check_recovery() thing.
The idea was that if you alt-sysrq-K to kill all processes, md arrays
would go into immediate-safe-mode where the metadata is marked clean
immediately after writes finish, rather than waiting a few seconds. The
chance of having a clean array after shutdown is hopefully improved.
I've never actually used this though, and I doubt many people know about
it. And bitmaps make it fairly pointless.
So I wouldn't object much if
allow_signal(SIGKILL);
and
if (signal_pending(current)) {
if (mddev->pers->sync_request && !mddev->external) {
pr_debug("md: %s in immediate safe mode\n",
mdname(mddev));
mddev->safemode = 2;
}
flush_signals(current);
}
were removed.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] md: don't use flush_signals in userspace processes
From: Henrique de Moraes Holschuh @ 2017-06-09 3:27 UTC (permalink / raw)
To: NeilBrown
Cc: Mikulas Patocka, Shaohua Li, linux-raid, linux-kernel,
Ingo Molnar, Peter Zijlstra
In-Reply-To: <87shja9b7s.fsf@notabene.neil.brown.name>
On Fri, 09 Jun 2017, NeilBrown wrote:
> Or maybe it could be discarded - the md_check_recovery() thing.
> The idea was that if you alt-sysrq-K to kill all processes, md arrays
> would go into immediate-safe-mode where the metadata is marked clean
> immediately after writes finish, rather than waiting a few seconds. The
> chance of having a clean array after shutdown is hopefully improved.
>
> I've never actually used this though, and I doubt many people know about
> it. And bitmaps make it fairly pointless.
Hmm, I have, although I had no idea this was why my arrays were getting
far less frazzled than expected... It is really useful behavior, now
that I know it can do that.
If you can teach SysRq+S, and especially SysRq+U, to force all arrays
into safe-mode *after* they carried their current meanings
(sync/umount), that would be more useful though, and it would help a lot
of people to avoid dirty arrays without them even knowing why...
--
Henrique Holschuh
^ permalink raw reply
* (unknown),
From: citydesk @ 2017-06-09 4:30 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: 846894449555915.zip --]
[-- Type: application/zip, Size: 3190 bytes --]
^ permalink raw reply
* Re: My md won't assemble even when disks are in clean state.
From: Ram Ramesh @ 2017-06-09 5:44 UTC (permalink / raw)
To: Adam Goryachev, Linux Raid
In-Reply-To: <da15e516-9d92-9b37-0df4-9a53e56e10ba@websitemanagers.com.au>
On 06/08/2017 08:48 PM, Adam Goryachev wrote:
> On 09/06/17 11:44, Ram Ramesh wrote:
>> Hi,
>>
>> Today my host had a power outage due to user mistake in the middle
>> of a disk replacement. The replacement was simply to replace an
>> old/smaller disk with new/larger one. No drive had failed prior to
>> replacement. My /dev/md0 is a RAID6 with 6 disks prior to
>> replacement (sd{b,c,e,f,g,h}1) I started replacement with this
>> following commands
>>
>> 1. mdadm /dev/md0 --add /dev/sdi1
>> 2. echo want-replacement > /sys/block/md0/md/dev-sdg1/state
>>
>> It was going to take about 6hr for the rebuild to complete. Then the
>> power outage happened about 1hr in to the replacement.
>> On reboot the array has all 7 (old 6+new 1) as spares and failed to
>> assemble. The disk names have also changed which did not surprise me.
>> mdadm --assemble -force did not work. It reported that all spares are
>> busy. I suspect that it has 7 disk for 6 array raid6 and does not
>> know which 6 to pick to bring up the array. Looking at the disk
>> vendor and serial numbers, I think the replacement is /dev/sdf1 and
>> the one getting replaced is /dev/sdi1 in the following details (Note
>> that pre crash this was called /dev/sdg1)
>>
>> zym [root] 27 > mdadm --version
>> mdadm - v3.2.5 - 18th May 2012
>>
>> zym [root] 28 > uname -a
>> Linux zym 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 15:44:32 UTC
>> 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> zym [root] 29 > cat /etc/os-release
>> NAME="Ubuntu"
>> VERSION="14.04.5 LTS, Trusty Tahr"
>> ID=ubuntu
>> ID_LIKE=debian
>> PRETTY_NAME="Ubuntu 14.04.5 LTS"
>> VERSION_ID="14.04"
>> HOME_URL="http://www.ubuntu.com/"
>> SUPPORT_URL="http://help.ubuntu.com/"
>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
>>
>> zym [root] 31 > cat /proc/mdstat
>> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
>> [raid4] [raid10]
>> md0 : inactive sdi1[7](S) sdg1[11](S) sdh1[6](S) sdf1[12](S)
>> sde1[10](S) sdd1[8](S) sdc1[9](S)
>> 39069229300 blocks super 1.2
>>
>> unused devices: <none>
>>
>> foreach i ( /dev/sd{c,d,e,f,h,i}1 )
>> sudo mdadm --examine $i >> /tmp/examine
>> end
>>
>> zym [root] 32 > cat /tmp/examine
>> /dev/sdc1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : 05bb9634:4ecf803a:c519c886:cf3f4867
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : cdf085c0 - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 5
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sdd1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : 7e16d55d:3f00c22b:44a750ab:b50a4b5d
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : 2fb6a8f - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 0
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sde1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : 7e035b56:d1e1882b:e78a08ad:3ba50667
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : 6bbb74c - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 2
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sdf1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : 94251d51:a616e735:e7baccdb:3610013b
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : e9aab94 - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 1
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sdg1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : ad285b4d:222eea5e:0baad052:02eeb7d2
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : 429690b8 - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 3
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sdh1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x13
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 11720780943 (5588.90 GiB 6001.04 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> Recovery Offset : 1192713176 sectors
>> State : clean
>> Device UUID : 0ddd2a83:872da375:c7cb7a93:c5bd2ea1
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : e55791e1 - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 4
>> Array State : AAAA?A ('A' == active, '.' == missing)
>>
>> /dev/sdi1:
>> Magic : a92b4efc
>> Version : 1.2
>> Feature Map : 0x1
>> Array UUID : 0e9f76b5:4a89171a:a930bccd:78749144
>> Name : zym:0 (local to host zym)
>> Creation Time : Mon Apr 22 00:08:12 2013
>> Raid Level : raid6
>> Raid Devices : 6
>>
>> Avail Dev Size : 7813772943 (3725.90 GiB 4000.65 GB)
>> Array Size : 15627545856 (14903.59 GiB 16002.61 GB)
>> Used Dev Size : 7813772928 (3725.90 GiB 4000.65 GB)
>> Data Offset : 262144 sectors
>> Super Offset : 8 sectors
>> State : clean
>> Device UUID : 6c35eb93:149c874e:48f7572b:fc6161cc
>>
>> Internal Bitmap : 8 sectors from superblock
>> Update Time : Thu Jun 8 19:11:59 2017
>> Checksum : 6214969b - correct
>> Events : 290068
>>
>> Layout : left-symmetric
>> Chunk Size : 64K
>>
>> Device Role : Active device 4
>> Array State : AAAA?A ('A' == active, '.' == missing)
>> zym [root] 33 >
>>
>> ***smartctl output omitted as all disks are healthy with no errors***
>>
>> Thanks in advance for your help.
>
> You might need to do a "mdadm --stop /dev/md0" before trying to do a
> start again (ie, they are busy because they are already used by MD,
> stop md0 so that they are all unused, then try to assemble again.
>
> Just remember, don't re-create the array without a full backup, or
> specific advice from someone (else) on the list.
>
> Hope that helps :)
>
> Regards,
> Adam
>
Thanks. That did it. I was able to assemble. It assembled degraded and I
--re-added the remaining drives and it accepted without any issue. There
was no rebuild after --re-add which is consistent with the examine
output above that all disks are clean. Did fsck a couple of times for a
good measure and things seem normal now.
Ramesh
^ permalink raw reply
* 7340 linux-raid
From: mdavis @ 2017-06-09 10:45 UTC (permalink / raw)
To: linux-raid
[-- Attachment #1: 2890322.zip --]
[-- Type: application/zip, Size: 2002 bytes --]
^ permalink raw reply
* Re: [dm-devel] kernel BUG at lib/percpu-refcount.c:192
From: Marian Csontos @ 2017-06-09 12:40 UTC (permalink / raw)
To: Shaohua Li, Mike Snitzer
Cc: linux-raid, Heinz Mauelshagen, device-mapper development
In-Reply-To: <20170608170719.6kkk4g2gwzrko7wr@kernel.org>
On 06/08/2017 07:07 PM, Shaohua Li wrote:
>
> Neil fixed a bug in this side recently, which is pretty similar like the
> reported, I'll push the patch to upstream soon. Could you please try my
> for-next tree, and check if you still have the issue?
>
> Thanks,
> Shaohua
Kernel with the patch applied runs so far fine. All raid tests passed,
and the whole test suite is being run now.
Thanks!
-- Martian
^ permalink raw reply
* [PATCH] Grow: don't allow to enable PPL when reshape is in progress
From: Tomasz Majchrzak @ 2017-06-09 14:20 UTC (permalink / raw)
To: linux-raid; +Cc: jes.sorensen, Tomasz Majchrzak
Don't allow to enable PPL consistency policy when reshape is in progress.
Current PPL implementation doesn't work when reshape is taking place.
Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
---
Grow.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Grow.c b/Grow.c
index 4ecb1d8..1a93391 100644
--- a/Grow.c
+++ b/Grow.c
@@ -530,6 +530,7 @@ int Grow_consistency_policy(char *devname, int fd, struct context *c, struct sha
char *subarray = NULL;
int ret = 0;
char container_dev[PATH_MAX];
+ char buf[20];
if (s->consistency_policy != CONSISTENCY_POLICY_RESYNC &&
s->consistency_policy != CONSISTENCY_POLICY_PPL) {
@@ -577,6 +578,17 @@ int Grow_consistency_policy(char *devname, int fd, struct context *c, struct sha
goto free_info;
}
+ if (s->consistency_policy == CONSISTENCY_POLICY_PPL) {
+ if (sysfs_get_str(sra, NULL, "sync_action", buf, 20) <= 0) {
+ ret = 1;
+ goto free_info;
+ } else if (strcmp(buf, "reshape\n") == 0) {
+ pr_err("PPL cannot be enabled when reshape is in progress\n");
+ ret = 1;
+ goto free_info;
+ }
+ }
+
if (subarray) {
char *update;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Grow: don't allow array geometry change with ppl enabled
From: Jes Sorensen @ 2017-06-09 14:56 UTC (permalink / raw)
To: Tomasz Majchrzak, linux-raid
In-Reply-To: <1496930751-9220-1-git-send-email-tomasz.majchrzak@intel.com>
On 06/08/2017 10:05 AM, Tomasz Majchrzak wrote:
> Don't allow array geometry change (size expand, disk adding) when PPL
> consistency policy is enabled. Current PPL implementation doesn't work when
> reshape is taking place.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Grow.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH] Grow: don't allow to enable PPL when reshape is in progress
From: Jes Sorensen @ 2017-06-09 14:58 UTC (permalink / raw)
To: Tomasz Majchrzak, linux-raid
In-Reply-To: <1497018019-11809-1-git-send-email-tomasz.majchrzak@intel.com>
On 06/09/2017 10:20 AM, Tomasz Majchrzak wrote:
> Don't allow to enable PPL consistency policy when reshape is in progress.
> Current PPL implementation doesn't work when reshape is taking place.
>
> Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> ---
> Grow.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Applied!
Thanks,
Jes
^ permalink raw reply
* Re: [PATCH 2/3 v1] mdadm/test: Refactor the codes of 'test' script
From: Jes Sorensen @ 2017-06-09 15:05 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1496913628-22779-1-git-send-email-zlliu@suse.com>
On 06/08/2017 05:20 AM, Zhilong Liu wrote:
> Adding functions:
> die()
> uniform the abnormal situations that have to abort.
> check_env()
> do various basic checking before running test suite.
> save_log()
> collect array infos, include of dmesg, superblock,
> bitmap and /proc/mdstat.
> main()
> the core function of this script.
>
> Improve functions:
> cleanup()
> clear dmesg and remove the /vat/tmp/mdtest* files.
> mdadm()
> clear superblock once creating or building arrays
> every time, because it's always creating arrays
> many times in a test case.
> check()
> just tidy up with die(), didn't change code meanings.
> testdev()
> add checking $1 must be a block device, add 'return 0'
> in final because this function exists in last line of
> test case, such as tests/05r6tor0.
> do_test()
> add checking abnormal dmesg and changing log management.
> do_help()
> just recommend a better way to print Usage.
> parse_args()
> just tidy up.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
> ---
> test | 346 +++++++++++++++++++++++++++++++++++++------------------------------
> 1 file changed, 191 insertions(+), 155 deletions(-)
Zhilong,
When sending out a v2 please add a small comment below the ---
explaining what you changed.
Cheers,
Jes
PS: I note you start with v1 for updates, but v1 is really the first
version - not a big deal.
^ permalink raw reply
* Re: [PATCH 1/3] mdadm/test: Convert code format to use Tab
From: Jes Sorensen @ 2017-06-09 15:06 UTC (permalink / raw)
To: Zhilong Liu; +Cc: linux-raid
In-Reply-To: <1496827888-17118-2-git-send-email-zlliu@suse.com>
On 06/07/2017 05:31 AM, Zhilong Liu wrote:
> In case to make codes neat, this commit didn't change
> any codes, just tidy up and use Tab as code format.
>
> Signed-off-by: Zhilong Liu <zlliu@suse.com>
Tabs are good :)
Applied!
Jes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox