Hide Forgot
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:
Sorry, left out version: librtas-1.3.13-2.el7.ppc64le But I believe this is the same in latest upstream librtas as well.
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.
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 From hegdevasant.com 2016-03-10 10:14 EDT------- I think below commit on kernel side resolves this issue. commit e256caa7d0515e301f8c8c6e7d1204a2b67b1381 Author: Vasant Hegde <hegdevasant.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.ibm.com> CC: Nathan Fontenot <nfont.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant.ibm.com> Acked-by: Dan Williams <dan.j.williams> Signed-off-by: Michael Ellerman <mpe.au> -Vasant ------- Comment From hegdevasant.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.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.ibm.com> Signed-off-by: Vasant Hegde <hegdevasant.ibm.com> -Vasant ------- Comment From hegdevasant.com 2016-03-10 10:17 EDT------- Hello RedHat, Please lets know if you still have issue after applying these patches?. -Vasant
Sinny, can you backport / merge that librtas patch?
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.
(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 ...
(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 ...
(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.
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