Bug 868233
| Summary: | [xfs/md] NULL pointer dereference - xfs_alloc_ioend_bio | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Boris Ranto <branto> |
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED ERRATA | QA Contact: | Boris Ranto <branto> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4 | CC: | bfoster, dchinner, esandeen, jcpunk, Jes.Sorensen, rwheeler |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-2.6.32-337.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-21 06:51:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Boris Ranto
2012-10-19 10:19:53 UTC
Hum, -299 seems to be the first kernel that regressed and there are no fs/xfs changes in there (or fs/ changes for that matter). Looking into it. I was able to reproduce this readily on a VM so I ran a bisect that narrowed in on the following commit (this does not appear to be XFS related):
commit fb0650c2790fc0198540ac92b2cd86326e6bf9de
Author: Mike Snitzer <snitzer>
Date: Fri Aug 3 19:24:03 2012 -0400
[block] do not artificially constrain max_sectors for stacking drivers
Message-id: <1344021906-26216-2-git-send-email-snitzer>
Patchwork-id: 49302
O-Subject: [RHEL6.4 PATCH 01/64] block: do not artificially constrain max_sectors for stacking drivers
Bugzilla: 844968
RH-Acked-by: Alasdair Kergon <agk>
BZ: 844968
Thanks Brian, I landed at the same commit almost simultaneously ;) It looks like MD's faulty.c isn't properly stacking its limits.
The various raid levels use disk_stack_limits, but not faulty.c
I'd wager the issue is that faulty.c is just using the limits set by blk_set_stacking_limits (via drivers/md/md.c:md_alloc)... which is a BUG, blk_set_stacking_limits just establishes a baseline upon which a stacking device should stack its limits (via one of these: {blk,bdev,disk}_stack_limits).
Thanks Mike, this did it, I'll send it upstream.
index 75c3bfd..a262192 100644
--- a/drivers/md/faulty.c
+++ b/drivers/md/faulty.c
@@ -315,8 +315,11 @@ static int run(struct mddev *mddev)
}
conf->nfaults = 0;
- list_for_each_entry(rdev, &mddev->disks, same_set)
+ list_for_each_entry(rdev, &mddev->disks, same_set) {
conf->rdev = rdev;
+ disk_stack_limits(mddev->gendisk, rdev->bdev,
+ rdev->data_offset << 9);
+ }
md_set_array_sectors(mddev, faulty_size(mddev, 0, 0));
mddev->private = conf;
FWIW, I think maybe xfs was not handling a failed bio_alloc due to the much higher number, as well.
Confirmed, xfs isn't handling a xfs_alloc_ioend_bio() allocation failure w/ 64k nvecs... Sent patch upstream: http://marc.info/?l=linux-raid&m=135069023019874&w=2 This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release. Patch(es) available on kernel-2.6.32-337.el6 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0496.html |