Bug 1300542 - If mmap() of /dev/mem fails, librtas does not release /run/lock/LCK..librtas
If mmap() of /dev/mem fails, librtas does not release /run/lock/LCK..librtas
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: librtas (Show other bugs)
7.3
ppc64le Linux
unspecified Severity medium
: rc
: 7.3
Assigned To: Sinny Kumari
Release Test Team
: Patch
Depends On: 1182039
Blocks: 1230910 1274397
  Show dependency treegraph
 
Reported: 2016-01-21 01:17 EST by David Gibson
Modified: 2016-11-04 00:01 EDT (History)
9 users (show)

See Also:
Fixed In Version: librtas-1.4.1-1.el7
Doc Type: Bug Fix
Doc Text:
Cause: When librtas fails, RMO buffer lock were not released in error path Consequence: In certain cases (like fails to mmap() the RTAS RMO buffer from /dev/mem) if librtas fails, causes future librtas invocations to jam Fix: Update to librtas-1.4.1-1.el7 or higher version Result:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 00:01:38 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 138819 None None None 2016-03-10 09:56 EST

  None (edit)
Description David Gibson 2016-01-21 01:17:39 EST
Description of problem:

If librtas fails in certain ways - in particular if it fails to mmap() the RTAS RMO buffer from /dev/mem - it will fail to release it's fcntl() lock on the error path.  This will then cause future librtas invocations to jam


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


How reproducible:

100%, but may require special kernel to trigger

Steps to Reproduce:
1. Boot with an upstream kernel after 1d54cf2b973a6265789b382b7d305771321b9b57, but before 8a3e3d31d13ece3003e8f750178a7db02c5cd123, and CONFIG_STRICT_DEVMEM enabled. (later upstream kernels may also work, but between those commits should definitely reproduce).
2. Boot a system with librtas_errd installed
3. After boot, run lslocks

Actual results:

[root@localhost ~]# lslocks
COMMAND           PID  TYPE SIZE MODE  M START END PATH
...
rtas_errd        4249 POSIX   0B WRITE 0     0   0 /run/lock/LCK..librtas


Expected results:

No rtas_errd in lslocks output.

Additional info:
Comment 1 David Gibson 2016-01-21 01:20:46 EST
Sorry, left out version:

librtas-1.3.13-2.el7.ppc64le

But I believe this is the same in latest upstream librtas as well.
Comment 2 David Gibson 2016-01-21 01:22:20 EST
The mentioned upstream kernels implement CONFIG_STRICT_DEVMEM, which, due to a kernel bug, prohibits librtas from mmaping() the range of /dev/mem it needs.

Obviously that kernel bug needs to be dealth with elsewhere, but librtas should still release the lock on the failure path.
Comment 3 David Gibson 2016-01-21 01:23:42 EST
Sorry, on further investigation, it's not clear that all the listed kernels will trigger the bug.

Kernel 9fa686068a32ddf256df03982b3e3967c18654a8 does appear to trigger it reliably, though.
Comment 4 IBM Bug Proxy 2016-03-10 10:19:05 EST
------- Comment From hegdevasant@in.ibm.com 2016-03-10 10:14 EDT-------
I think below commit on kernel side resolves this issue.

commit e256caa7d0515e301f8c8c6e7d1204a2b67b1381
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Thu Jan 21 21:45:31 2016 +0530

powerpc/mm: Allow user space to map rtas_rmo_buf

With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) mapping
rtas_rmo_buf from user space is failing. Hence we are not able to make
RTAS syscall.

This patch calls page_is_rtas_user_buf before calling iomem_is_exclusive
in  devmem_is_allowed(). This will allow user space to map rtas_rmo_buf
and we are able to make RTAS syscall.

Reported-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

-Vasant

------- Comment From hegdevasant@in.ibm.com 2016-03-10 10:16 EDT-------
..and librtas fix .

Note that its in origin/next branch.. it will eventually goes to master.. So you can pull this patch .

commit c5e9dcf993e9e20bbe14bc06fb0ec6dd5031f935
Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Date:   Mon Feb 15 07:33:14 2016 -0500

librtas: Release lock in error path

Release RMO buffer lock in error path. Otherwise we will continue to hold
the lock and subsequent RMO buffer allocation request fails.

Reported-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>

-Vasant

------- Comment From hegdevasant@in.ibm.com 2016-03-10 10:17 EDT-------
Hello RedHat,

Please lets know if you still have issue after applying these patches?.

-Vasant
Comment 5 David Gibson 2016-03-10 18:16:04 EST
Sinny, can you backport / merge that librtas patch?
Comment 6 Sinny Kumari 2016-03-11 03:41:38 EST
Sure, we will backport this patch in librtas, RHEL 7.3.
Also, let us know if a new upstream release of librtas occur with fix included.
Comment 7 Hanns-Joachim Uhl 2016-03-11 04:14:27 EST
(In reply to Sinny Kumari from comment #6)
> Sure, we will backport this patch in librtas, RHEL 7.3.
.
... yes, for RHEL7.3 a librtas update is requested in
LTC bug 120225 - RH1182039- [7.3 FEAT] librtas package update - ppc64/ppc64le
.
> Also, let us know if a new upstream release of librtas occur with fix
> included.
.
... I will check ...
Comment 8 Hanns-Joachim Uhl 2016-04-11 06:06:05 EDT
(In reply to Hanns-Joachim Uhl from comment #7)
> (In reply to Sinny Kumari from comment #6)
> > Sure, we will backport this patch in librtas, RHEL 7.3.
> .
> ... yes, for RHEL7.3 a librtas update is requested in
> LTC bug 120225 - RH1182039- [7.3 FEAT] librtas package update - ppc64/ppc64le
> .
> > Also, let us know if a new upstream release of librtas occur with fix
> > included.
> .
> ... I will check ...
.
fyi ... the librtas patch from this bugzilla is included in "librtas 1.4.1"
as available upstream from 
https://github.com/nfont/librtas/releases ...
Comment 9 Sinny Kumari 2016-04-11 07:03:18 EDT
(In reply to Hanns-Joachim Uhl from comment #8)

> fyi ... the librtas patch from this bugzilla is included in "librtas 1.4.1"
> as available upstream from 
> https://github.com/nfont/librtas/releases ...

Thanks for update.
Comment 15 errata-xmlrpc 2016-11-04 00:01:38 EDT
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.

https://rhn.redhat.com/errata/RHBA-2016-2337.html

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