Bug 993744 - device-mapper: dm-cache fails to allocate memory when setting up mapping
device-mapper: dm-cache fails to allocate memory when setting up mapping
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Heinz Mauelshagen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-06 08:04 EDT by Heinz Mauelshagen
Modified: 2014-02-28 12:28 EST (History)
14 users (show)

See Also:
Fixed In Version: kernel-3.11.4-101.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-13 15:55:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
setup of cache device and kernel trace (8.54 KB, text/plain)
2013-08-06 08:04 EDT, Heinz Mauelshagen
no flags Details
Proposed fix (1012 bytes, patch)
2013-08-07 07:31 EDT, Heinz Mauelshagen
heinzm: review+
Details | Diff

  None (edit)
Description Heinz Mauelshagen 2013-08-06 08:04:04 EDT
Created attachment 783292 [details]
setup of cache device and kernel trace

Description of problem:
Creation of a 10TB cached device with 2048 sector block size and 411GB cache size.

Version-Release number of selected component (if applicable):
Kernel 3.10.4

How reproducible:
Always

Steps to Reproduce:
1. setup cache in description with "dmsetup create"
2.
3.

Actual results:
Fails with evidence in attachment

Expected results:
Succeeds

Additional info:
Comment 1 Heinz Mauelshagen 2013-08-06 08:06:22 EDT
Metadata device size is 32MB.
Comment 2 Heinz Mauelshagen 2013-08-07 07:26:43 EDT
Reproducer with a 10T sparse logical volume cached:

# lvs --noheadings tst/metadata tst/data_ssd vg_a4/sparse10t 
  data_ssd  tst   -wi-a---- 135.00g                                                        
  metadata  tst   -wi-a---- 400.00m                                                        
  sparse10t vg_a4 swi-a-s--   1.00g      [sparse10t_vorigin]  37.62                        
[root@a4 linux]# blockdev --getsz  /dev/tst/metadata /dev/tst/data_ssd /dev/vg_a4/sparse10t
819200
283115520
21474836480

[root@a4 linux]# dmsetup create cache --table "0 $(blockdev --getsize /dev/vg_a4/sparse10t) cache /dev/tst/metadata /dev/tst/data_ssd /dev/vg_a4/sparse10t 128 0 mq 0"

-> fails
Comment 3 Heinz Mauelshagen 2013-08-07 07:31:02 EDT
Created attachment 783835 [details]
Proposed fix

