In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2dioendiowrite() estimates number of necessary transaction credits using ocfs2calcextend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2markextentwritten() will end up calling ocfs2replaceextentrec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARNON(jbd2handlebuffercredits(handle) <= 0) is triggered in jbd2journaldirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2markextent_written().
Heming Zhao said:
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machinekexec at ffffffff8c069932 #1 _crashkexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2handleerror at ffffffffc0c86c0c [ocfs2] #4 _ocfs2abort at ffffffffc0c88387 [ocfs2] #5 ocfs2journaldirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2splitextent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2changeextentflag at ffffffffc0c28053 [ocfs2] #8 ocfs2markextentwritten at ffffffffc0c28347 [ocfs2] #9 ocfs2dioendio_write at ffffffffc0c2bef9 [ocfs2]