<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/fs/gfs2/bmap.c, branch dev-4.17</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2018-04-12T17:07:51+00:00</updated>
<entry>
<title>GFS2: Minor improvements to comments and documentation</title>
<updated>2018-04-12T17:07:51+00:00</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2018-04-06T20:07:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3e7aafc39c59c639ebd5961f893743f076df9b4e'/>
<id>urn:sha1:3e7aafc39c59c639ebd5961f893743f076df9b4e</id>
<content type='text'>
This patch simply fixes some comments and the gfs2-glocks.txt file:
Places where i_rwsem was called i_mutex, and adding i_rw_mutex.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Zero out fallocated blocks in fallocate_chunk</title>
<updated>2018-03-29T13:50:32+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2018-03-29T13:50:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=fffb64127adc3eea6a19ceefdc88d171f68b9d34'/>
<id>urn:sha1:fffb64127adc3eea6a19ceefdc88d171f68b9d34</id>
<content type='text'>
Instead of zeroing out fallocated blocks in gfs2_iomap_alloc, zero them
out in fallocate_chunk, much higher up the call stack.  This gets rid of
gfs2's abuse of the IOMAP_ZERO flag as well as the gfs2 specific zeronew
buffer flag.  I can't think of a reason why zeroing out the blocks in
gfs2_iomap_alloc would have any benefits: there is no additional locking
at that level that would add protection to the newly allocated blocks.

While at it, change fallocate over from gs2_block_map to gfs2_iomap_begin.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Acked-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>gfs2: Check for the end of metadata in punch_hole</title>
<updated>2018-03-23T18:43:02+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2018-03-23T14:33:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=bb491ce67aa7c1635e5ae4f2f304a7d13d3dbe71'/>
<id>urn:sha1:bb491ce67aa7c1635e5ae4f2f304a7d13d3dbe71</id>
<content type='text'>
When punching a hole or truncating an inode down to a given size, also
check if the truncate point / start of the hole is within the range we
have metadata for.  Otherwise, we can end up freeing blocks that
shouldn't be freed, corrupting the inode, or crashing the machine when
trying to punch a hole into the void.

When growing an inode via truncate, we set the new size but we don't
allocate additional levels of indirect blocks and grow the inode height.
When shrinking that inode again, the new size may still point beyond the
end of the inode's metadata.

Fixes xfstest generic/476.

Debugged-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Improve gfs2_block_map comment</title>
<updated>2018-03-08T16:26:20+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2018-03-05T13:24:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=d39d18e0ef738cc8614abd8bb25fb270a4c41801'/>
<id>urn:sha1:d39d18e0ef738cc8614abd8bb25fb270a4c41801</id>
<content type='text'>
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Fixes to "Implement iomap for block_map" (2)</title>
<updated>2018-03-07T18:40:38+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2018-03-05T13:18:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3b5da96e4585a2788da6a07619bda3518d76eb30'/>
<id>urn:sha1:3b5da96e4585a2788da6a07619bda3518d76eb30</id>
<content type='text'>
It turns out that commit 3229c18c0d6b2 'Fixes to "Implement iomap for
block_map"' introduced another bug in gfs2_iomap_begin that can cause
gfs2_block_map to set bh-&gt;b_size of an actual buffer to 0.  This can
lead to arbitrary incorrect behavior including crashes or disk
corruption.  Revert the incorrect part of that commit.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Fixes to "Implement iomap for block_map"</title>
<updated>2018-02-13T20:38:10+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2018-02-06T14:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=49edd5bf429c405b3a7f75503845d9f66a47dd4b'/>
<id>urn:sha1:49edd5bf429c405b3a7f75503845d9f66a47dd4b</id>
<content type='text'>
It turns out that commit 3974320ca6 "Implement iomap for block_map"
introduced a few bugs that trigger occasional failures with xfstest
generic/476:

In gfs2_iomap_begin, we jump to do_alloc when we determine that we are
beyond the end of the allocated metadata (height &gt; ip-&gt;i_height).
There, we can end up calling hole_size with a metapath that doesn't
match the current metadata tree, which doesn't make sense.  After
untangling the code at do_alloc, fix this by checking if the block we
are looking for is within the range of allocated metadata.

In addition, add a BUG() in case gfs2_iomap_begin is accidentally called
for reading stuffed files: this is handled separately.  Make sure we
don't truncate iomap-&gt;length for reads beyond the end of the file; in
that case, the entire range counts as a hole.

Finally, revert to taking a bitmap write lock when doing allocations.
It's unclear why that change didn't lead to any failures during testing.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Add gfs2_max_stuffed_size</title>
<updated>2018-01-18T21:18:53+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2017-11-14T15:53:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=235628c5c76040b0ec206ea9ab9e017771e0d78e'/>
<id>urn:sha1:235628c5c76040b0ec206ea9ab9e017771e0d78e</id>
<content type='text'>
Add a small inline function for computing the maximum size of a stuffed
inode instead of open coding that in several places throughout the code.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Implement fallocate(FALLOC_FL_PUNCH_HOLE)</title>
<updated>2018-01-18T20:15:58+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2017-12-14T16:11:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4e56a6411fbce6f859566e17298114c2434391a4'/>
<id>urn:sha1:4e56a6411fbce6f859566e17298114c2434391a4</id>
<content type='text'>
Implement the top-level bits of punching a hole into a file.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Turn trunc_dealloc into punch_hole</title>
<updated>2018-01-18T20:15:57+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2017-12-18T23:06:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=10d2cf94c23d48ef1b141084216e7580011e4790'/>
<id>urn:sha1:10d2cf94c23d48ef1b141084216e7580011e4790</id>
<content type='text'>
Add an upper bound to the range of blocks to deallocate blocks to
function trunc_dealloc so that this function can be used for truncating
a file as well as for punching a hole into a file.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Generalize truncate code</title>
<updated>2018-01-18T20:15:37+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2017-12-11T11:49:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5cf26b1e88c9eef76a1e8bdedbad48db925bbdd5'/>
<id>urn:sha1:5cf26b1e88c9eef76a1e8bdedbad48db925bbdd5</id>
<content type='text'>
Pull the code for computing the range of metapointers to iterate out of
gfs2_metapath_ra (for readahead), sweep_bh_for_rgrps (for deallocating
metapointers within a block), and trunc_dealloc (for walking the
metadata tree).

In sweep_bh_for_rgrps, move the code for looking up the resource group
descriptor of the current resource group out of the inner loop.  The
metatype check moves to trunc_dealloc.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
</feed>