the mq policy module allocated a block with kzalloc instead of vzalloc and hit maximum possible allocation. We need to lower memory consumption of that policy...
Comment 4 Josh Boyer 2013-09-18 16:53:47 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 5 Josh Boyer 2013-10-08 14:06:42 EDT
The patch seems reasonable to me.  Has it been sent upstream?
Comment 6 Heinz Mauelshagen 2013-10-09 05:06:32 EDT
(In reply to Josh Boyer from comment #5)
> The patch seems reasonable to me.  Has it been sent upstream?

Yes, it went to Joe Thornber, the upstream maintainer back in August at the time of comment #3
Comment 7 Josh Boyer 2013-10-09 08:26:12 EDT
(In reply to Heinz Mauelshagen from comment #6)
> (In reply to Josh Boyer from comment #5)
> > The patch seems reasonable to me.  Has it been sent upstream?
> 
> Yes, it went to Joe Thornber, the upstream maintainer back in August at the
> time of comment #3

Hm, ok.  I don't see it in Linus' tree, the device-mapper tree, or linux-next.  I'm guessing Joe hasn't gotten to it yet?

Anyway, would you like the Fedora maintainers to pick this up now while it's working it's way upstream?
Comment 8 Heinz Mauelshagen 2013-10-09 11:54:40 EDT
(In reply to Josh Boyer from comment #7)
> (In reply to Heinz Mauelshagen from comment #6)
> > (In reply to Josh Boyer from comment #5)
> > > The patch seems reasonable to me.  Has it been sent upstream?
> > 
> > Yes, it went to Joe Thornber, the upstream maintainer back in August at the
> > time of comment #3
> 
> Hm, ok.  I don't see it in Linus' tree, the device-mapper tree, or
> linux-next.  I'm guessing Joe hasn't gotten to it yet?
> 
> Anyway, would you like the Fedora maintainers to pick this up now while it's
> working it's way upstream?

Yes, please.
Comment 9 Josh Boyer 2013-10-10 08:55:30 EDT
Added across the Fedora releases.  Thanks!
Comment 10 Fedora Update System 2013-10-10 13:40:35 EDT
kernel-3.11.4-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.11.4-201.fc19
Comment 11 Fedora Update System 2013-10-10 13:40:56 EDT
kernel-3.11.4-101.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.4-101.fc18
Comment 12 Fedora Update System 2013-10-10 18:33:22 EDT
kernel-3.11.4-301.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.4-301.fc20
Comment 13 Fedora Update System 2013-10-10 22:32:21 EDT
Package kernel-3.11.4-201.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.4-201.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18820/kernel-3.11.4-201.fc19
then log in and leave karma (feedback).
Comment 14 Fedora Update System 2013-10-13 15:55:20 EDT
kernel-3.11.4-301.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2013-10-14 03:10:27 EDT
kernel-3.11.4-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2013-10-14 13:17:23 EDT
kernel-3.11.4-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2013-10-18 15:31:04 EDT
kernel-3.11.4-101.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Josh Boyer 2013-12-17 10:31:13 EST
(In reply to Heinz Mauelshagen from comment #6)
> (In reply to Josh Boyer from comment #5)
> > The patch seems reasonable to me.  Has it been sent upstream?
> 
> Yes, it went to Joe Thornber, the upstream maintainer back in August at the
> time of comment #3

This still doesn't seem to be upstream yet and we're still carrying the patch.  I don't see it queued in the for-next branch of the device-mapper tree on git.kernel.org either.  Did it get replaced by something else?
Comment 19 Mike Snitzer 2013-12-17 10:55:29 EST
(In reply to Josh Boyer from comment #18)
> (In reply to Heinz Mauelshagen from comment #6)
> > (In reply to Josh Boyer from comment #5)
> > > The patch seems reasonable to me.  Has it been sent upstream?
> > 
> > Yes, it went to Joe Thornber, the upstream maintainer back in August at the
> > time of comment #3
> 
> This still doesn't seem to be upstream yet and we're still carrying the
> patch.  I don't see it queued in the for-next branch of the device-mapper
> tree on git.kernel.org either.  Did it get replaced by something else?

No, it never got into Joe's development tree.  As such it got dropped on the floor.  This is why, in general, DM fixes should cc dm-devel@redhat.com

I'll pick it up now and get it staged in linux-next.
Comment 20 Josh Boyer 2013-12-17 11:40:02 EST
Thanks Mike.
Comment 21 Josh Boyer 2014-02-28 09:44:48 EST
(In reply to Mike Snitzer from comment #19)
> (In reply to Josh Boyer from comment #18)
> > (In reply to Heinz Mauelshagen from comment #6)
> > > (In reply to Josh Boyer from comment #5)
> > > > The patch seems reasonable to me.  Has it been sent upstream?
> > > 
> > > Yes, it went to Joe Thornber, the upstream maintainer back in August at the
> > > time of comment #3
> > 
> > This still doesn't seem to be upstream yet and we're still carrying the
> > patch.  I don't see it queued in the for-next branch of the device-mapper
> > tree on git.kernel.org either.  Did it get replaced by something else?
> 
> No, it never got into Joe's development tree.  As such it got dropped on the
> floor.  This is why, in general, DM fixes should cc dm-devel@redhat.com
> 
> I'll pick it up now and get it staged in linux-next.

I still don't see this in linux-next...  we're still carrying it on top of 3.13 and 3.14.  Should we be?
Comment 22 Mike Snitzer 2014-02-28 12:28:47 EST
(In reply to Josh Boyer from comment #21)

> I still don't see this in linux-next...  we're still carrying it on top of
> 3.13 and 3.14.  Should we be?

Ngh, yeah I forgot to pick it up.  It is staged in linux-next now, will likely send to Linus next week:

https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=14f398ca2f26a2ed6236aec54395e0fa06ec8a82

Note You need to log in before you can comment on or make changes to this bug.