| commit | 2d7e662fe7a645599757bf93ef1b46168f9202e7 | |
| author | Matthew Dillon <dillon@apollo.backplane.com> | |
| Sat, 5 Mar 2016 03:17:28 +0000 (4 19:17 -0800) | ||
| committer | Matthew Dillon <dillon@apollo.backplane.com> | |
| Sat, 5 Mar 2016 03:17:28 +0000 (4 19:17 -0800) | ||
| tree | 420d67e8223cd271bcd3ae940f595a10579d42b3 | treesnapshot (tar.gz zip) |
| parent | 2192e32eabfeca69947bbc94e2f4061a24451eb2 | commitdiff |
hammer - Fix coredump bug which can stall processes
* Fix a coredump bug which can stall the process. If a process > 100MB is
in the process of being coredumped, a signal will cause the hammer_write()
path to hit tstop() due to the core-dump being in progress. Unfortunately
the write might be happening from the kernel core generator itself which
will stall the process forever with a number of locks held.
hammer only checks for signals on very large (> 100MB) read() and write()
calls so the issue does not effect coredumps of smaller processes.
* Use CURSIG_NOBLOCK() instead of CURSIG().
* Fix a coredump bug which can stall the process. If a process > 100MB is
in the process of being coredumped, a signal will cause the hammer_write()
path to hit tstop() due to the core-dump being in progress. Unfortunately
the write might be happening from the kernel core generator itself which
will stall the process forever with a number of locks held.
hammer only checks for signals on very large (> 100MB) read() and write()
calls so the issue does not effect coredumps of smaller processes.
* Use CURSIG_NOBLOCK() instead of CURSIG().
| sys/vfs/hammer/hammer_signal.c | diffblobblamehistory | |
| sys/vfs/hammer2/hammer2_subr.c | diffblobblamehistory |