* What happens with array when external write-intent bitmap fails?
From: Andrei Borzenkov @ 2014-09-16 13:42 UTC (permalink / raw)
To: linux-raid
Theoretically write-intent is optional, so if it fails it would be
possible to simply discard it and continue. But I have seen statement
that if external write-intent bitmap file is not available at time of
assembly, starting of array fails.
Thank you for clarification.
-andrei
^ permalink raw reply
* Re: Raid 1 vs Raid 10 single thread performance
From: keld @ 2014-09-16 10:19 UTC (permalink / raw)
To: Bostjan Skufca; +Cc: David Brown, linux-raid
In-Reply-To: <CAEp_DRAifxNPscq_jUuUM9+1r_1aJzi-W1UnH=jTYa3oxRspqg@mail.gmail.com>
On Tue, Sep 16, 2014 at 09:48:28AM +0200, Bostjan Skufca wrote:
> David and Neil, thanks for hints!
>
> (I was busy with other things lately, but believe it or not I got the
> "why not try raid 10 with only 2 partitions" idea just last night,
> tested it a couple of minutes ago with fascination, and now here I am
> reading your emails - please do not remind me again of time wasted :)
>
> The write performance is curious though:
> - f2: 147 MB/s
> - n2: 162 MB/s
> I was expecting greater difference (bu I must admit this was not
> tested on the whole 3TB disk, just 400GB partition on it).
This is as expected, and also as reported in other benchmarks.
Many expect that writing is considerably slower in F2 than n2,
because the blocks are distributed much more apart in f2 than in n2,
but the elevator algorithm for IO sceduling collects writing blocks
in the cache and does almost equalize the time used for about all mirrored
raid types.
See also https://raid.wiki.kernel.org/index.php/Performance
for more benchmarks.
Best regards
Keld
> b.
>
>
> On 12 September 2014 10:49, David Brown <david.brown@hesbynett.no> wrote:
> > On 10/09/14 23:24, Bostjan Skufca wrote:
> >> Hi,
> >>
> >> I have a simple question:
> >> - Where is the code that is used for actual RAID 10 creation? In
> >> kernel or in mdadm?
> >>
> >>
> >> Explanation:
> >>
> >> I was dissatisfied with single-threaded RAID 1 sequential read
> >> performance (basically boils down to the speed of one disk). I figured
> >> that instead of using level 1 I could create RAID level 10 and use two
> >> equally-sized partitions on each drive (instead of one).
> >>
> >> It turns out that if array is created properly, it is capable of
> >> sequential reads at almost 2x single device speed, as expected (on
> >> SSD!) and what would anyone expect from ordinary RAID 1.
> >>
> >> What does "properly" actually mean?
> >> I was doing some benchmarks with various raid configurations and
> >> figured out that the order of devices submitted to creation command is
> >> significant. It also makes raid10 created in such mode reliable or
> >> unreliable to a device failure (not partition failure, device failure,
> >> which means that two raid underlying devices fail at once).
> >>
> >> Sum:
> >> - if such array is created properly, it has redundancy in place and
> >> performs as expected
> >> - if not, it performs as raid1 and fails with one physical disk failure
> >>
> >> I am trying to find the code responsible for creation of RAID 10 in
> >> order to try and make it more inteligent about where to place RAID 10
> >> parts if it gets a list of devices to use, and some of those devices
> >> are on the same physical disks.
> >>
> >> Thanks for hints,
> >> b.
> >>
> >>
> >>
> >> PS: More details about testing is available here, but be warned, it is
> >> still a bit hectic to read:
> >> http://blog.a2o.si/2014/09/07/linux-software-raid-why-you-should-always-use-raid-10-instead-of-raid-1/
> >
> >
> > Hi,
> >
> > First let me applaud your enthusiasm for trying to inform people about
> > raid in your blog, your interest in investigating different ideas in the
> > hope of making md raid faster and/or easier and/or safer.
> >
> > Then let me tell you your entire blog post is wasted, because md already
> > has a solution that is faster, easier and safer than anything you have
> > come up with so far.
> >
> > You are absolutely correct about the single-threaded read performance of
> > raid1 pairs - for a number of reasons, a single thread read will get
> > reads from only one disk. This is not a problem in many cases, because
> > you often have multiple simultaneous reads on "typical" systems with
> > raid1. But for some cases, such as a high performance desktop, it can
> > be a limitation.
> >
> > You are also correct that the solution is basically to split the drives
> > into two parts, pair up halves from each disk as raid1 mirrors, and
> > stripe the two mirrors as raid0.
> >
> > And you are correct that you have to get the sets right, or you will may
> > lose redundancy and/or speed.
> >
> > Fortunately, Neil and the other md raid developers are way ahead of you.
> >
> > Neil gave you the pointers in one of his replies, but I suspect you did
> > not understand that Linux raid10 is not limited to the arrangement of
> > traditional raid10, and thus did not see his point.
> >
> > md raid and mdadmin already support a very flexible form of raid10.
> > Unlike traditional raid10 that requires a multiple of 4 disks, Linux
> > raid10 can work with /any/ number of disks greater than 1. There are
> > various layouts that can be used for this - the Wikipedia entry gives
> > some useful diagrams:
> >
> > <http://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10>
> >
> > You can also read about it in the mdadm manual page, and various
> > documents and resources around the web.
> >
> >
> > In your particular case, what you want is to use "--layout raid10,f2" on
> > your two disks. This asks md to split each disk (or the partitions you
> > use) into two parts, without creating any new partitions. The first
> > half of disk 1 is mirrored with the second half of disk 2, and vice
> > versa, then these mirrors are striped. This is very similar to the
> > layout you are trying to achieve, except for four points:
> >
> > The mirrors are crossed-over, so that a first half is mirrored with a
> > second half. This makes no difference on an SSD, but makes a huge
> > difference on a hard disk.
> >
> > mdadm and md raid get the ordering right every time - there is no need
> > to worry about the ordering of the two disks.
> >
> > You don't have to have extra partitions, automatic detection works, and
> > the layout has one less layer, meaning less complexity and lower latency
> > and overheads.
> >
> > md raid knows more about the layout, and can use it to optimise the speed.
> >
> >
> > In particular, md will (almost) always read from the outer halves of the
> > disks. On a hard disk, this can be twice the speed of the inner layers.
> >
> > Obviously you pay a penalty in writing when you have such an arrangement
> > - writes need to go to both disks, and involve significant head
> > movement. There are other raid10 layouts that have lower streamed read
> > speeds but also lower write latencies (choose the balance you want).
> >
> >
> > With this in mind, I hope you can try out raid10,f2 layout on your
> > system and then change your blog to show how easy this all is with md
> > raid, how practical it is for a fast workstation or desktop, and how
> > much faster such a setup is than anything that can be achieved with
> > hardware raid cards or anything other than md raid.
> >
> > mvh.,
> >
> > David
> >
> --
> 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: Raid 1 vs Raid 10 single thread performance
From: Bostjan Skufca @ 2014-09-16 7:48 UTC (permalink / raw)
To: David Brown; +Cc: linux-raid
In-Reply-To: <5412B38E.5040205@hesbynett.no>
David and Neil, thanks for hints!
(I was busy with other things lately, but believe it or not I got the
"why not try raid 10 with only 2 partitions" idea just last night,
tested it a couple of minutes ago with fascination, and now here I am
reading your emails - please do not remind me again of time wasted :)
The write performance is curious though:
- f2: 147 MB/s
- n2: 162 MB/s
I was expecting greater difference (bu I must admit this was not
tested on the whole 3TB disk, just 400GB partition on it).
b.
On 12 September 2014 10:49, David Brown <david.brown@hesbynett.no> wrote:
> On 10/09/14 23:24, Bostjan Skufca wrote:
>> Hi,
>>
>> I have a simple question:
>> - Where is the code that is used for actual RAID 10 creation? In
>> kernel or in mdadm?
>>
>>
>> Explanation:
>>
>> I was dissatisfied with single-threaded RAID 1 sequential read
>> performance (basically boils down to the speed of one disk). I figured
>> that instead of using level 1 I could create RAID level 10 and use two
>> equally-sized partitions on each drive (instead of one).
>>
>> It turns out that if array is created properly, it is capable of
>> sequential reads at almost 2x single device speed, as expected (on
>> SSD!) and what would anyone expect from ordinary RAID 1.
>>
>> What does "properly" actually mean?
>> I was doing some benchmarks with various raid configurations and
>> figured out that the order of devices submitted to creation command is
>> significant. It also makes raid10 created in such mode reliable or
>> unreliable to a device failure (not partition failure, device failure,
>> which means that two raid underlying devices fail at once).
>>
>> Sum:
>> - if such array is created properly, it has redundancy in place and
>> performs as expected
>> - if not, it performs as raid1 and fails with one physical disk failure
>>
>> I am trying to find the code responsible for creation of RAID 10 in
>> order to try and make it more inteligent about where to place RAID 10
>> parts if it gets a list of devices to use, and some of those devices
>> are on the same physical disks.
>>
>> Thanks for hints,
>> b.
>>
>>
>>
>> PS: More details about testing is available here, but be warned, it is
>> still a bit hectic to read:
>> http://blog.a2o.si/2014/09/07/linux-software-raid-why-you-should-always-use-raid-10-instead-of-raid-1/
>
>
> Hi,
>
> First let me applaud your enthusiasm for trying to inform people about
> raid in your blog, your interest in investigating different ideas in the
> hope of making md raid faster and/or easier and/or safer.
>
> Then let me tell you your entire blog post is wasted, because md already
> has a solution that is faster, easier and safer than anything you have
> come up with so far.
>
> You are absolutely correct about the single-threaded read performance of
> raid1 pairs - for a number of reasons, a single thread read will get
> reads from only one disk. This is not a problem in many cases, because
> you often have multiple simultaneous reads on "typical" systems with
> raid1. But for some cases, such as a high performance desktop, it can
> be a limitation.
>
> You are also correct that the solution is basically to split the drives
> into two parts, pair up halves from each disk as raid1 mirrors, and
> stripe the two mirrors as raid0.
>
> And you are correct that you have to get the sets right, or you will may
> lose redundancy and/or speed.
>
> Fortunately, Neil and the other md raid developers are way ahead of you.
>
> Neil gave you the pointers in one of his replies, but I suspect you did
> not understand that Linux raid10 is not limited to the arrangement of
> traditional raid10, and thus did not see his point.
>
> md raid and mdadmin already support a very flexible form of raid10.
> Unlike traditional raid10 that requires a multiple of 4 disks, Linux
> raid10 can work with /any/ number of disks greater than 1. There are
> various layouts that can be used for this - the Wikipedia entry gives
> some useful diagrams:
>
> <http://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10>
>
> You can also read about it in the mdadm manual page, and various
> documents and resources around the web.
>
>
> In your particular case, what you want is to use "--layout raid10,f2" on
> your two disks. This asks md to split each disk (or the partitions you
> use) into two parts, without creating any new partitions. The first
> half of disk 1 is mirrored with the second half of disk 2, and vice
> versa, then these mirrors are striped. This is very similar to the
> layout you are trying to achieve, except for four points:
>
> The mirrors are crossed-over, so that a first half is mirrored with a
> second half. This makes no difference on an SSD, but makes a huge
> difference on a hard disk.
>
> mdadm and md raid get the ordering right every time - there is no need
> to worry about the ordering of the two disks.
>
> You don't have to have extra partitions, automatic detection works, and
> the layout has one less layer, meaning less complexity and lower latency
> and overheads.
>
> md raid knows more about the layout, and can use it to optimise the speed.
>
>
> In particular, md will (almost) always read from the outer halves of the
> disks. On a hard disk, this can be twice the speed of the inner layers.
>
> Obviously you pay a penalty in writing when you have such an arrangement
> - writes need to go to both disks, and involve significant head
> movement. There are other raid10 layouts that have lower streamed read
> speeds but also lower write latencies (choose the balance you want).
>
>
> With this in mind, I hope you can try out raid10,f2 layout on your
> system and then change your blog to show how easy this all is with md
> raid, how practical it is for a fast workstation or desktop, and how
> much faster such a setup is than anything that can be achieved with
> hardware raid cards or anything other than md raid.
>
> mvh.,
>
> David
>
^ permalink raw reply
* Re: grub-probe: "found two disks with the index 3 for RAID md2" after changing superblock 0.9 to 1.0
From: Andy Smith @ 2014-09-16 4:00 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20140916075458.155ca17a@notabene.brown>
Hi Neil,
On Tue, Sep 16, 2014 at 07:54:58AM +1000, NeilBrown wrote:
> On Mon, 15 Sep 2014 17:12:52 +0000 Andy Smith <andy@strugglers.net> wrote:
> > On Mon, Sep 15, 2014 at 05:00:37PM +1000, NeilBrown wrote:
> > > mdadm --zero-super --metadata=0.90 /dev/sda3
> > >
> > > will remove any 0.90 metadata.
> >
> > Trying that whole the array is running:
> >
> > mdadm: Couldn't open /dev/sda3 for write - not zeroing
> >
> > This needs to be done with the array stopped, presumably?
>
> It's preferred, but if you are really confident (and I think you are), then
> adding --force is justified and should make it work.
Yep, that worked, thank you! No more complaints from grub-probe.
Do you consider it a bug that mdadm does not zero the old metadata
when upgrading it to a new version?
Or do you consider it a documentation issue to explain that it may
be necessary to manually do it?
I think I would've liked grub-probe at least in verbose mode to say
which version of metadata it was reading from where. That would've
been immediately enlightening, so I'll see if they would accept a
patch for that…
Cheers,
Andy
--
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: grub-probe: "found two disks with the index 3 for RAID md2" after changing superblock 0.9 to 1.0
From: NeilBrown @ 2014-09-15 21:54 UTC (permalink / raw)
To: Andy Smith; +Cc: linux-raid
In-Reply-To: <20140915171252.GI11855@bitfolk.com>
[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]
On Mon, 15 Sep 2014 17:12:52 +0000 Andy Smith <andy@strugglers.net> wrote:
> Hi Neil,
>
> On Mon, Sep 15, 2014 at 05:00:37PM +1000, NeilBrown wrote:
> > On Mon, 15 Sep 2014 06:47:41 +0000 Andy Smith <andy@strugglers.net> wrote:
> > > The thing is, that bug report is quite old and is marked closed, and
> > > also states:
> > >
> > > "The problem is that 0.9x metadata block doesn't have enough
> > > info to check it. With 1.x we have no such problem."
> > >
> > > Of course, it *is* 1.x superblock. Did the poster actually mean to
> > > say that they have no problem with v1.1 and v1.2 (because they are
> > > located at or near the beginning of the device, not at the end)?
> >
> > 0.90 has the problem, 1.x doesn't.
>
> Right.
>
> > Maybe there is an old 0.90 superblock confusing things. It lives in a
> > different location than the others and so there is room for confusion.
>
> I think that must be it.
>
> > mdadm --examine --metadata=0.90 /dev/sda3
> >
> > which show you the 0.90 metadata if there is any.
>
> /dev/sda3:
> Magic : a92b4efc
> Version : 0.90.01
> UUID : 3905b303:ca604b72:be5949c4:ab051b7a
> Creation Time : Sun Jun 4 08:18:58 2006
> Raid Level : raid10
> Used Dev Size : 309363264 (295.03 GiB 316.79 GB)
> Array Size : 928089792 (885.10 GiB 950.36 GB)
> Raid Devices : 6
> Total Devices : 6
> Preferred Minor : 2
>
> Update Time : Sun Aug 24 14:26:50 2014
> State : clean
> Active Devices : 6
> Working Devices : 6
> Failed Devices : 0
> Spare Devices : 0
> Checksum : e613d577 - correct
> Events : 312149996
>
> Layout : near=2
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 5 8 3 5 active sync /dev/sda3
>
> 0 0 8 51 0 active sync /dev/sdd3
> 1 1 8 67 1 active sync
> 2 2 8 83 2 active sync
> 3 3 8 19 3 active sync /dev/sdb3
> 4 4 8 35 4 active sync /dev/sdc3
> 5 5 8 3 5 active sync /dev/sda3
>
> This shows the array when it had 6 devices as well, so clearly from
> before the metadata update and shrink to 4 devices.
>
> > mdadm --zero-super --metadata=0.90 /dev/sda3
> >
> > will remove any 0.90 metadata.
>
> Trying that whole the array is running:
>
> mdadm: Couldn't open /dev/sda3 for write - not zeroing
>
> This needs to be done with the array stopped, presumably?
It's preferred, but if you are really confident (and I think you are), then
adding --force is justified and should make it work.
NeilBrown
>
> Thanks for the explanation!
>
> Cheers,
> Andy
> --
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: grub-probe: "found two disks with the index 3 for RAID md2" after changing superblock 0.9 to 1.0
From: Andy Smith @ 2014-09-15 17:12 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20140915170037.16f93daa@notabene.brown>
Hi Neil,
On Mon, Sep 15, 2014 at 05:00:37PM +1000, NeilBrown wrote:
> On Mon, 15 Sep 2014 06:47:41 +0000 Andy Smith <andy@strugglers.net> wrote:
> > The thing is, that bug report is quite old and is marked closed, and
> > also states:
> >
> > "The problem is that 0.9x metadata block doesn't have enough
> > info to check it. With 1.x we have no such problem."
> >
> > Of course, it *is* 1.x superblock. Did the poster actually mean to
> > say that they have no problem with v1.1 and v1.2 (because they are
> > located at or near the beginning of the device, not at the end)?
>
> 0.90 has the problem, 1.x doesn't.
Right.
> Maybe there is an old 0.90 superblock confusing things. It lives in a
> different location than the others and so there is room for confusion.
I think that must be it.
> mdadm --examine --metadata=0.90 /dev/sda3
>
> which show you the 0.90 metadata if there is any.
/dev/sda3:
Magic : a92b4efc
Version : 0.90.01
UUID : 3905b303:ca604b72:be5949c4:ab051b7a
Creation Time : Sun Jun 4 08:18:58 2006
Raid Level : raid10
Used Dev Size : 309363264 (295.03 GiB 316.79 GB)
Array Size : 928089792 (885.10 GiB 950.36 GB)
Raid Devices : 6
Total Devices : 6
Preferred Minor : 2
Update Time : Sun Aug 24 14:26:50 2014
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
Checksum : e613d577 - correct
Events : 312149996
Layout : near=2
Chunk Size : 64K
Number Major Minor RaidDevice State
this 5 8 3 5 active sync /dev/sda3
0 0 8 51 0 active sync /dev/sdd3
1 1 8 67 1 active sync
2 2 8 83 2 active sync
3 3 8 19 3 active sync /dev/sdb3
4 4 8 35 4 active sync /dev/sdc3
5 5 8 3 5 active sync /dev/sda3
This shows the array when it had 6 devices as well, so clearly from
before the metadata update and shrink to 4 devices.
> mdadm --zero-super --metadata=0.90 /dev/sda3
>
> will remove any 0.90 metadata.
Trying that whole the array is running:
mdadm: Couldn't open /dev/sda3 for write - not zeroing
This needs to be done with the array stopped, presumably?
Thanks for the explanation!
Cheers,
Andy
^ permalink raw reply
* read error recovery threshold
From: Eric Mei @ 2014-09-15 16:56 UTC (permalink / raw)
To: linux-raid
Hi,
After a read error detected, RAID6 will initiate a recovery procedure
try to correct it, until the number of read error exceeds a threshold,
which is "conf->max_nr_stripes" (see raid5_end_read_request()), I'm
wondering the reasoning behind this. To me the threshold seems a drive
property, but max_nr_stripes is a array-wide cache setting and can be
changed at runtime. In our specific case, we observed a drive emitting
lots of read errors without being marked as faulty because the larger
max_nr_stripes
setting.
Look at other part of MD code, there is "mddev::max_corr_read_errors"
which is set to 20, but only RAID10 makes use of it. Also the comment
above MD_DEFAULT_MAX_CORRECTED_READ_ERRORS says "...We divide the read
error count by 2 for every hour elapsed between read errors", but I
don't see any code matching this description.
Any thoughts? Thanks
Eric
^ permalink raw reply
* Re: [PATCH v3 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
From: Behan Webster @ 2014-09-15 14:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alasdair G Kergon, Chris Mason, David Miller, dm-devel@redhat.com,
Fabian Frederick, Herbert Xu, Josef Bacik, Mike Snitzer,
tadeusz.struk, Andrew Morton, Bruce Allan, Dmitry Kasatkin,
James Morris, john.griffin, linux-btrfs,
Linux Crypto Mailing List, linux-ima-devel, linux-ima-user,
Linux Kernel Mailing List, linux-raid@vger.kernel.org, LSM List,
Neil Brown, qat-lin
In-Reply-To: <CA+55aFx8FN2Rq+d3v9rsDbTyX3hwm6TvudvZrL5wgf7fX3aQjA@mail.gmail.com>
On 09/15/14 07:21, Linus Torvalds wrote:
> On Mon, Sep 15, 2014 at 12:30 AM, <behanw@converseincode.com> wrote:
>> From: Behan Webster <behanw@converseincode.com>
>>
>> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
>> compliant equivalent. This patch allocates the appropriate amount of memory
>> using a char array using the SHASH_DESC_ON_STACK macro.
> You only made the first case use SHASH_DESC_ON_STACK, the two other
> cases you left in the ugly format. Was that just an oversight, or was
> there some reason for it?
>
Oversight. Will Fix.
Behan
--
Behan Webster
behanw@converseincode.com
^ permalink raw reply
* Re: [PATCH v3 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
From: Linus Torvalds @ 2014-09-15 14:21 UTC (permalink / raw)
To: Behan Webster
Cc: Alasdair G Kergon, Chris Mason, David Miller, dm-devel@redhat.com,
Fabian Frederick, Herbert Xu, Josef Bacik, Mike Snitzer,
tadeusz.struk, Andrew Morton, Bruce Allan, Dmitry Kasatkin,
James Morris, john.griffin, linux-btrfs,
Linux Crypto Mailing List, linux-ima-devel, linux-ima-user,
Linux Kernel Mailing List, linux-raid@vger.kernel.org, LSM List,
Neil Brown, qat-lin
In-Reply-To: <1410766234-1634-12-git-send-email-behanw@converseincode.com>
On Mon, Sep 15, 2014 at 12:30 AM, <behanw@converseincode.com> wrote:
> From: Behan Webster <behanw@converseincode.com>
>
> Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
> compliant equivalent. This patch allocates the appropriate amount of memory
> using a char array using the SHASH_DESC_ON_STACK macro.
You only made the first case use SHASH_DESC_ON_STACK, the two other
cases you left in the ugly format. Was that just an oversight, or was
there some reason for it?
Linus
^ permalink raw reply
* Re: dmadm question
From: Luke Odom @ 2014-09-15 14:07 UTC (permalink / raw)
To: NeilBrown; +Cc: Luke Odom, linux-raid
In-Reply-To: <20140915103154.59bc7293@notabene.brown>
Drive is exact same model as old one. Output of requested commands:
# mdadm --manage /dev/md127 --remove /dev/sdb
mdadm: hot removed /dev/sdb from /dev/md127
# mdadm --zero /dev/sdb
# mdadm --manage /dev/md127 --add /dev/sdb
mdadm: added /dev/sdb
# ps aux | grep mdmon
root 1937 0.0 0.1 10492 10484 ? SLsl 14:04 0:00 mdmon md127
root 2055 0.0 0.0 2420 928 pts/0 S+ 14:06 0:00 grep mdmon
md: unbind<sdb>
md: export_rdev(sdb)
md: bind<sdb>
On Sun, September 14, 2014 5:31 pm, NeilBrown wrote:
> On 12 Sep 2014 18:49:54 -0700 Luke Odom <luke@lukeodom.com> wrote:
>
>> I had a raid1 subarray running within an imsm container. One of the
>> drives died so I replaced it. I can get the new drive into the imsm
>> container but I can’t add it to the raid1 array within that
>> container. I’ve read the man page and can’t see to figure it out.
>> Any help would be greatly appreciated. Using mdadm 3.2.5 on debian
>> squeeze.Â
>
> This should just happen automatically. As soon as you add the device to
> the
> container, mdmon notices and adds it to the raid1.
>
> However it appears not to have happened...
>
> I assume the new drive is exactly the same size as the old drive?
> Try removing the new device from md127, run "mdadm --zero" on it, then add
> it
> back again.
> Do any messages appear in the kernel logs when you do that?
>
> Is "mdmon md127" running?
>
> NeilBrown
>
>
>>
>>
>>
>>
>> root@ds6790:~# cat /proc/mdstat
>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>> md126 : active raid1 sda[0]
>> Â Â Â 976759808 blocks super external:/md127/0 [2/1] [U_]
>>
>>
>>
>>
>> md127 : inactive sdb[0](S) sda[1](S)
>> Â Â Â 4901 blocks super external:imsm
>>
>>
>>
>>
>> unused devices: <none>
>>
>>
>>
>>
>>
>>
>> root@ds6790:~# mdadm --detail /dev/md126
>> /dev/md126:
>> Â Â Â Container : /dev/md127, member 0
>> Â Â Â Raid Level : raid1
>> Â Â Â Array Size : 976759808 (931.51 GiB 1000.20 GB)
>> Â Used Dev Size : 976759940 (931.51 GiB 1000.20 GB)
>> Â Â Raid Devices : 2
>> Â Total Devices : 1
>>
>>
>>
>>
>> Â Â Â Â Â State : active, degradedÂ
>> Â Active Devices : 1
>> Working Devices : 1
>> Â Failed Devices : 0
>> Â Spare Devices : 0
>>
>>
>>
>>
>>
>>
>>
>>
>> Â Â Â Â Â Â UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>>   Number  Major  Minor  RaidDevice State
>> Â Â Â Â 0 Â Â Â 8 Â Â Â Â 0 Â Â Â Â 0 Â Â Â active sync Â
>> /dev/sda
>> Â Â Â Â 1 Â Â Â 0 Â Â Â Â 0 Â Â Â Â 1 Â Â Â removed
>>
>>
>>
>>
>>
>>
>> root@ds6790:~# mdadm --examine /dev/md127
>> /dev/md127:
>> Â Â Â Â Â Magic : Intel Raid ISM Cfg Sig.
>> Â Â Â Â Version : 1.1.00
>> Â Â Orig Family : 6e37aa48
>> Â Â Â Â Â Family : 6e37aa48
>> Â Â Â Generation : 00640a43
>> Â Â Â Attributes : All supported
>> Â Â Â Â Â Â UUID : ac27ba68:f8a3618d:3810d44f:25031c07
>> Â Â Â Â Checksum : 513ef1f6 correct
>> Â Â MPB Sectors : 1
>> Â Â Â Â Â Disks : 2
>> Â Â RAID Devices : 1
>>
>>
>>
>>
>> Â Disk00 Serial : 9XG3RTL0
>> Â Â Â Â Â State : active
>> Â Â Â Â Â Â Â Id : 00000002
>> Â Â Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>
>>
>>
>>
>> [Volume0]:
>> Â Â Â Â Â Â UUID : 1be60edf:5c16b945:86434b6b:2714fddb
>> Â Â Â RAID Level : 1
>> Â Â Â Â Members : 2
>> Â Â Â Â Â Slots : [U_]
>> Â Â Failed disk : 1
>> Â Â Â This Slot : 0
>> Â Â Â Array Size : 1953519616 (931.51 GiB 1000.20 GB)
>> Â Â Per Dev Size : 1953519880 (931.51 GiB 1000.20 GB)
>> Â Sector Offset : 0
>> Â Â Num Stripes : 7630936
>> Â Â Â Chunk Size : 64 KiB
>> Â Â Â Â Reserved : 0
>> Â Migrate State : idle
>> Â Â Â Map State : degraded
>> Â Â Dirty State : dirty
>>
>>
>>
>>
>> Â Disk01 Serial : XG3RWMF
>> Â Â Â Â Â State : failed
>> Â Â Â Â Â Â Â Id : ffffffff
>> Â Â Usable Size : 1953519880 (931.51 GiB 1000.20 GB)
>>
>>
>>
>>
>>
>
>
--
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: frequent disk activity with mdadm-3.3
From: Marco Schindler @ 2014-09-15 10:52 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <20140915101830.3c85d423@notabene.brown>
On 15.09.2014, at 02:18, NeilBrown <neilb@suse.de> wrote:
> It would help to get "udevadm monitor" info to correlate with this.
> Presumably some uevent is generated when the spindown happens. udev might
> respond to this by reading from the device, which defeats the purpose...
>
>
>>
>> here’s the output of blktrace -d /dev/sda during that time.
>> https://dl.dropboxusercontent.com/u/3464720/blktrace.tar.bz2
>
> That suggest that something is reading the metadata from the device almost
> constantly. Mostly a 'kworker' thread. I don't know what would cause that.
>
> Let's look at the 'udevadm monitor' trace first and see what that shows.
here’s the output of udevadm monitor during the spindown cycle while mdadm-3.3 is installed.
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[299719.336261] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb (block)
UDEV [299720.646760] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb (block)
KERNEL[299780.202901] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:0/end_device-0:0/target0:0:0/0:0:0:0/block/sda (block)
UDEV [299781.567308] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:0/end_device-0:0/target0:0:0/0:0:0:0/block/sda (block)
KERNEL[299841.090818] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb (block)
UDEV [299842.407035] change /devices/pci0000:00/0000:00:06.0/0000:09:00.0/host0/port-0:1/end_device-0:1/target0:0:1/0:0:1:0/block/sdb (block)
please note that the issue immediately disappears when downgrading to mdadm-3.2 without touching anything else.
I see the udev rules have been updated in mdadm-3.3..
--
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: [dm-devel] [PATCH v3 01/12] crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code
From: Behan Webster @ 2014-09-15 8:37 UTC (permalink / raw)
To: Michał Mirosław, device-mapper development
Cc: agk, clm, David Miller, fabf, Herbert Xu, jbacik, snitzer,
tadeusz.struk, thomas.lendacky, linux-ima-user, qat-linux,
d.kasatkin, Bruce Allan, Linux Kernel, john.griffin, linux-raid,
linux-security-module, linux-crypto, james.l.morris,
Linus Torvalds, linux-ima-devel, Andrew Morton, zohar,
linux-btrfs, Serge E. Hallyn
In-Reply-To: <CAHXqBFK=o2Q3CUPWaL_8TDBJbGjfEOx_HnQzooy33wuKWyu5Gw@mail.gmail.com>
On 09/15/14 01:06, Michał Mirosław wrote:
> 2014-09-15 9:30 GMT+02:00 <behanw@converseincode.com>:
> [...]
>> +#define SHASH_DESC_ON_STACK(shash, tfm) \
>> + char __desc[sizeof(struct shash_desc) + \
>> + crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR; \
>> + struct shash_desc *shash = (struct shash_desc *)__desc
>> +
> char shash##__desc[] or similar? Otherwise it won't work if you use
> this macro twice in the same block.
>
> Best Regards,
> Michał Mirosław
Good thinking. Will fix.
Behan
--
Behan Webster
behanw@converseincode.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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: [dm-devel] [PATCH v3 01/12] crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code
From: Michał Mirosław @ 2014-09-15 8:06 UTC (permalink / raw)
To: device-mapper development
Cc: agk, clm, David Miller, fabf, Herbert Xu, jbacik, snitzer,
tadeusz.struk, thomas.lendacky, linux-ima-user, qat-linux,
d.kasatkin, Bruce Allan, Linux Kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, Linus Torvalds, linux-ima-devel, Andrew Morton,
zohar, linux-btrfs, Serge E. Hallyn
In-Reply-To: <1410766234-1634-2-git-send-email-behanw@converseincode.com>
2014-09-15 9:30 GMT+02:00 <behanw@converseincode.com>:
[...]
> +#define SHASH_DESC_ON_STACK(shash, tfm) \
> + char __desc[sizeof(struct shash_desc) + \
> + crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR; \
> + struct shash_desc *shash = (struct shash_desc *)__desc
> +
char shash##__desc[] or similar? Otherwise it won't work if you use
this macro twice in the same block.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: Speeding up reading with RAID1 and --write-mostly
From: martin f krafft @ 2014-09-15 7:44 UTC (permalink / raw)
To: Roberto Spadim, NeilBrown; +Cc: linux-raid@vger.kernel.org
In-Reply-To: <CAH3kUhGEaon77fpNm2mjRwPbNMZe9BLK3eA6LTB4xQeg0hMF-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
also sprach Roberto Spadim <roberto@spadim.com.br> [2014-09-13 13:56 +0200]:
> Try a bcache or something like it
also sprach NeilBrown <neilb@suse.de> [2014-09-15 06:11 +0200]:
> It is a persistent cache though.
Oh cool, and it optimises writing too, I'll definitely will check it
out, thank you!
> But I suspect you will find that SD cards aren't really fast
> enough for your needs. It wouldn't hurt to experiment on just an
> SD card and see how it performs.
Sure, and this will be much easier to set up. However, even my cheap
camera SD outperforms my rotational disk, especially with dmcrypt…
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
an egg has the shortest sex-life of all: if gets laid once; it gets
eaten once. it also has to come in a box with 11 others, and the
only person who will sit on its face is its mother.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1107 bytes --]
^ permalink raw reply
* [PATCH v3 12/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: pageexec@freemail.hu
---
crypto/testmgr.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ac2b631..b959c0c 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1714,16 +1714,14 @@ static int alg_test_crc32c(const struct alg_test_desc *desc,
}
do {
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(shash, tfm);
+ u32 *ctx = (u32 *)shash_desc_ctx(shash);
- sdesc.shash.tfm = tfm;
- sdesc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
- *(u32 *)sdesc.ctx = le32_to_cpu(420553207);
- err = crypto_shash_final(&sdesc.shash, (u8 *)&val);
+ *ctx = le32_to_cpu(420553207);
+ err = crypto_shash_final(shash, (u8 *)&val);
if (err) {
printk(KERN_ERR "alg: crc32c: Operation failed for "
"%s: %d\n", driver, err);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" 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 related
* [PATCH v3 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster, tglx
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Cc: tglx@linutronix.de
---
security/integrity/ima/ima_crypto.c | 51 +++++++++++++++++--------------------
1 file changed, 23 insertions(+), 28 deletions(-)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index 0bd7328..bb55737 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -380,17 +380,14 @@ static int ima_calc_file_hash_tfm(struct file *file,
loff_t i_size, offset = 0;
char *rbuf;
int rc, read = 0;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
hash->length = crypto_shash_digestsize(tfm);
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -420,7 +417,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
break;
offset += rbuf_len;
- rc = crypto_shash_update(&desc.shash, rbuf, rbuf_len);
+ rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
}
@@ -429,7 +426,7 @@ static int ima_calc_file_hash_tfm(struct file *file,
kfree(rbuf);
out:
if (!rc)
- rc = crypto_shash_final(&desc.shash, hash->digest);
+ rc = crypto_shash_final(shash, hash->digest);
return rc;
}
@@ -487,18 +484,17 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
struct ima_digest_data *hash,
struct crypto_shash *tfm)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ char desc[sizeof(struct shash_desc) +
+ crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR;
+ struct shash_desc *shash = (struct shash_desc *)desc;
int rc, i;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
hash->length = crypto_shash_digestsize(tfm);
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -508,7 +504,7 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
u32 datalen = field_data[i].len;
if (strcmp(td->name, IMA_TEMPLATE_IMA_NAME) != 0) {
- rc = crypto_shash_update(&desc.shash,
+ rc = crypto_shash_update(shash,
(const u8 *) &field_data[i].len,
sizeof(field_data[i].len));
if (rc)
@@ -518,13 +514,13 @@ static int ima_calc_field_array_hash_tfm(struct ima_field_data *field_data,
data_to_hash = buffer;
datalen = IMA_EVENT_NAME_LEN_MAX + 1;
}
- rc = crypto_shash_update(&desc.shash, data_to_hash, datalen);
+ rc = crypto_shash_update(shash, data_to_hash, datalen);
if (rc)
break;
}
if (!rc)
- rc = crypto_shash_final(&desc.shash, hash->digest);
+ rc = crypto_shash_final(shash, hash->digest);
return rc;
}
@@ -565,15 +561,14 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
{
u8 pcr_i[TPM_DIGEST_SIZE];
int rc, i;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ char desc[sizeof(struct shash_desc) +
+ crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR;
+ struct shash_desc *shash = (struct shash_desc *)desc;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
+ shash->tfm = tfm;
+ shash->flags = 0;
- rc = crypto_shash_init(&desc.shash);
+ rc = crypto_shash_init(shash);
if (rc != 0)
return rc;
@@ -581,10 +576,10 @@ static int __init ima_calc_boot_aggregate_tfm(char *digest,
for (i = TPM_PCR0; i < TPM_PCR8; i++) {
ima_pcrread(i, pcr_i);
/* now accumulate with current aggregate */
- rc = crypto_shash_update(&desc.shash, pcr_i, TPM_DIGEST_SIZE);
+ rc = crypto_shash_update(shash, pcr_i, TPM_DIGEST_SIZE);
}
if (!rc)
- crypto_shash_final(&desc.shash, digest);
+ crypto_shash_final(shash, digest);
return rc;
}
--
1.9.1
--
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 related
* [PATCH v3 10/12] crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: pageexec@freemail.hu
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
lib/libcrc32c.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/lib/libcrc32c.c b/lib/libcrc32c.c
index b3131f5..6a08ce7 100644
--- a/lib/libcrc32c.c
+++ b/lib/libcrc32c.c
@@ -41,20 +41,18 @@ static struct crypto_shash *tfm;
u32 crc32c(u32 crc, const void *address, unsigned int length)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
+ u32 *ctx = (u32 *)shash_desc_ctx(shash);
int err;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
- *(u32 *)desc.ctx = crc;
+ shash->tfm = tfm;
+ shash->flags = 0;
+ *ctx = crc;
- err = crypto_shash_update(&desc.shash, address, length);
+ err = crypto_shash_update(shash, address, length);
BUG_ON(err);
- return *(u32 *)desc.ctx;
+ return *ctx;
}
EXPORT_SYMBOL(crc32c);
--
1.9.1
^ permalink raw reply related
* [PATCH v3 09/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: pageexec@freemail.hu
---
crypto/hmac.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/crypto/hmac.c b/crypto/hmac.c
index 8d9544c..e392219 100644
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -52,20 +52,17 @@ static int hmac_setkey(struct crypto_shash *parent,
struct hmac_ctx *ctx = align_ptr(opad + ss,
crypto_tfm_ctx_alignment());
struct crypto_shash *hash = ctx->hash;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(hash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, hash);
unsigned int i;
- desc.shash.tfm = hash;
- desc.shash.flags = crypto_shash_get_flags(parent) &
- CRYPTO_TFM_REQ_MAY_SLEEP;
+ shash->tfm = hash;
+ shash->flags = crypto_shash_get_flags(parent)
+ & CRYPTO_TFM_REQ_MAY_SLEEP;
if (keylen > bs) {
int err;
- err = crypto_shash_digest(&desc.shash, inkey, keylen, ipad);
+ err = crypto_shash_digest(shash, inkey, keylen, ipad);
if (err)
return err;
@@ -81,12 +78,12 @@ static int hmac_setkey(struct crypto_shash *parent,
opad[i] ^= 0x5c;
}
- return crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, ipad, bs) ?:
- crypto_shash_export(&desc.shash, ipad) ?:
- crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, opad, bs) ?:
- crypto_shash_export(&desc.shash, opad);
+ return crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, ipad, bs) ?:
+ crypto_shash_export(shash, ipad) ?:
+ crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, opad, bs) ?:
+ crypto_shash_export(shash, opad);
}
static int hmac_export(struct shash_desc *pdesc, void *out)
--
1.9.1
^ permalink raw reply related
* [PATCH v3 08/12] crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Jan-Simon Möller,
Behan Webster, pageexec, gmazyland
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: pageexec@freemail.hu
Cc: gmazyland@gmail.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/md/dm-crypt.c | 34 ++++++++++++++--------------------
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index cd15e08..fc93b93 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -526,29 +526,26 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8 *iv,
u8 *data)
{
struct iv_lmk_private *lmk = &cc->iv_gen_private.lmk;
- struct {
- struct shash_desc desc;
- char ctx[crypto_shash_descsize(lmk->hash_tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(desc, lmk->hash_tfm);
struct md5_state md5state;
__le32 buf[4];
int i, r;
- sdesc.desc.tfm = lmk->hash_tfm;
- sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ desc->tfm = lmk->hash_tfm;
+ desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
- r = crypto_shash_init(&sdesc.desc);
+ r = crypto_shash_init(desc);
if (r)
return r;
if (lmk->seed) {
- r = crypto_shash_update(&sdesc.desc, lmk->seed, LMK_SEED_SIZE);
+ r = crypto_shash_update(desc, lmk->seed, LMK_SEED_SIZE);
if (r)
return r;
}
/* Sector is always 512B, block size 16, add data of blocks 1-31 */
- r = crypto_shash_update(&sdesc.desc, data + 16, 16 * 31);
+ r = crypto_shash_update(desc, data + 16, 16 * 31);
if (r)
return r;
@@ -557,12 +554,12 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8 *iv,
buf[1] = cpu_to_le32((((u64)dmreq->iv_sector >> 32) & 0x00FFFFFF) | 0x80000000);
buf[2] = cpu_to_le32(4024);
buf[3] = 0;
- r = crypto_shash_update(&sdesc.desc, (u8 *)buf, sizeof(buf));
+ r = crypto_shash_update(desc, (u8 *)buf, sizeof(buf));
if (r)
return r;
/* No MD5 padding here */
- r = crypto_shash_export(&sdesc.desc, &md5state);
+ r = crypto_shash_export(desc, &md5state);
if (r)
return r;
@@ -679,10 +676,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
struct iv_tcw_private *tcw = &cc->iv_gen_private.tcw;
u64 sector = cpu_to_le64((u64)dmreq->iv_sector);
u8 buf[TCW_WHITENING_SIZE];
- struct {
- struct shash_desc desc;
- char ctx[crypto_shash_descsize(tcw->crc32_tfm)];
- } sdesc;
+ SHASH_DESC_ON_STACK(desc, tcw->crc32_tfm);
int i, r;
/* xor whitening with sector number */
@@ -691,16 +685,16 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc,
crypto_xor(&buf[8], (u8 *)§or, 8);
/* calculate crc32 for every 32bit part and xor it */
- sdesc.desc.tfm = tcw->crc32_tfm;
- sdesc.desc.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ desc->tfm = tcw->crc32_tfm;
+ desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
for (i = 0; i < 4; i++) {
- r = crypto_shash_init(&sdesc.desc);
+ r = crypto_shash_init(desc);
if (r)
goto out;
- r = crypto_shash_update(&sdesc.desc, &buf[i * 4], 4);
+ r = crypto_shash_update(desc, &buf[i * 4], 4);
if (r)
goto out;
- r = crypto_shash_final(&sdesc.desc, &buf[i * 4]);
+ r = crypto_shash_final(desc, &buf[i * 4]);
if (r)
goto out;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v3 07/12] crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
---
drivers/crypto/qat/qat_common/qat_algs.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c b/drivers/crypto/qat/qat_common/qat_algs.c
index 59df488..9cabadd 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -152,10 +152,7 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
const uint8_t *auth_key,
unsigned int auth_keylen, uint8_t *auth_state)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(ctx->hash_tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, ctx->hash_tfm);
struct sha1_state sha1;
struct sha256_state sha256;
struct sha512_state sha512;
@@ -167,12 +164,12 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
__be64 *hash512_state_out;
int i, offset;
- desc.shash.tfm = ctx->hash_tfm;
- desc.shash.flags = 0x0;
+ shash->tfm = ctx->hash_tfm;
+ shash->flags = 0x0;
if (auth_keylen > block_size) {
char buff[SHA512_BLOCK_SIZE];
- int ret = crypto_shash_digest(&desc.shash, auth_key,
+ int ret = crypto_shash_digest(shash, auth_key,
auth_keylen, buff);
if (ret)
return ret;
@@ -195,10 +192,10 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
*opad_ptr ^= 0x5C;
}
- if (crypto_shash_init(&desc.shash))
+ if (crypto_shash_init(shash))
return -EFAULT;
- if (crypto_shash_update(&desc.shash, ipad, block_size))
+ if (crypto_shash_update(shash, ipad, block_size))
return -EFAULT;
hash_state_out = (__be32 *)hash->sha.state1;
@@ -206,19 +203,19 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
switch (ctx->qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
- if (crypto_shash_export(&desc.shash, &sha1))
+ if (crypto_shash_export(shash, &sha1))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha1.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
- if (crypto_shash_export(&desc.shash, &sha256))
+ if (crypto_shash_export(shash, &sha256))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha256.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
- if (crypto_shash_export(&desc.shash, &sha512))
+ if (crypto_shash_export(shash, &sha512))
return -EFAULT;
for (i = 0; i < digest_size >> 3; i++, hash512_state_out++)
*hash512_state_out = cpu_to_be64(*(sha512.state + i));
@@ -227,10 +224,10 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
return -EFAULT;
}
- if (crypto_shash_init(&desc.shash))
+ if (crypto_shash_init(shash))
return -EFAULT;
- if (crypto_shash_update(&desc.shash, opad, block_size))
+ if (crypto_shash_update(shash, opad, block_size))
return -EFAULT;
offset = round_up(qat_get_inter_state_size(ctx->qat_hash_alg), 8);
@@ -239,19 +236,19 @@ static int qat_alg_do_precomputes(struct icp_qat_hw_auth_algo_blk *hash,
switch (ctx->qat_hash_alg) {
case ICP_QAT_HW_AUTH_ALGO_SHA1:
- if (crypto_shash_export(&desc.shash, &sha1))
+ if (crypto_shash_export(shash, &sha1))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha1.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA256:
- if (crypto_shash_export(&desc.shash, &sha256))
+ if (crypto_shash_export(shash, &sha256))
return -EFAULT;
for (i = 0; i < digest_size >> 2; i++, hash_state_out++)
*hash_state_out = cpu_to_be32(*(sha256.state + i));
break;
case ICP_QAT_HW_AUTH_ALGO_SHA512:
- if (crypto_shash_export(&desc.shash, &sha512))
+ if (crypto_shash_export(shash, &sha512))
return -EFAULT;
for (i = 0; i < digest_size >> 3; i++, hash512_state_out++)
*hash512_state_out = cpu_to_be64(*(sha512.state + i));
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" 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 related
* [PATCH v3 06/12] crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
---
drivers/crypto/omap-sham.c | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 710d863..24ef489 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -949,17 +949,14 @@ static int omap_sham_finish_hmac(struct ahash_request *req)
struct omap_sham_hmac_ctx *bctx = tctx->base;
int bs = crypto_shash_blocksize(bctx->shash);
int ds = crypto_shash_digestsize(bctx->shash);
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(bctx->shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, bctx->shash);
- desc.shash.tfm = bctx->shash;
- desc.shash.flags = 0; /* not CRYPTO_TFM_REQ_MAY_SLEEP */
+ shash->tfm = bctx->shash;
+ shash->flags = 0; /* not CRYPTO_TFM_REQ_MAY_SLEEP */
- return crypto_shash_init(&desc.shash) ?:
- crypto_shash_update(&desc.shash, bctx->opad, bs) ?:
- crypto_shash_finup(&desc.shash, req->result, ds, req->result);
+ return crypto_shash_init(shash) ?:
+ crypto_shash_update(shash, bctx->opad, bs) ?:
+ crypto_shash_finup(shash, req->result, ds, req->result);
}
static int omap_sham_finish(struct ahash_request *req)
@@ -1118,18 +1115,15 @@ static int omap_sham_update(struct ahash_request *req)
return omap_sham_enqueue(req, OP_UPDATE);
}
-static int omap_sham_shash_digest(struct crypto_shash *shash, u32 flags,
+static int omap_sham_shash_digest(struct crypto_shash *tfm, u32 flags,
const u8 *data, unsigned int len, u8 *out)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
- desc.shash.tfm = shash;
- desc.shash.flags = flags & CRYPTO_TFM_REQ_MAY_SLEEP;
+ shash->tfm = tfm;
+ shash->flags = flags & CRYPTO_TFM_REQ_MAY_SLEEP;
- return crypto_shash_digest(&desc.shash, data, len, out);
+ return crypto_shash_digest(shash, data, len, out);
}
static int omap_sham_final_shash(struct ahash_request *req)
--
1.9.1
^ permalink raw reply related
* [PATCH v3 05/12] crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
---
drivers/crypto/n2_core.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 7263c10..f8e3207 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -445,10 +445,7 @@ static int n2_hmac_async_setkey(struct crypto_ahash *tfm, const u8 *key,
struct n2_hmac_ctx *ctx = crypto_ahash_ctx(tfm);
struct crypto_shash *child_shash = ctx->child_shash;
struct crypto_ahash *fallback_tfm;
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(child_shash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, child_shash);
int err, bs, ds;
fallback_tfm = ctx->base.fallback_tfm;
@@ -456,15 +453,15 @@ static int n2_hmac_async_setkey(struct crypto_ahash *tfm, const u8 *key,
if (err)
return err;
- desc.shash.tfm = child_shash;
- desc.shash.flags = crypto_ahash_get_flags(tfm) &
+ shash->tfm = child_shash;
+ shash->flags = crypto_ahash_get_flags(tfm) &
CRYPTO_TFM_REQ_MAY_SLEEP;
bs = crypto_shash_blocksize(child_shash);
ds = crypto_shash_digestsize(child_shash);
BUG_ON(ds > N2_HASH_KEY_MAX);
if (keylen > bs) {
- err = crypto_shash_digest(&desc.shash, key, keylen,
+ err = crypto_shash_digest(shash, key, keylen,
ctx->hash_key);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH v3 04/12] crypto: LLVMLinux: Remove VLAIS from crypto/mv_cesa.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: akpm, bruce.w.allan, d.kasatkin, james.l.morris, john.griffin,
linux-btrfs, linux-crypto, linux-ima-devel, linux-ima-user,
linux-kernel, linux-raid, linux-security-module, neilb, qat-linux,
serge, thomas.lendacky, zohar, torvalds, Behan Webster
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Behan Webster <behanw@converseincode.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
---
drivers/crypto/mv_cesa.c | 41 ++++++++++++++++++-----------------------
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index 29d0ee5..032c72c 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -402,26 +402,23 @@ static int mv_hash_final_fallback(struct ahash_request *req)
{
const struct mv_tfm_hash_ctx *tfm_ctx = crypto_tfm_ctx(req->base.tfm);
struct mv_req_hash_ctx *req_ctx = ahash_request_ctx(req);
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm_ctx->fallback)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm_ctx->fallback);
int rc;
- desc.shash.tfm = tfm_ctx->fallback;
- desc.shash.flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ shash->tfm = tfm_ctx->fallback;
+ shash->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
if (unlikely(req_ctx->first_hash)) {
- crypto_shash_init(&desc.shash);
- crypto_shash_update(&desc.shash, req_ctx->buffer,
+ crypto_shash_init(shash);
+ crypto_shash_update(shash, req_ctx->buffer,
req_ctx->extra_bytes);
} else {
/* only SHA1 for now....
*/
- rc = mv_hash_import_sha1_ctx(req_ctx, &desc.shash);
+ rc = mv_hash_import_sha1_ctx(req_ctx, shash);
if (rc)
goto out;
}
- rc = crypto_shash_final(&desc.shash, req->result);
+ rc = crypto_shash_final(shash, req->result);
out:
return rc;
}
@@ -794,23 +791,21 @@ static int mv_hash_setkey(struct crypto_ahash *tfm, const u8 * key,
ss = crypto_shash_statesize(ctx->base_hash);
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(ctx->base_hash)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, ctx->base_hash);
+
unsigned int i;
char ipad[ss];
char opad[ss];
- desc.shash.tfm = ctx->base_hash;
- desc.shash.flags = crypto_shash_get_flags(ctx->base_hash) &
+ shash->tfm = ctx->base_hash;
+ shash->flags = crypto_shash_get_flags(ctx->base_hash) &
CRYPTO_TFM_REQ_MAY_SLEEP;
if (keylen > bs) {
int err;
err =
- crypto_shash_digest(&desc.shash, key, keylen, ipad);
+ crypto_shash_digest(shash, key, keylen, ipad);
if (err)
return err;
@@ -826,12 +821,12 @@ static int mv_hash_setkey(struct crypto_ahash *tfm, const u8 * key,
opad[i] ^= 0x5c;
}
- rc = crypto_shash_init(&desc.shash) ? :
- crypto_shash_update(&desc.shash, ipad, bs) ? :
- crypto_shash_export(&desc.shash, ipad) ? :
- crypto_shash_init(&desc.shash) ? :
- crypto_shash_update(&desc.shash, opad, bs) ? :
- crypto_shash_export(&desc.shash, opad);
+ rc = crypto_shash_init(shash) ? :
+ crypto_shash_update(shash, ipad, bs) ? :
+ crypto_shash_export(shash, ipad) ? :
+ crypto_shash_init(shash) ? :
+ crypto_shash_update(shash, opad, bs) ? :
+ crypto_shash_export(shash, opad);
if (rc == 0)
mv_hash_init_ivs(ctx, ipad, opad);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" 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 related
* [PATCH v3 03/12] crypto: LLVMLinux: Remove VLAIS from crypto/ccp/ccp-crypto-sha.c
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, Jan-Simon Möller, linux-ima-user, qat-linux,
d.kasatkin, bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Behan Webster, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, akpm, zohar,
linux-btrfs, serge
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Jan-Simon Möller <dl9pf@gmx.de>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Behan Webster <behanw@converseincode.com>
---
drivers/crypto/ccp/ccp-crypto-sha.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c b/drivers/crypto/ccp/ccp-crypto-sha.c
index 873f234..9653157 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -198,10 +198,9 @@ static int ccp_sha_setkey(struct crypto_ahash *tfm, const u8 *key,
{
struct ccp_ctx *ctx = crypto_tfm_ctx(crypto_ahash_tfm(tfm));
struct crypto_shash *shash = ctx->u.sha.hmac_tfm;
- struct {
- struct shash_desc sdesc;
- char ctx[crypto_shash_descsize(shash)];
- } desc;
+
+ SHASH_DESC_ON_STACK(sdesc, shash);
+
unsigned int block_size = crypto_shash_blocksize(shash);
unsigned int digest_size = crypto_shash_digestsize(shash);
int i, ret;
@@ -216,11 +215,11 @@ static int ccp_sha_setkey(struct crypto_ahash *tfm, const u8 *key,
if (key_len > block_size) {
/* Must hash the input key */
- desc.sdesc.tfm = shash;
- desc.sdesc.flags = crypto_ahash_get_flags(tfm) &
+ sdesc->tfm = shash;
+ sdesc->flags = crypto_ahash_get_flags(tfm) &
CRYPTO_TFM_REQ_MAY_SLEEP;
- ret = crypto_shash_digest(&desc.sdesc, key, key_len,
+ ret = crypto_shash_digest(sdesc, key, key_len,
ctx->u.sha.key);
if (ret) {
crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply related
* [PATCH v3 02/12] btrfs: LLVMLinux: Remove VLAIS
From: behanw @ 2014-09-15 7:30 UTC (permalink / raw)
To: agk, clm, davem, dm-devel, fabf, herbert, jbacik, snitzer,
tadeusz.struk
Cc: thomas.lendacky, linux-ima-user, qat-linux, d.kasatkin,
bruce.w.allan, linux-kernel, john.griffin, linux-raid,
linux-security-module, Vinícius Tinti, linux-crypto,
james.l.morris, torvalds, linux-ima-devel, Behan Webster, akpm,
zohar, linux-btrfs, serge
In-Reply-To: <1410766234-1634-1-git-send-email-behanw@converseincode.com>
From: Vinícius Tinti <viniciustinti@gmail.com>
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.
struct {
struct shash_desc shash;
char ctx[crypto_shash_descsize(tfm)];
} desc;
This patch instead allocates the appropriate amount of memory using a
char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
fs/btrfs/hash.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/hash.c b/fs/btrfs/hash.c
index 85889aa..4bf4d3a 100644
--- a/fs/btrfs/hash.c
+++ b/fs/btrfs/hash.c
@@ -33,18 +33,16 @@ void btrfs_hash_exit(void)
u32 btrfs_crc32c(u32 crc, const void *address, unsigned int length)
{
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ SHASH_DESC_ON_STACK(shash, tfm);
+ u32 *ctx = (u32 *)shash_desc_ctx(shash);
int err;
- desc.shash.tfm = tfm;
- desc.shash.flags = 0;
- *(u32 *)desc.ctx = crc;
+ shash->tfm = tfm;
+ shash->flags = 0;
+ *ctx = crc;
- err = crypto_shash_update(&desc.shash, address, length);
+ err = crypto_shash_update(shash, address, length);
BUG_ON(err);
- return *(u32 *)desc.ctx;
+ return *ctx;
}
--
1.9.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ 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