diff options
| author | Bob Peterson <rpeterso@redhat.com> | 2020-07-24 20:06:31 +0300 | 
|---|---|---|
| committer | Andreas Gruenbacher <agruenba@redhat.com> | 2020-08-07 18:22:55 +0300 | 
| commit | 70499cdfeb3625c87eebe4f7a7ea06fa7447e5df (patch) | |
| tree | f9b6e70fea9b1497b7dbae595e429bef663e9ae0 /drivers/fpga/zynq-fpga.c | |
| parent | b0be23b23f6cdeb61d154fef72cd82f8f99f9ca4 (diff) | |
| download | linux-70499cdfeb3625c87eebe4f7a7ea06fa7447e5df.tar.xz | |
gfs2: Never call gfs2_block_zero_range with an open transaction
Before this patch, some functions started transactions then they called
gfs2_block_zero_range. However, gfs2_block_zero_range, like writes, can
start transactions, which results in a recursive transaction error.
For example:
do_shrink
   trunc_start
      gfs2_trans_begin <------------------------------------------------
         gfs2_block_zero_range
            iomap_zero_range(inode, from, length, NULL, &gfs2_iomap_ops);
               iomap_apply ... iomap_zero_range_actor
                  iomap_begin
                     gfs2_iomap_begin
                        gfs2_iomap_begin_write
                  actor (iomap_zero_range_actor)
		     iomap_zero
			iomap_write_begin
			   gfs2_iomap_page_prepare
			      gfs2_trans_begin <------------------------
This patch reorders the callers of gfs2_block_zero_range so that they
only start their transactions after the call. It also adds a BUG_ON to
ensure this doesn't happen again.
Fixes: 2257e468a63b ("gfs2: implement gfs2_block_zero_range using iomap_zero_range")
Cc: stable@vger.kernel.org # v5.5+
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Diffstat (limited to 'drivers/fpga/zynq-fpga.c')
0 files changed, 0 insertions, 0 deletions
