* [GIT PULL] MD for 4.6
From: Shaohua Li @ 2016-03-21 5:10 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, linux-raid, neilb
Hi Linus,
Could you please pull the MD update for 4.6? This update mainly fixes bugs.
- A raid5 discard related fix from Jes
- A MD multipath bio clone fix from Ming
- raid1 error handling deadlock fix from Nate and corresponding raid10 fix from
myself
- A raid5 stripe batch fix from Neil
- A patch from Sebastian to avoid unnecessary uevent
- Several cleanup/debug patches
Thanks,
Shaohua
The following changes since commit 6dc390ad61ac8dfca5fa9b0823981fb6f7ec17a0:
Merge tag 'arc-4.5-rc6-fixes-upd' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc (2016-02-24 14:06:17 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shli/md.git tags/md/4.6-rc1
for you to fetch changes up to 1d034e68e2c256640eb1f44bd7dcd89f90806ccf:
md/raid5: Cleanup cpu hotplug notifier (2016-03-17 14:30:15 -0700)
----------------------------------------------------------------
Anna-Maria Gleixner (1):
md/raid5: Cleanup cpu hotplug notifier
Eric Engestrom (1):
md/bitmap: remove redundant check
Guoqing Jiang (3):
md/raid1: remove unnecessary BUG_ON
md/bitmap: remove redundant return in bitmap_checkpage
md: fix typos for stipe
Jes Sorensen (1):
md/raid5: Compare apples to apples (or sectors to sectors)
Ming Lei (1):
md: multipath: don't hardcopy bio in .make_request path
Nate Dailey (1):
raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
NeilBrown (1):
md/raid5: preserve STRIPE_PREREAD_ACTIVE in break_stripe_batch_list
Sebastian Parschauer (1):
md: Drop sending a change uevent when stopping
Shaohua Li (6):
RAID5: check_reshape() shouldn't call mddev_suspend
RAID5: revert e9e4c377e2f563 to fix a livelock
MD: warn for potential deadlock
Update MD git tree URL
md/raid5: output stripe state for debug
raid10: include bio_end_io_list in nr_queued to prevent freeze_array hang
MAINTAINERS | 2 +-
drivers/md/bitmap.c | 4 +---
drivers/md/bitmap.h | 4 ++--
drivers/md/md.c | 2 +-
drivers/md/multipath.c | 4 +++-
drivers/md/raid1.c | 8 ++++---
drivers/md/raid10.c | 7 ++++--
drivers/md/raid5.c | 63 +++++++++++++++++++++++++++++---------------------
drivers/md/raid5.h | 4 +++-
9 files changed, 58 insertions(+), 40 deletions(-)
^ permalink raw reply
* Re: problems with dm-raid 6
From: Andreas Klauer @ 2016-03-20 22:37 UTC (permalink / raw)
To: Patrick Tschackert; +Cc: linux-raid
In-Reply-To: <trinity-dd5fc296-8c28-4b99-85de-889a495e6956-1458510296940@3capp-gmx-bs09>
On Sun, Mar 20, 2016 at 10:44:57PM +0100, Patrick Tschackert wrote:
> After rebooting the system, one of the harddisks was missing from my md raid 6 (the drive was /dev/sdf), so i rebuilt it with a hotspare that was already present in the system.
> I physically removed the "missing" /dev/sdf drive after the restore and replaced it with a new drive.
Exact commands involved for those steps?
mdadm --examine output for your disks?
> $ cat /sys/block/md0/md/mismatch_cnt
> 311936608
Basically the whole array out of whack.
This is what you get when you use --create --assume-clean on disks
that are not actually clean... or if you somehow convince md to
integrate a disk that does not have valid data on, for example
because you copied partition table and md metadata - but not
everything else - using dd.
Something really bad happened here and the only person who
can explain it, is probably yourself.
Your best bet is that the data is valid on n-2 disks.
Use overlay https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file
Assemble the overlay RAID with any 2 disks missing (try all combinations) and see if you get valid data.
Regards
Andreas Klauer
^ permalink raw reply
* problems with dm-raid 6
From: Patrick Tschackert @ 2016-03-20 21:44 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <trinity-235b76ed-571d-4615-b6f7-b4d5ed6a116d-1458509365312@3capp-gmx-bs09>
Hi, I've been referred here after this exchange: https://mail-archive.com/linux-btrfs@vger.kernel.org/msg51726.html
Especially the last email: https://mail-archive.com/linux-btrfs@vger.kernel.org/msg51763.html
Here's a rundown of my problem:
After rebooting the system, one of the harddisks was missing from my md raid 6 (the drive was /dev/sdf), so i rebuilt it with a hotspare that was already present in the system.
I physically removed the "missing" /dev/sdf drive after the restore and replaced it with a new drive.
This was all done using the following kernel:
$ uname -a
Linux vmhost 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4
(2016-02-29) x86_64 GNU/Linux
After I got advice from the linux-btrfs mailing list, i upgraded to a newer kernel from the debian backports and increased the command timeout on the drives:
$ uname -a
Linux vmhost 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.5-1~bpo8+1 (2016-02-23) x86_64 GNU/Linux
$ cat /sys/block/md0/md/mismatch_cnt
0
$ for i in /sys/class/scsi_generic/*/device/timeout; do echo 120 > "$i"; done
(I know this isn't persistent across reboots...)
$ echo check > /sys/block/md0/md/sync_action
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sda[0] sdf[12](S) sdg[11](S) sdj[9] sdh[7] sdi[6] sdk[10] sde[4] sdd[3] sdc[2] sdb[1]
20510948416 blocks super 1.2 level 6, 64k chunk, algorithm 2 [9/9] [UUUUUUUUU]
[>....................] check = 1.0% (30812476/2930135488) finish=340.6min speed=141864K/sec
unused devices: <none>
After the raid was done checking, I got this:
$ cat /sys/block/md0/md/mismatch_cnt
311936608
And messages in dmesg (attached to this mail) lead me to believe that the /dev/sdh drive is also faulty:
[12235.372901] sd 7:0:0:0: [sdh] tag#15 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[12235.372906] sd 7:0:0:0: [sdh] tag#15 Sense Key : Medium Error [current] [descriptor]
[12235.372909] sd 7:0:0:0: [sdh] tag#15 Add. Sense: Unrecovered read error - auto reallocate failed
[12235.372913] sd 7:0:0:0: [sdh] tag#15 CDB: Read(16) 88 00 00 00 00 00 af b2 bb 48 00 00 05 40 00 00
[12235.372916] blk_update_request: I/O error, dev sdh, sector 2947727304
[12235.372941] ata8: EH complete
[12266.856747] ata8.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x0
[12266.856753] ata8.00: irq_stat 0x40000008
[12266.856756] ata8.00: failed command: READ FPDMA QUEUED
[12266.856762] ata8.00: cmd 60/40:d8:08:17:b5/05:00:af:00:00/40 tag 27 ncq 688128 in
res 41/40:00:18:1b:b5/00:00:af:00:00/40 Emask 0x409 (media error) <F>
[12266.856765] ata8.00: status: { DRDY ERR }
[12266.856767] ata8.00: error: { UNC }
[12266.858112] ata8.00: configured for UDMA/133
Here are the output for "smartctl -x" for each disk in the array: http://pastebin.com/PCMMByJc
And here's my complete dmesg: http://pastebin.com/bwkhXh2S
This is the current status of the array:
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sda[0] sdf[12](S) sdg[11](S) sdj[9] sdh[7] sdi[6] sdk[10] sde[4] sdd[3] sdc[2] sdb[1]
20510948416 blocks super 1.2 level 6, 64k chunk, algorithm 2 [9/9] [UUUUUUUUU]
unused devices: <none>
$ mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sat Jun 14 18:47:44 2014
Raid Level : raid6
Array Size : 20510948416 (19560.77 GiB 21003.21 GB)
Used Dev Size : 2930135488 (2794.40 GiB 3000.46 GB)
Raid Devices : 9
Total Devices : 11
Persistence : Superblock is persistent
Update Time : Sun Mar 20 18:04:04 2016
State : clean
Active Devices : 9
Working Devices : 11
Failed Devices : 0
Spare Devices : 2
Layout : left-symmetric
Chunk Size : 64K
Name : brain:0
UUID : e45daf8f:99d0ff7f:e8244429:827e7c71
Events : 2393
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
2 8 32 2 active sync /dev/sdc
3 8 48 3 active sync /dev/sdd
4 8 64 4 active sync /dev/sde
10 8 160 5 active sync /dev/sdk
6 8 128 6 active sync /dev/sdi
7 8 112 7 active sync /dev/sdh
9 8 144 8 active sync /dev/sdj
11 8 96 - spare /dev/sdg
12 8 80 - spare /dev/sdf
The RAID holds an encrypted LUKS container. After opening it, the filesys can't be mounted (see https://mail-archive.com/linux-btrfs@vger.kernel.org/msg51726.html[https://mail-archive.com/linux-btrfs@vger.kernel.org/msg51726.html]).
Could this be due to errors on the raid?
Should i manually fail /dev/sdh and rebuild?
Thank you & kind Regards
^ permalink raw reply
* Re: Raid server Motherboard recommendation.
From: Ram Ramesh @ 2016-03-19 18:42 UTC (permalink / raw)
To: Dave Stevens; +Cc: Andreas Klauer, Roman Mamedov, Linux Raid
In-Reply-To: <20160318154152.10835s56gu5tsab4@webmail.uniserve.com>
On 03/18/2016 05:41 PM, Dave Stevens wrote:
> Quoting Ram Ramesh <rramesh2400@gmail.com>:
>
>> On 03/17/2016 04:52 AM, Andreas Klauer wrote:
>>> On Wed, Mar 16, 2016 at 05:38:14PM -0500, Ram Ramesh wrote:
>>>> If you don't mind, could you share with me the standalone card that
>>>> you
>>>> use?
>>> I think this is the same I use:
>>>
>>> http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
>>>
>>>
>>> It has two ports, and you can choose between internal and external
>>> via 4 jumpers per port.
>>>
>>> You also find this Asmedia chipset on a lot of Asus/Asrock
>>> mainboards that have two additional SATA ports.
>>>
>>>> BTW, have you stressed your card through a rebuild/checkarray?
>>> I run checkarray every day (each day a different part of disk so
>>> entire disk is covered in a week or so) with no issue.
>>>
>>> I also mirror my single SSD disk to the HDD RAID once a week.
>>>
>>> I can run a mkfs.ext4 -c -c on a LVM partition at a later time, but
>>> so far no issues whatsoever.
>>>
>>> Regards
>>> Andreas Klauer
>> Thanks.
>>
>> I saw similar one on Amazon too:
>> http://www.amazon.com/Express-Adapter-Converter-ASMEDIA-ASM1061/dp/B008BZAVVE
>>
>> I am getting asrock extreme6 and that will be enough for the next
>> 6months (eventually I want to have a total of 12). Before that time,
>> I will probably buy the card you have given unless I get nervous
>> about ebay vendor and choose amazon version.
>>
>> Regards
>> Rameshn
>
>
> Hi Ramesh,
>
> Why are you considering only hardware RAID? Software RAID is basically
> free and you needn't be concerned about board manufacturers going out
> of business or changing the board BIOS and so on.
>
> Dave
>
>>
>>
>> --
>> 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
>>
>
>
>
Dave,
Not sure what you mean. I am only talking about mdadm. I just needed
extra sata ports to hook up more drives. None of my
conversation is about hardware raid. I have never used or wanted to have
hardware raid.
Ramesh
^ permalink raw reply
* RE: RE
From: Robert @ 2016-03-19 10:06 UTC (permalink / raw)
Please confirm receipt of my previous mail..When can i call you
^ permalink raw reply
* Re: Raid server Motherboard recommendation.
From: Dave Stevens @ 2016-03-18 22:41 UTC (permalink / raw)
To: Ram Ramesh; +Cc: Andreas Klauer, Roman Mamedov, Linux Raid
In-Reply-To: <56EB87E3.6060504@gmail.com>
Quoting Ram Ramesh <rramesh2400@gmail.com>:
> On 03/17/2016 04:52 AM, Andreas Klauer wrote:
>> On Wed, Mar 16, 2016 at 05:38:14PM -0500, Ram Ramesh wrote:
>>> If you don't mind, could you share with me the standalone card that you
>>> use?
>> I think this is the same I use:
>>
>> http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
>>
>> It has two ports, and you can choose between internal and external
>> via 4 jumpers per port.
>>
>> You also find this Asmedia chipset on a lot of Asus/Asrock
>> mainboards that have two additional SATA ports.
>>
>>> BTW, have you stressed your card through a rebuild/checkarray?
>> I run checkarray every day (each day a different part of disk so
>> entire disk is covered in a week or so) with no issue.
>>
>> I also mirror my single SSD disk to the HDD RAID once a week.
>>
>> I can run a mkfs.ext4 -c -c on a LVM partition at a later time, but
>> so far no issues whatsoever.
>>
>> Regards
>> Andreas Klauer
> Thanks.
>
> I saw similar one on Amazon too:
> http://www.amazon.com/Express-Adapter-Converter-ASMEDIA-ASM1061/dp/B008BZAVVE
>
> I am getting asrock extreme6 and that will be enough for the next
> 6months (eventually I want to have a total of 12). Before that time,
> I will probably buy the card you have given unless I get nervous
> about ebay vendor and choose amazon version.
>
> Regards
> Rameshn
Hi Ramesh,
Why are you considering only hardware RAID? Software RAID is basically
free and you needn't be concerned about board manufacturers going out
of business or changing the board BIOS and so on.
Dave
>
>
> --
> 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
>
--
"As long as politics is the shadow cast on society by big business,
the attenuation of the shadow will not change the substance."
-- John Dewey
^ permalink raw reply
* Re: Raid server Motherboard recommendation.
From: Ram Ramesh @ 2016-03-18 4:45 UTC (permalink / raw)
To: Andreas Klauer; +Cc: Roman Mamedov, Linux Raid
In-Reply-To: <20160317095252.GA3822@EIS>
On 03/17/2016 04:52 AM, Andreas Klauer wrote:
> On Wed, Mar 16, 2016 at 05:38:14PM -0500, Ram Ramesh wrote:
>> If you don't mind, could you share with me the standalone card that you
>> use?
> I think this is the same I use:
>
> http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
>
> It has two ports, and you can choose between internal and external via 4 jumpers per port.
>
> You also find this Asmedia chipset on a lot of Asus/Asrock mainboards that have two additional SATA ports.
>
>> BTW, have you stressed your card through a rebuild/checkarray?
> I run checkarray every day (each day a different part of disk so entire disk is covered in a week or so) with no issue.
>
> I also mirror my single SSD disk to the HDD RAID once a week.
>
> I can run a mkfs.ext4 -c -c on a LVM partition at a later time, but so far no issues whatsoever.
>
> Regards
> Andreas Klauer
Thanks.
I saw similar one on Amazon too:
http://www.amazon.com/Express-Adapter-Converter-ASMEDIA-ASM1061/dp/B008BZAVVE
I am getting asrock extreme6 and that will be enough for the next
6months (eventually I want to have a total of 12). Before that time, I
will probably buy the card you have given unless I get nervous about
ebay vendor and choose amazon version.
Regards
Ramesh
^ permalink raw reply
* Re: [PATCH] raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
From: Shaohua Li @ 2016-03-17 21:24 UTC (permalink / raw)
To: Joe Lawrence; +Cc: Nate Dailey, linux-raid
In-Reply-To: <56EB13C6.8080009@stratus.com>
On Thu, Mar 17, 2016 at 04:29:58PM -0400, Joe Lawrence wrote:
> On 02/29/2016 10:43 AM, Nate Dailey wrote:
> > If raid1d is handling a mix of read and write errors, handle_read_error's
> > call to freeze_array can get stuck.
> >
> > This can happen because, though the bio_end_io_list is initially drained,
> > writes can be added to it via handle_write_finished as the retry_list
> > is processed. These writes contribute to nr_pending but are not included
> > in nr_queued.
> >
> > If a later entry on the retry_list triggers a call to handle_read_error,
> > freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
> > on the bio_end_io_list aren't included in nr_queued so the condition will
> > never be satisfied.
> >
> > To prevent the hang, include bio_end_io_list writes in nr_queued.
> >
> > There's probably a better way to handle decrementing nr_queued, but this
> > seemed like the safest way to avoid breaking surrounding code.
> >
> > I'm happy to supply the script I used to repro this hang.
> >
> > Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
> > ---
> > drivers/md/raid1.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> > index 4e3843f..bb5bce0 100644
> > --- a/drivers/md/raid1.c
> > +++ b/drivers/md/raid1.c
> > @@ -2274,6 +2274,7 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
> > if (fail) {
> > spin_lock_irq(&conf->device_lock);
> > list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
> > + conf->nr_queued++;
> > spin_unlock_irq(&conf->device_lock);
> > md_wakeup_thread(conf->mddev->thread);
> > } else {
> > @@ -2391,8 +2392,10 @@ static void raid1d(struct md_thread *thread)
> > LIST_HEAD(tmp);
> > spin_lock_irqsave(&conf->device_lock, flags);
> > if (!test_bit(MD_CHANGE_PENDING, &mddev->flags)) {
> > - list_add(&tmp, &conf->bio_end_io_list);
> > - list_del_init(&conf->bio_end_io_list);
> > + while (!list_empty(&conf->bio_end_io_list)) {
> > + list_move(conf->bio_end_io_list.prev, &tmp);
> > + conf->nr_queued--;
> > + }
> > }
> > spin_unlock_irqrestore(&conf->device_lock, flags);
> > while (!list_empty(&tmp)) {
> >
>
> Nate, Shaohua,
>
> It looks like bio_end_io_list was added in 55ce74d4bfe1 "md/raid1:
> ensure device failure recorded before write request returns", which
> dates back a ways:
>
> % git tag --contains 55ce74d4bfe1b | grep -v 'rc' | sort -V
> v4.3
> v4.4
> v4.5
>
> Should these patches have 'Fixes' tags for stable backporting?
i'll add it
^ permalink raw reply
* Re: [PATCH] raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
From: Joe Lawrence @ 2016-03-17 20:29 UTC (permalink / raw)
To: Nate Dailey, linux-raid, shli
In-Reply-To: <1456760638-23936-1-git-send-email-nate.dailey@stratus.com>
On 02/29/2016 10:43 AM, Nate Dailey wrote:
> If raid1d is handling a mix of read and write errors, handle_read_error's
> call to freeze_array can get stuck.
>
> This can happen because, though the bio_end_io_list is initially drained,
> writes can be added to it via handle_write_finished as the retry_list
> is processed. These writes contribute to nr_pending but are not included
> in nr_queued.
>
> If a later entry on the retry_list triggers a call to handle_read_error,
> freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
> on the bio_end_io_list aren't included in nr_queued so the condition will
> never be satisfied.
>
> To prevent the hang, include bio_end_io_list writes in nr_queued.
>
> There's probably a better way to handle decrementing nr_queued, but this
> seemed like the safest way to avoid breaking surrounding code.
>
> I'm happy to supply the script I used to repro this hang.
>
> Signed-off-by: Nate Dailey <nate.dailey@stratus.com>
> ---
> drivers/md/raid1.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 4e3843f..bb5bce0 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -2274,6 +2274,7 @@ static void handle_write_finished(struct r1conf *conf, struct r1bio *r1_bio)
> if (fail) {
> spin_lock_irq(&conf->device_lock);
> list_add(&r1_bio->retry_list, &conf->bio_end_io_list);
> + conf->nr_queued++;
> spin_unlock_irq(&conf->device_lock);
> md_wakeup_thread(conf->mddev->thread);
> } else {
> @@ -2391,8 +2392,10 @@ static void raid1d(struct md_thread *thread)
> LIST_HEAD(tmp);
> spin_lock_irqsave(&conf->device_lock, flags);
> if (!test_bit(MD_CHANGE_PENDING, &mddev->flags)) {
> - list_add(&tmp, &conf->bio_end_io_list);
> - list_del_init(&conf->bio_end_io_list);
> + while (!list_empty(&conf->bio_end_io_list)) {
> + list_move(conf->bio_end_io_list.prev, &tmp);
> + conf->nr_queued--;
> + }
> }
> spin_unlock_irqrestore(&conf->device_lock, flags);
> while (!list_empty(&tmp)) {
>
Nate, Shaohua,
It looks like bio_end_io_list was added in 55ce74d4bfe1 "md/raid1:
ensure device failure recorded before write request returns", which
dates back a ways:
% git tag --contains 55ce74d4bfe1b | grep -v 'rc' | sort -V
v4.3
v4.4
v4.5
Should these patches have 'Fixes' tags for stable backporting?
Regards,
-- Joe
^ permalink raw reply
* Re: Raid server Motherboard recommendation.
From: Andreas Klauer @ 2016-03-17 9:52 UTC (permalink / raw)
To: Ram Ramesh; +Cc: Roman Mamedov, Linux Raid
In-Reply-To: <56E9E056.7000204@gmail.com>
On Wed, Mar 16, 2016 at 05:38:14PM -0500, Ram Ramesh wrote:
> If you don't mind, could you share with me the standalone card that you
> use?
I think this is the same I use:
http://www.ebay.com/itm/PCI-E-Express-SATA3-SATA3-0-6Gb-s-eSATA-SATA-III-Card-ASMEDIA1061-/231378681315
It has two ports, and you can choose between internal and external via 4 jumpers per port.
You also find this Asmedia chipset on a lot of Asus/Asrock mainboards that have two additional SATA ports.
> BTW, have you stressed your card through a rebuild/checkarray?
I run checkarray every day (each day a different part of disk so entire disk is covered in a week or so) with no issue.
I also mirror my single SSD disk to the HDD RAID once a week.
I can run a mkfs.ext4 -c -c on a LVM partition at a later time, but so far no issues whatsoever.
Regards
Andreas Klauer
^ permalink raw reply
* Re: Raid server Motherboard recommendation.
From: Ram Ramesh @ 2016-03-16 22:38 UTC (permalink / raw)
To: Andreas Klauer; +Cc: Roman Mamedov, Linux Raid
In-Reply-To: <20151112151105.GA32385@EIS>
On 11/12/2015 09:11 AM, Andreas Klauer wrote:
> On Thu, Nov 12, 2015 at 08:15:01AM -0600, Ram Ramesh wrote:
>> Thanks. I did see that. But, in newegg, there are reviews dated much
>> later than above complaining about ubuntu 14.04 installs failing with
>> ASMedia enabled. So, I concluded that it is iffy. I could not see any
>> consistent message of positive result.
> I use ASMedia controllers myself, onboard and as standalone card.
> They were cheap (much cheaper than getting a board with additional
> ports using the same chipset really) and I don't need the PCIe slots
> for anything else.
>
> They work fine in AHCI mode for HDD, with mdadm software raid.
>
> If you have a CD drive hooked to it the kernel will crash.
> Until you add libata.atapi_passthru16=0 to your cmdline.
>
> Regards
> Andreas
Andreas
If you don't mind, could you share with me the standalone card that you
use?
I used SYBA SI-PEX40064
(http://www.newegg.com/Product/Product.aspx?Item=N82E16816124064)
and under load (mkfs.ext4 -c -c on just one drive) it drops the drives
and a reboot
is required to get them back. This means I cannot put raid component on this
without risking degrading the array. I believe SYBA based on Marvell
88SE9215.
BTW, have you stressed your card through a rebuild/checkarray?
Thanks
Ramesh
^ permalink raw reply
* Re: [PATCH] md/raid5: Cleanup cpu hotplug notifier
From: Shaohua Li @ 2016-03-16 17:11 UTC (permalink / raw)
To: Anna-Maria Gleixner; +Cc: linux-kernel, rt, linux-raid
In-Reply-To: <1458116723-66984-1-git-send-email-anna-maria@linutronix.de>
On Wed, Mar 16, 2016 at 09:25:23AM +0100, Anna-Maria Gleixner wrote:
> The raid456_cpu_notify() hotplug callback lacks handling of the
> CPU_UP_CANCELED case. That means if CPU_UP_PREPARE fails, the scratch
> buffer is leaked.
>
> Add handling for CPU_UP_CANCELED[_FROZEN] hotplug notifier transitions
> to free the scratch buffer.
>
> CC: Shaohua Li <shli@kernel.org>
> CC: linux-raid@vger.kernel.org
> Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Applied, thanks!
^ permalink raw reply
* [PATCH] md/raid5: Cleanup cpu hotplug notifier
From: Anna-Maria Gleixner @ 2016-03-16 8:25 UTC (permalink / raw)
To: linux-kernel; +Cc: rt, Anna-Maria Gleixner, Shaohua Li, linux-raid
The raid456_cpu_notify() hotplug callback lacks handling of the
CPU_UP_CANCELED case. That means if CPU_UP_PREPARE fails, the scratch
buffer is leaked.
Add handling for CPU_UP_CANCELED[_FROZEN] hotplug notifier transitions
to free the scratch buffer.
CC: Shaohua Li <shli@kernel.org>
CC: linux-raid@vger.kernel.org
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
---
drivers/md/raid5.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6376,6 +6376,8 @@ static int raid456_cpu_notify(struct not
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
+ case CPU_UP_CANCELED:
+ case CPU_UP_CANCELED_FROZEN:
free_scratch_buffer(conf, per_cpu_ptr(conf->percpu, cpu));
break;
default:
^ permalink raw reply
* [PATCH v2 4/4] md: dm-crypt: Initialize the sector number for one request
From: Baolin Wang @ 2016-03-15 7:48 UTC (permalink / raw)
To: herbert, davem, agk, snitzer, axboe, dm-devel
Cc: akpm, david.s.gordon, thomas.lendacky, robert.jarzmik,
yamada.masahiro, smueller, tadeusz.struk, standby24x7, shli,
broonie, linus.walleij, arnd, baolin.wang, linux-kernel,
linux-crypto, linux-raid
In-Reply-To: <cover.1458023695.git.baolin.wang@linaro.org>
If the crypto engine can support the bulk mode, that means the contiguous
requests from one block can be merged into one request to be handled by
crypto engine. If so, the crypto engine need the sector number of one request
to do merging action.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/md/dm-crypt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 3147c8d..9e2dbfd 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -866,6 +866,7 @@ static int crypt_convert_block(struct crypt_config *cc,
return r;
}
+ req->sector = ctx->cc_sector;
ablkcipher_request_set_crypt(req, &dmreq->sg_in, &dmreq->sg_out,
1 << SECTOR_SHIFT, iv);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] crypto: Introduce the bulk mode for crypto engine framework
From: Baolin Wang @ 2016-03-15 7:48 UTC (permalink / raw)
To: herbert, davem, agk, snitzer, axboe, dm-devel
Cc: akpm, david.s.gordon, thomas.lendacky, robert.jarzmik,
yamada.masahiro, smueller, tadeusz.struk, standby24x7, shli,
broonie, linus.walleij, arnd, baolin.wang, linux-kernel,
linux-crypto, linux-raid
In-Reply-To: <cover.1458023695.git.baolin.wang@linaro.org>
Now some cipher hardware engines prefer to handle bulk block by merging
requests to increase the block size and thus increase the hardware engine
processing speed.
This patch introduces request bulk mode to help the crypto hardware drivers
improve in efficiency, and chooses the suitable mode (SECTOR_MODE) for
initializing omap aes engine.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
crypto/Kconfig | 1 +
crypto/crypto_engine.c | 122 +++++++++++++++++++++++++++++++++++++++++++--
drivers/crypto/omap-aes.c | 2 +-
include/crypto/algapi.h | 23 ++++++++-
4 files changed, 143 insertions(+), 5 deletions(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index c844227..6a2f9a6 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -229,6 +229,7 @@ config CRYPTO_GLUE_HELPER_X86
config CRYPTO_ENGINE
tristate
+ select CRYPTO_ABLK_HELPER
comment "Authenticated Encryption with Associated Data"
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index a55c82d..0de5829 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/delay.h>
+#include <crypto/ablk_helper.h>
#include "internal.h"
#define CRYPTO_ENGINE_MAX_QLEN 10
@@ -84,6 +85,17 @@ static void crypto_pump_requests(struct crypto_engine *engine,
req = ablkcipher_request_cast(async_req);
+ /*
+ * If the engine supports the bulk mode and the request is allocated the
+ * sg table to expand scatterlists entries, then it need to point the
+ * scatterlists from the sg table.
+ */
+ if (engine->mode == SECTOR_BULK_MODE && req->sgt_src.orig_nents &&
+ req->sgt_dst.orig_nents) {
+ req->src = req->sgt_src.sgl;
+ req->dst = req->sgt_dst.sgl;
+ }
+
engine->cur_req = req;
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
@@ -137,9 +149,46 @@ static void crypto_pump_work(struct kthread_work *work)
}
/**
+ * crypto_merge_request_to_engine - try to merge one request into previous one
+ * @engine: the hardware engine
+ * @req: the request need to be merged
+ *
+ * If the crypto engine supports bulk mode, then try to merge the new request
+ * into the listed one from engine queue to handle them together.
+ *
+ * Return 0 on success and others are failed.
+ */
+static bool crypto_merge_request_to_engine(struct crypto_engine *engine,
+ struct ablkcipher_request *req)
+{
+ /*
+ * The request is allocated from memory pool in dm-crypt, here need to
+ * do initialization for sg table in case some random values.
+ */
+ req->sgt_src.orig_nents = 0;
+ req->sgt_dst.orig_nents = 0;
+
+ /*
+ * If the hardware engine can not support the bulk mode encryption,
+ * just return 1 means merging failed.
+ */
+ if (engine->mode != SECTOR_BULK_MODE)
+ return 1;
+
+ return ablk_try_merge(&engine->queue, req);
+}
+
+/**
* crypto_transfer_request - transfer the new request into the engine queue
* @engine: the hardware engine
* @req: the request need to be listed into the engine queue
+ *
+ * Firstly it will check if the new request can be merged into previous one
+ * if their secotr numbers are continuous, if not should list it into engine
+ * queue.
+ *
+ * If the new request can be merged into the previous request, then just
+ * finalize the new request.
*/
int crypto_transfer_request(struct crypto_engine *engine,
struct ablkcipher_request *req, bool need_pump)
@@ -154,6 +203,26 @@ int crypto_transfer_request(struct crypto_engine *engine,
return -ESHUTDOWN;
}
+ /*
+ * Here need to check if the request can be merged into previous
+ * request. If the hardware engine can support encryption with
+ * bulk block, we can merge the new request into previous request
+ * if their secotr numbers are continuous, which can be handled
+ * together by engine to improve the encryption efficiency.
+ * Return -EINPROGRESS means it has been merged into previous request,
+ * so just end up this request.
+ */
+ ret = crypto_merge_request_to_engine(engine, req);
+ if (!ret) {
+ spin_unlock_irqrestore(&engine->queue_lock, flags);
+ crypto_finalize_request(engine, req, 0);
+ return -EINPROGRESS;
+ }
+
+ /*
+ * If the request can not be merged into previous request, then list it
+ * into the queue of engine, and will be handled by kthread worker.
+ */
ret = ablkcipher_enqueue_request(&engine->queue, req);
if (!engine->busy && need_pump)
@@ -178,7 +247,8 @@ int crypto_transfer_request_to_engine(struct crypto_engine *engine,
EXPORT_SYMBOL_GPL(crypto_transfer_request_to_engine);
/**
- * crypto_finalize_request - finalize one request if the request is done
+ * crypto_finalize_request - finalize one request if the request is done or
+ * merged into previous request
* @engine: the hardware engine
* @req: the request need to be finalized
* @err: error number
@@ -208,9 +278,18 @@ void crypto_finalize_request(struct crypto_engine *engine,
spin_unlock_irqrestore(&engine->queue_lock, flags);
}
+ sg_free_table(&req->sgt_src);
+ sg_free_table(&req->sgt_dst);
req->base.complete(&req->base, err);
- queue_kthread_work(&engine->kworker, &engine->pump_requests);
+ /*
+ * If the request is finalized by merging into the previous request from
+ * the engine queue, then it is no need to queue the kthread work.
+ * Cause now maybe there are other requests need to be merged into the
+ * listed request from one block, just wait for merging action.
+ */
+ if (finalize_cur_req)
+ queue_kthread_work(&engine->kworker, &engine->pump_requests);
}
EXPORT_SYMBOL_GPL(crypto_finalize_request);
@@ -279,15 +358,45 @@ int crypto_engine_stop(struct crypto_engine *engine)
EXPORT_SYMBOL_GPL(crypto_engine_stop);
/**
+ * crypto_engine_change_mode - Change the mode for hardware engine
+ * @engine: the hardware engine
+ * @mode: engine mode to be set
+ *
+ * This function can change the hardware engine mode when the engine is running.
+ * Return 0 on success, else on fail.
+ */
+int crypto_engine_change_mode(struct crypto_engine *engine,
+ enum engine_mode mode)
+{
+ unsigned long flags;
+ int ret;
+
+ ret = crypto_engine_stop(engine);
+ if (ret) {
+ pr_warn("could not change engine mode now\n");
+ return ret;
+ }
+
+ spin_lock_irqsave(&engine->queue_lock, flags);
+ engine->mode = mode;
+ spin_unlock_irqrestore(&engine->queue_lock, flags);
+
+ return crypto_engine_start(engine);
+}
+EXPORT_SYMBOL_GPL(crypto_engine_change_mode);
+
+/**
* crypto_engine_alloc_init - allocate crypto hardware engine structure and
* initialize it.
* @dev: the device attached with one hardware engine
+ * @mode: crypto engine mode
* @rt: whether this queue is set to run as a realtime task
*
* This must be called from context that can sleep.
* Return: the crypto engine structure on success, else NULL.
*/
-struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
+struct crypto_engine *crypto_engine_alloc_init(struct device *dev,
+ enum engine_mode mode, bool rt)
{
struct sched_param param = { .sched_priority = MAX_RT_PRIO - 1 };
struct crypto_engine *engine;
@@ -299,6 +408,13 @@ struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt)
if (!engine)
return NULL;
+ /*
+ * If the hardware engine can handle the IV by itself, that means it
+ * just need one initial IV for multiple requests from one block. So
+ * we can merge requests from one block into one request to handle,
+ * which can improve the hardware engine efficiency.
+ */
+ engine->mode = mode;
engine->rt = rt;
engine->running = false;
engine->busy = false;
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index d420ec7..946f11f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1230,7 +1230,7 @@ static int omap_aes_probe(struct platform_device *pdev)
}
/* Initialize crypto engine */
- dd->engine = crypto_engine_alloc_init(dev, 1);
+ dd->engine = crypto_engine_alloc_init(dev, SECTOR_MODE, 1);
if (!dd->engine)
goto err_algs;
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index b09d43f..69fb43e 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -130,6 +130,22 @@ struct ablkcipher_walk {
};
#define ENGINE_NAME_LEN 30
+
+/*
+ * enum engine_mode - crypto engine mode
+ * @SECTOR_MODE: should do encryption/decryption one request by one (one
+ * request length is one sector size), and it will not coalesce requests.
+ * @SECTOR_BULK_MODE: it can coalesce the contiguous requests (one request
+ * length is one sector size) together to be one bulk request, which can be
+ * handled by crypto engine at one time.
+ * @MAX_MODE: engine mode numbers
+ */
+enum engine_mode {
+ SECTOR_MODE,
+ SECTOR_BULK_MODE,
+ MAX_MODE,
+};
+
/*
* struct crypto_engine - crypto hardware engine
* @name: the engine name
@@ -140,6 +156,7 @@ struct ablkcipher_walk {
* @list: link with the global crypto engine list
* @queue_lock: spinlock to syncronise access to request queue
* @queue: the crypto queue of the engine
+ * @mode: crypto engine mode
* @rt: whether this queue is set to run as a realtime task
* @prepare_crypt_hardware: a request will soon arrive from the queue
* so the subsystem requests the driver to prepare the hardware
@@ -167,6 +184,7 @@ struct crypto_engine {
spinlock_t queue_lock;
struct crypto_queue queue;
+ enum engine_mode mode;
bool rt;
int (*prepare_crypt_hardware)(struct crypto_engine *engine);
@@ -195,7 +213,10 @@ void crypto_finalize_request(struct crypto_engine *engine,
struct ablkcipher_request *req, int err);
int crypto_engine_start(struct crypto_engine *engine);
int crypto_engine_stop(struct crypto_engine *engine);
-struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
+int crypto_engine_change_mode(struct crypto_engine *engine,
+ enum engine_mode mode);
+struct crypto_engine *crypto_engine_alloc_init(struct device *dev,
+ enum engine_mode mode, bool rt);
int crypto_engine_exit(struct crypto_engine *engine);
extern const struct crypto_type crypto_ablkcipher_type;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/4] crypto: Introduce some helper functions to help to merge requests
From: Baolin Wang @ 2016-03-15 7:48 UTC (permalink / raw)
To: herbert, davem, agk, snitzer, axboe, dm-devel
Cc: akpm, david.s.gordon, thomas.lendacky, robert.jarzmik,
yamada.masahiro, smueller, tadeusz.struk, standby24x7, shli,
broonie, linus.walleij, arnd, baolin.wang, linux-kernel,
linux-crypto, linux-raid
In-Reply-To: <cover.1458023695.git.baolin.wang@linaro.org>
Usually the dm-crypt subsystem will send encryption/descryption requests to
the crypto layer one block at a time, making each request 512 bytes long,
which is a much smaller size for hardware engine, that means the hardware
engine can not play its best performance.
Now some cipher hardware engines prefer to handle bulk block rather than one
sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
the intermediate values (IV) by themselves in one bulk block. This means we
can increase the size of the request by merging request rather than always 512
bytes and thus increase the hardware engine processing speed.
This patch introduces some helper functions to help to merge requests to improve
hardware engine efficiency.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
crypto/ablk_helper.c | 135 ++++++++++++++++++++++++++++++++++++++++++
include/crypto/ablk_helper.h | 3 +
include/linux/crypto.h | 5 ++
3 files changed, 143 insertions(+)
diff --git a/crypto/ablk_helper.c b/crypto/ablk_helper.c
index e1fcf53..3cf15cb 100644
--- a/crypto/ablk_helper.c
+++ b/crypto/ablk_helper.c
@@ -26,6 +26,7 @@
#include <linux/kernel.h>
#include <linux/crypto.h>
+#include <linux/device-mapper.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/hardirq.h>
@@ -34,6 +35,140 @@
#include <crypto/ablk_helper.h>
#include <asm/simd.h>
+/**
+ * ablk_link_request_if_contigous - try to link one request into previous one
+ * if the page address is contiguous.
+ * @list_req: the request from queue list
+ * @req: the new request need to be merged
+ *
+ * If the listed request and new request's pages of the scatterlists are
+ * contiguous, then merge the scatterlists of new request into the listed one.
+ *
+ * Return true on success, others means failed.
+ */
+static bool ablk_link_request_if_contigous(struct ablkcipher_request *list_req,
+ struct ablkcipher_request *req)
+{
+ struct scatterlist *last_src_sg =
+ sg_last(list_req->sgt_src.sgl, list_req->sgt_src.nents);
+ struct scatterlist *last_dst_sg =
+ sg_last(list_req->sgt_dst.sgl, list_req->sgt_dst.nents);
+ struct scatterlist *req_src_sg = req->src;
+ struct scatterlist *req_dst_sg = req->dst;
+
+ if (!last_src_sg || !last_dst_sg)
+ return false;
+
+ /* Check if the src/dst scatterlists are contiguous */
+ if (!sg_is_contiguous(last_src_sg, req_src_sg) ||
+ !sg_is_contiguous(last_dst_sg, req_dst_sg))
+ return false;
+
+ /*
+ * If the request can be merged into the listed request after the
+ * checking, then expand the listed request scatterlists' length.
+ */
+ last_src_sg->length += req_src_sg->length;
+ last_dst_sg->length += req_dst_sg->length;
+ list_req->nbytes += req->nbytes;
+
+ return true;
+}
+
+/**
+ * ablk_merge_request - try to merge one request into previous one
+ * @list_req: the request from queue list
+ * @req: the request need to be merged
+ *
+ * This function will create a dynamic scatterlist table for both source
+ * and destination if the request is the first coming in.
+ *
+ * Return true on success, others means failed.
+ */
+static bool ablk_merge_request(struct ablkcipher_request *list_req,
+ struct ablkcipher_request *req)
+{
+ struct sg_table *sgt_src = &list_req->sgt_src;
+ struct sg_table *sgt_dst = &list_req->sgt_dst;
+ unsigned int nents = SG_MAX_SINGLE_ALLOC;
+
+ if (sg_table_is_empty(sgt_src)) {
+ if (sg_alloc_empty_table(sgt_src, nents, GFP_ATOMIC))
+ return false;
+
+ if (sg_add_sg_to_table(sgt_src, list_req->src))
+ return false;
+ }
+
+ if (sg_table_is_empty(sgt_dst)) {
+ if (sg_alloc_empty_table(sgt_dst, nents, GFP_ATOMIC))
+ return false;
+
+ if (sg_add_sg_to_table(sgt_dst, list_req->dst))
+ return false;
+ }
+
+ /*
+ * Check if the new request is contiguous for the listed request,
+ * if it is contiguous then merge the new request into the listed one.
+ */
+ if (ablk_link_request_if_contigous(list_req, req))
+ return true;
+
+ if (sg_add_sg_to_table(sgt_src, req->src))
+ return false;
+
+ if (sg_add_sg_to_table(sgt_dst, req->dst))
+ return false;
+
+ list_req->nbytes += req->nbytes;
+ return true;
+}
+
+/**
+ * ablk_try_merge - try to merge one request into previous one
+ * @queue: the crypto queue list
+ * @req: the request need to be merged
+ *
+ * Note: The merging action should be under the spinlock or mutex protection.
+ *
+ * Return 0 on success and others are failed.
+ */
+int ablk_try_merge(struct crypto_queue *queue,
+ struct ablkcipher_request *req)
+{
+ struct ablkcipher_request *list_req;
+ struct crypto_async_request *async_req;
+
+ list_for_each_entry(async_req, &queue->list, list) {
+ list_req = ablkcipher_request_cast(async_req);
+
+ if (list_req->base.flags != req->base.flags)
+ continue;
+
+ /* Check that the request adds up to an even number of sectors */
+ if (!IS_ALIGNED(list_req->nbytes, (1U << SECTOR_SHIFT)))
+ continue;
+
+ if (list_req->nbytes + req->nbytes > UINT_MAX)
+ continue;
+
+ /*
+ * We first check that the sectors are adjacent so we don't
+ * mistadly coalesce something that is contigous in memory but
+ * not contigous on disk.
+ */
+ if (list_req->sector + list_req->nbytes /
+ (1U << SECTOR_SHIFT) == req->sector) {
+ if (ablk_merge_request(list_req, req))
+ return 0;
+ }
+ }
+
+ return 1;
+}
+EXPORT_SYMBOL_GPL(ablk_try_merge);
+
int ablk_set_key(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int key_len)
{
diff --git a/include/crypto/ablk_helper.h b/include/crypto/ablk_helper.h
index 4f93df5..12ae00d 100644
--- a/include/crypto/ablk_helper.h
+++ b/include/crypto/ablk_helper.h
@@ -8,6 +8,7 @@
#include <linux/crypto.h>
#include <linux/kernel.h>
#include <crypto/cryptd.h>
+#include <crypto/algapi.h>
struct async_helper_ctx {
struct cryptd_ablkcipher *cryptd_tfm;
@@ -28,4 +29,6 @@ extern int ablk_init_common(struct crypto_tfm *tfm, const char *drv_name);
extern int ablk_init(struct crypto_tfm *tfm);
+extern int ablk_try_merge(struct crypto_queue *queue,
+ struct ablkcipher_request *req);
#endif /* _CRYPTO_ABLK_HELPER_H */
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index e71cb70..f878bb1 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -21,6 +21,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/bug.h>
+#include <linux/scatterlist.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/uaccess.h>
@@ -170,6 +171,10 @@ struct ablkcipher_request {
struct scatterlist *src;
struct scatterlist *dst;
+ struct sg_table sgt_src;
+ struct sg_table sgt_dst;
+ sector_t sector;
+
void *__ctx[] CRYPTO_MINALIGN_ATTR;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/4] scatterlist: Introduce some helper functions
From: Baolin Wang @ 2016-03-15 7:47 UTC (permalink / raw)
To: herbert, davem, agk, snitzer, axboe, dm-devel
Cc: akpm, david.s.gordon, thomas.lendacky, robert.jarzmik,
yamada.masahiro, smueller, tadeusz.struk, standby24x7, shli,
broonie, linus.walleij, arnd, baolin.wang, linux-kernel,
linux-crypto, linux-raid
In-Reply-To: <cover.1458023695.git.baolin.wang@linaro.org>
In crypto engine framework, one request can combine (copy) other requests'
scatterlists into its dynamic sg table to manage them together as a bulk
block , which can improve engine efficency with handling bulk block. Thus
we need some helper functions to manage dynamic scattertables.
This patch introduces 'sg_is_contiguous()' function to check if two
scatterlists are contiguous, 'sg_alloc_empty_table()' function to
allocate one empty dynamic sg table, 'sg_add_sg_to_table()' function
to copy one mapped scatterlist into sg table and 'sg_table_is_empty'
function to check if the sg table is empty.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
include/linux/scatterlist.h | 33 +++++++++++++++++++++
lib/scatterlist.c | 69 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 102 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 556ec1e..c1ed9f4 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -212,6 +212,20 @@ static inline void sg_unmark_end(struct scatterlist *sg)
}
/**
+ * sg_table_is_empty - Check if the sg table is empty
+ * @sgt: sg table
+ *
+ * Description:
+ * The 'orig_nents' member of one sg table is used to indicate how many
+ * scatterlists in the sg table.
+ *
+ **/
+static inline bool sg_table_is_empty(struct sg_table *sgt)
+{
+ return !sgt->orig_nents;
+}
+
+/**
* sg_phys - Return physical address of an sg entry
* @sg: SG entry
*
@@ -241,6 +255,23 @@ static inline void *sg_virt(struct scatterlist *sg)
return page_address(sg_page(sg)) + sg->offset;
}
+/**
+ * sg_is_contiguous - Check if the scatterlists are contiguous
+ * @sga: SG entry
+ * @sgb: SG entry
+ *
+ * Description:
+ * If the sga scatterlist is contiguous with the sgb scatterlist,
+ * that means they can be merged together.
+ *
+ **/
+static inline bool sg_is_contiguous(struct scatterlist *sga,
+ struct scatterlist *sgb)
+{
+ return *(unsigned long *)sg_virt(sga) + sga->length ==
+ *(unsigned long *)sg_virt(sgb);
+}
+
int sg_nents(struct scatterlist *sg);
int sg_nents_for_len(struct scatterlist *sg, u64 len);
struct scatterlist *sg_next(struct scatterlist *);
@@ -261,6 +292,8 @@ void sg_free_table(struct sg_table *);
int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int,
struct scatterlist *, gfp_t, sg_alloc_fn *);
int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
+int sg_alloc_empty_table(struct sg_table *, unsigned int, gfp_t);
+int sg_add_sg_to_table(struct sg_table *, struct scatterlist *);
int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70..6d3f3b0 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -370,6 +370,75 @@ int sg_alloc_table(struct sg_table *table, unsigned int nents, gfp_t gfp_mask)
EXPORT_SYMBOL(sg_alloc_table);
/**
+ * sg_add_sg_to_table - Add one scatterlist into sg table
+ * @sgt: The sg table header to use
+ * @src: The sg need to be added into sg table
+ *
+ * Description:
+ * The 'nents' member indicates how many mapped scatterlists has been added
+ * in the dynamic sg table. The 'orig_nents' member indicates the size of the
+ * dynamic sg table.
+ *
+ * Copy one mapped @src@ scatterlist into the dynamic sg table and increase
+ * 'nents' member.
+ *
+ **/
+int sg_add_sg_to_table(struct sg_table *sgt, struct scatterlist *src)
+{
+ unsigned int i = 0, orig_nents = sgt->orig_nents;
+ struct scatterlist *sgl = sgt->sgl;
+ struct scatterlist *sg;
+
+ /* Check if there are enough space for the new sg to be added */
+ if (sgt->nents >= sgt->orig_nents)
+ return -EINVAL;
+
+ for_each_sg(sgl, sg, orig_nents, i) {
+ if (sgt->nents > 0 && i == (sgt->nents - 1)) {
+ sg_unmark_end(sg);
+ } else if (i == sgt->nents) {
+ memcpy(sg, src, sizeof(struct scatterlist));
+ sg_mark_end(sg);
+ sgt->nents++;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * sg_alloc_empty_table - Allocate one empty dynamic sg table
+ * @sgt: The sg table header to use
+ * @nents: Number of entries in sg list
+ * @gfp_mask: GFP allocation mask
+ *
+ * Description:
+ * Allocate and initialize one dynamic sg table. One dynamic sg table means
+ * it need allocate @nents@ empty scatterlists entries and is used to copy
+ * other mapped scatterlists into the dynamic sg table.
+ *
+ * The 'nents' member indicates how many scatterlists has been copied into
+ * the dynamic sg table. It should set 0 which means there are no mapped
+ * scatterlists added in this sg table now.
+ *
+ * The 'orig_nents' member indicates the size of the dynamic sg table.
+ *
+ **/
+int sg_alloc_empty_table(struct sg_table *sgt, unsigned int nents,
+ gfp_t gfp_mask)
+{
+ int ret;
+
+ ret = sg_alloc_table(sgt, nents, gfp_mask);
+ if (ret)
+ return ret;
+
+ sgt->nents = 0;
+ return 0;
+}
+
+/**
* sg_alloc_table_from_pages - Allocate and initialize an sg table from
* an array of pages
* @sgt: The sg table header to use
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
From: Baolin Wang @ 2016-03-15 7:47 UTC (permalink / raw)
To: herbert, davem, agk, snitzer, axboe, dm-devel
Cc: akpm, david.s.gordon, thomas.lendacky, robert.jarzmik,
yamada.masahiro, smueller, tadeusz.struk, standby24x7, shli,
broonie, linus.walleij, arnd, baolin.wang, linux-kernel,
linux-crypto, linux-raid
Now some cipher hardware engines prefer to handle bulk block by merging requests
to increase the block size and thus increase the hardware engine processing speed.
This patchset introduces request bulk mode to help the crypto hardware drivers
improve in efficiency.
Changes since v1:
- Modify the sg_is_contiguous() function.
Baolin Wang (4):
scatterlist: Introduce some helper functions
crypto: Introduce some helper functions to help to merge requests
crypto: Introduce the bulk mode for crypto engine framework
md: dm-crypt: Initialize the sector number for one request
crypto/Kconfig | 1 +
crypto/ablk_helper.c | 135 ++++++++++++++++++++++++++++++++++++++++++
crypto/crypto_engine.c | 122 +++++++++++++++++++++++++++++++++++++-
drivers/crypto/omap-aes.c | 2 +-
drivers/md/dm-crypt.c | 1 +
include/crypto/ablk_helper.h | 3 +
include/crypto/algapi.h | 23 ++++++-
include/linux/crypto.h | 5 ++
include/linux/scatterlist.h | 33 +++++++++++
lib/scatterlist.c | 69 +++++++++++++++++++++
10 files changed, 389 insertions(+), 5 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns
From: Miklos Szeredi @ 2016-03-14 20:58 UTC (permalink / raw)
To: Seth Forshee
Cc: Eric W. Biederman, Alexander Viro, Serge Hallyn,
Richard Weinberger, Austin S Hemmelgarn, Kernel Mailing List,
linux-bcache, dm-devel, linux-raid, linux-mtd, Linux-Fsdevel,
fuse-devel, LSM, selinux
In-Reply-To: <20160309170726.GB28779@ubuntu-hedt>
On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> On Wed, Mar 09, 2016 at 04:51:42PM +0100, Miklos Szeredi wrote:
>> On Wed, Mar 9, 2016 at 4:25 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
>> > On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote:
>>
>> >> Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe?
>> >
>> > That would be a departure from the current behavior in the !allow_other
>> > case for unprivileged users. Since those mounts are done by an suid
>> > helper all of those ids would be root in the userns, wouldn't they?
>>
>> Well, actually this is what the helper does:
>>
>> sprintf(d, "fd=%i,rootmode=%o,user_id=%u,group_id=%u",
>> fd, rootmode, getuid(), getgid());
>
> Sorry, I was thinking of euid. So this may not be a problem.
>
>> So it just uses the current uid/gid. Apparently no reason to do this
>> in userland, we could just as well set these in the kernel. Except
>> for possible backward compatibility problems for things not using the
>> helper.
>>
>> BUT if the mount is unprivileged or it's a userns mount, or anything
>> previously not possible, then we are not constrained by the backward
>> compatibility issues, and can go with the saner solution.
>>
>> Does that not make sense?
>
> But we generally do want backwards compatibility, and we want userspace
> software to be able to expect the same behavior whether or not it's
> running in a user namespaced container. Obviously we can't always have
> things 100% identical, but we shouldn't break things unless we really
> need to.
>
> However it may be that this isn't actually going to break assumptions of
> existing software like I had feared. My preference is still to not
> change any userspace-visible behaviors since we never know what software
> might have made assumptions based on those behaviors. But if you're
> confident that it won't break anything I'm willing to give it a try.
I'm quite confident it won't make a difference.
Thanks,
Miklos
^ permalink raw reply
* Re: [PATCH] raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang
From: Shaohua Li @ 2016-03-14 18:59 UTC (permalink / raw)
To: Nate Dailey; +Cc: linux-raid
In-Reply-To: <20160306233304.GA3200@kernel.org>
On Sun, Mar 06, 2016 at 03:33:04PM -0800, Shaohua Li wrote:
> On Mon, Feb 29, 2016 at 10:43:58AM -0500, Nate Dailey wrote:
> > If raid1d is handling a mix of read and write errors, handle_read_error's
> > call to freeze_array can get stuck.
> >
> > This can happen because, though the bio_end_io_list is initially drained,
> > writes can be added to it via handle_write_finished as the retry_list
> > is processed. These writes contribute to nr_pending but are not included
> > in nr_queued.
> >
> > If a later entry on the retry_list triggers a call to handle_read_error,
> > freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
> > on the bio_end_io_list aren't included in nr_queued so the condition will
> > never be satisfied.
> >
> > To prevent the hang, include bio_end_io_list writes in nr_queued.
> >
> > There's probably a better way to handle decrementing nr_queued, but this
> > seemed like the safest way to avoid breaking surrounding code.
> >
> > I'm happy to supply the script I used to repro this hang.
>
> Looks good. Could you please also fix raid10?
Alright, I applied the patch and added raid10 part so this can be applied to 4.6
^ permalink raw reply
* Re: [PATCH 0/3] md: trivial changes
From: Shaohua Li @ 2016-03-14 18:16 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: shli, linux-raid
In-Reply-To: <1457946099-1878-1-git-send-email-gqjiang@suse.com>
On Mon, Mar 14, 2016 at 05:01:36PM +0800, Guoqing Jiang wrote:
> Hi,
>
> I found some trivial issues when look into md code, and
> all the changes are based on for-next branch of new md
> tree.
Applied all three, thanks!
Thanks,
Shaohua
^ permalink raw reply
* Re: multipath: I/O hanging forever
From: Shaohua Li @ 2016-03-14 18:16 UTC (permalink / raw)
To: Ming Lei; +Cc: Andrea Righi, Kent Overstreet, linux-raid, linux-kernel
In-Reply-To: <20160312094723.7c6a4ff4@tom-T450>
On Sat, Mar 12, 2016 at 09:47:23AM +0800, Ming Lei wrote:
> On Fri, 11 Mar 2016 15:24:33 -0700
> Andrea Righi <righi.andrea@gmail.com> wrote:
>
> > On Sat, Mar 05, 2016 at 08:31:03PM -0900, Kent Overstreet wrote:
> > > On Fri, Mar 04, 2016 at 10:30:44AM -0700, Andrea Righi wrote:
> > > > On Sun, Feb 28, 2016 at 08:46:16PM -0700, Andrea Righi wrote:
> > > > > On Sun, Feb 28, 2016 at 06:53:33PM -0700, Andrea Righi wrote:
> > > > > ...
> > > > > > I'm using 4.5.0-rc5+, from Linus' git. I'll try to do a git bisect
> > > > > > later, I'm pretty sure this problem has been introduced recently (i.e.,
> > > > > > I've never seen this issue with 4.1.x).
> > > > >
> > > > > I confirm, just tested kernel 4.1 and this problem doesn't happen.
> > > >
> > > > Alright, I had some spare time to bisect this problem and I found that
> > > > the commit that introduced this issue is c66a14d.
> > > >
> > > > So, I tried to revert the commit (with some changes to fix conflicts and
> > > > ABI changes) and now multipath seems to work fine for me (no hung task).
> > >
> > > Is it hanging on first IO, first large IO, or just randomly?
> >
> > It's always the very first O_DIRECT I/O, in general the task gets stuck
> > in do_blockdev_direct_IO().
>
> I can reproduce the issue too, and looks it is a MD issue instead of block.
> Andrea, could you try the following patch to see if it can fix your issue?
>
> ---
> From 43fc9c221e53c64f2df7c100c77cc25c4a98c607 Mon Sep 17 00:00:00 2001
> From: Ming Lei <ming.lei@canonical.com>
> Date: Sat, 12 Mar 2016 09:29:40 +0800
> Subject: [PATCH] md: multipath: don't hardcopy bio in .make_request path
>
> Inside multipath_make_request(), multipath maps the incoming
> bio into low level device's bio, but it is totally wrong to
> copy the bio into mapped bio via '*mapped_bio = *bio'. For
> example, .__bi_remaining is kept in the copy, especially if
> the incoming bio is chained to via bio splitting, so .bi_end_io
> can't be called for the mapped bio at all in the completing path
> in this kind of situation.
>
> This patch fixes the issue by using clone style.
Applied, thanks! Looks this issue exists since immutable bio is introduced, but
triggered recently. Will add to stable too.
Thanks,
Shaohua
^ permalink raw reply
* [PATCH 3/3] md: fix typos for stipe
From: Guoqing Jiang @ 2016-03-14 9:01 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Guoqing Jiang
In-Reply-To: <1457946099-1878-1-git-send-email-gqjiang@suse.com>
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/bitmap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/bitmap.h b/drivers/md/bitmap.h
index 7d5c3a6..5e3fcd6 100644
--- a/drivers/md/bitmap.h
+++ b/drivers/md/bitmap.h
@@ -49,8 +49,8 @@
* When we set a bit, or in the counter (to start a write), if the fields is
* 0, we first set the disk bit and set the counter to 1.
*
- * If the counter is 0, the on-disk bit is clear and the stipe is clean
- * Anything that dirties the stipe pushes the counter to 2 (at least)
+ * If the counter is 0, the on-disk bit is clear and the stripe is clean
+ * Anything that dirties the stripe pushes the counter to 2 (at least)
* and sets the on-disk bit (lazily).
* If a periodic sweep find the counter at 2, it is decremented to 1.
* If the sweep find the counter at 1, the on-disk bit is cleared and the
--
2.6.2
^ permalink raw reply related
* [PATCH 2/3] md/bitmap: remove redundant return in bitmap_checkpage
From: Guoqing Jiang @ 2016-03-14 9:01 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Guoqing Jiang
In-Reply-To: <1457946099-1878-1-git-send-email-gqjiang@suse.com>
The "return 0" is not needed since bitmap_checkpage
will finally return 0 for the case.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/bitmap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index bbe7b64..7df6b4f 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -98,7 +98,6 @@ __acquires(bitmap->lock)
bitmap->bp[page].hijacked) {
/* somebody beat us to getting the page */
kfree(mappage);
- return 0;
} else {
/* no page was in place and we have one, so install it */
--
2.6.2
^ permalink raw reply related
* [PATCH 1/3] md/raid1: remove unnecessary BUG_ON
From: Guoqing Jiang @ 2016-03-14 9:01 UTC (permalink / raw)
To: shli; +Cc: linux-raid, Guoqing Jiang
In-Reply-To: <1457946099-1878-1-git-send-email-gqjiang@suse.com>
Since bitmap_start_sync will not return until
sync_blocks is not less than PAGE_SIZE>>9, so
the BUG_ON is not needed anymore.
Signed-off-by: Guoqing Jiang <gqjiang@suse.com>
---
drivers/md/raid1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 4e3843f..d1d5363 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2695,7 +2695,6 @@ static sector_t raid1_sync_request(struct mddev *mddev, sector_t sector_nr,
!conf->fullsync &&
!test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery))
break;
- BUG_ON(sync_blocks < (PAGE_SIZE>>9));
if ((len >> 9) > sync_blocks)
len = sync_blocks<<9;
}
--
2.6.2
^ permalink raw reply related
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