| 1894
|
|
|
Martin Hicks |
4 months ago
|
 |
|
| 1893
|
|
|
Kienan Stewart |
4 months ago
|
|
|
| 1892
|
|
|
Jérémie Galarneau |
4 months ago
|
|
|
| 1891
|
|
Remove strlcpy usage
The replacement for `strlcpy`, `strscpy`, was introduced in Linux
4.3. As lttng-modules master aims to support Linux 4.4+ at this time,
the version check can safely be removed.
See upstream commit:
commit 30035e45753b708e7d47a98398500ca005e02b86
Author: Chris Metcalf <cmetcalf@ezchip.com>
Date: Wed Apr 29 12:52:04 2015 -0400
string: provide strscpy()
The strscpy() API is intended to be used instead of strlcpy(),
and instead of most uses of strncpy().
- Unlike strlcpy(), it doesn't read from memory beyond (src + size).
- Unlike strlcpy() or strncpy(), the API provides an easy way to check
for destination buffer overflow: an -E2BIG error return value.
- The provided implementation is robust in the face of the source
buffer being asynchronously changed during the copy, unlike the
current implementation of strlcpy().
- Unlike strncpy(), the destination buffer will be NUL-terminated
if the string in the source buffer is too long.
- Also unlike strncpy(), the destination buffer will not be updated
beyond the NUL termination, avoiding strncpy's behavior of zeroing
the entire tail end of the destination buffer. (A memset() after
the strscpy() can be used if this behavior is desired.)
- The implementation should be reasonably performant on all
platforms since it uses the asm/word-at-a-time.h API rather than
simple byte copy. Kernel-to-kernel string copy is not considered
to be performance critical in any case.
Change-Id: I31fefde148d5b63a30532fbcb4b59bb951bba902
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Kienan Stewart |
4 months ago
|
|
|
| 1890
|
|
Fix: btrfs_get_extent flags and compress_type changed in linux 6.8.0-rc1
See upstream commit:
commit f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9
Author: Filipe Manana <fdmanana@suse.com>
Date: Mon Dec 4 16:20:33 2023 +0000
btrfs: use the flags of an extent map to identify the compression type
Currently, in struct extent_map, we use an unsigned int (32 bits) to
identify the compression type of an extent and an unsigned long (64 bits
on a 64 bits platform, 32 bits otherwise) for flags. We are only using
6 different flags, so an unsigned long is excessive and we can use flags
to identify the compression type instead of using a dedicated 32 bits
field.
We can easily have tens or hundreds of thousands (or more) of extent maps
on busy and large filesystems, specially with compression enabled or many
or large files with tons of small extents. So it's convenient to have the
extent_map structure as small as possible in order to use less memory.
So remove the compression type field from struct extent_map, use flags
to identify the compression type and shorten the flags field from an
unsigned long to a u32. This saves 8 bytes (on 64 bits platforms) and
reduces the size of the structure from 136 bytes down to 128 bytes, using
now only two cache lines, and increases the number of extent maps we can
have per 4K page from 30 to 32. By using a u32 for the flags instead of
an unsigned long, we no longer use test_bit(), set_bit() and clear_bit(),
but that level of atomicity is not needed as most flags are never cleared
once set (before adding an extent map to the tree), and the ones that can
be cleared or set after an extent map is added to the tree, are always
performed while holding the write lock on the extent map tree, while the
reader holds a lock on the tree or tests for a flag that never changes
once the extent map is in the tree (such as compression flags).
Change-Id: I95402d43f064c016b423b48652e4968d3db9b8a9
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Kienan Stewart |
4 months ago
|
|
|
| 1889
|
|
Fix: btrfs_chunk tracepoints changed in linux 6.8.0-rc1
See upstream commit:
commit 7dc66abb5a47778d7db327783a0ba172b8cff0b5
Author: Filipe Manana <fdmanana@suse.com>
Date: Tue Nov 21 13:38:38 2023 +0000
btrfs: use a dedicated data structure for chunk maps
Currently we abuse the extent_map structure for two purposes:
1) To actually represent extents for inodes;
2) To represent chunk mappings.
This is odd and has several disadvantages:
1) To create a chunk map, we need to do two memory allocations: one for
an extent_map structure and another one for a map_lookup structure, so
more potential for an allocation failure and more complicated code to
manage and link two structures;
2) For a chunk map we actually only use 3 fields (24 bytes) of the
respective extent map structure: the 'start' field to have the logical
start address of the chunk, the 'len' field to have the chunk's size,
and the 'orig_block_len' field to contain the chunk's stripe size.
Besides wasting a memory, it's also odd and not intuitive at all to
have the stripe size in a field named 'orig_block_len'.
We are also using 'block_len' of the extent_map structure to contain
the chunk size, so we have 2 fields for the same value, 'len' and
'block_len', which is pointless;
3) When an extent map is associated to a chunk mapping, we set the bit
EXTENT_FLAG_FS_MAPPING on its flags and then make its member named
'map_lookup' point to the associated map_lookup structure. This means
that for an extent map associated to an inode extent, we are not using
this 'map_lookup' pointer, so wasting 8 bytes (on a 64 bits platform);
4) Extent maps associated to a chunk mapping are never merged or split so
it's pointless to use the existing extent map infrastructure.
So add a dedicated data structure named 'btrfs_chunk_map' to represent
chunk mappings, this is basically the existing map_lookup structure with
some extra fields:
1) 'start' to contain the chunk logical address;
2) 'chunk_len' to contain the chunk's length;
3) 'stripe_size' for the stripe size;
4) 'rb_node' for insertion into a rb tree;
5) 'refs' for reference counting.
This way we do a single memory allocation for chunk mappings and we don't
waste memory for them with unused/unnecessary fields from an extent_map.
We also save 8 bytes from the extent_map structure by removing the
'map_lookup' pointer, so the size of struct extent_map is reduced from
144 bytes down to 136 bytes, and we can now have 30 extents map per 4K
page instead of 28.
Change-Id: Ie52b5ac83df4bc6abeb84d958c4f5d24ae0d8c75
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Kienan Stewart |
4 months ago
|
|
|
| 1888
|
|
|
Kienan Stewart |
4 months ago
|
|
|
| 1887
|
|
|
Kienan Stewart |
4 months ago
|
|
|
| 1886
|
|
|
Kienan Stewart |
4 months ago
|
|
|
| 1885
|
|
|
Kienan Stewart |
5 months ago
|
|
|
| 1884
|
|
|
Mathieu Desnoyers |
5 months ago
|
|
|
| 1883
|
|
|
Michael Jeanson |
5 months ago
|
|
|
| 1882
|
|
|
Mathieu Desnoyers |
5 months ago
|
|
|
| 1881
|
|
|
Mathieu Desnoyers |
5 months ago
|
|
|
| 1880
|
|
|
Michael Jeanson |
5 months ago
|
|
|
| 1879
|
|
|
Mathieu Desnoyers |
5 months ago
|
|
|
| 1878
|
|
|
Mathieu Desnoyers |
5 months ago
|
|
|
| 1877
|
|
|
Mathieu Desnoyers |
6 months ago
|
|
|
| 1876
|
|
|
Lei wang |
6 months ago
|
|
|
| 1875
|
|
|
Kienan Stewart |
6 months ago
|
|
|
collapse all