2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-05-18 15:09:15 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-01 11:05:15 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2014-03-06 12:10:45 -08:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-27 17:23:27 -05:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-04-18 10:09:15 -04:00
|
|
|
|
2016-11-01 07:40:13 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-02-27 17:23:27 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2006-02-27 17:23:27 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2010-09-17 12:30:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2010-08-11 09:53:11 +01:00
|
|
|
|
|
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-22 16:09:31 +00:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-27 12:00:42 -05:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-26 10:51:20 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-05-05 16:59:11 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-24 10:07:13 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-01 15:28:57 -04:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-11 09:53:11 +01:00
|
|
|
|
|
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-05-05 16:59:11 -04:00
|
|
|
|
2006-09-21 17:05:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-19 16:02:07 +02:00
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-21 17:05:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
2006-01-30 13:31:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-30 09:48:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 09:17:28 +01:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2014-11-20 05:18:38 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-20 05:19:47 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2014-11-20 05:19:47 +00:00
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2014-11-20 05:19:47 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-29 10:03:41 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2015-10-29 10:03:41 -05:00
|
|
|
|
|
|
|
|
|
2014-11-20 05:18:38 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
GFS2: rename causes kernel Oops
This patch fixes a kernel Oops in the GFS2 rename code.
The problem was in the way the gfs2 directory code was trying
to re-use sentinel directory entries.
In the failing case, gfs2's rename function was renaming a
file to another name that had the same non-trivial length.
The file being renamed happened to be the first directory
entry on the leaf block.
First, the rename code (gfs2_rename in ops_inode.c) found the
original directory entry and decided it could do its job by
simply replacing the directory entry with another. Therefore
it determined correctly that no block allocations were needed.
Next, the rename code deleted the old directory entry prior to
replacing it with the new name. Therefore, the soon-to-be
replaced directory entry was temporarily made into a directory
entry "sentinel" or a place holder at the start of a leaf block.
Lastly, it went to re-add the replacement directory entry in
that leaf block. However, when gfs2_dirent_find_space was
looking for space in the leaf block, it used the wrong value
for the sentinel. That threw off its calculations so later
it decides it can't really re-use the sentinel and therefore
must allocate a new leaf block. But because it previously decided
to re-use the directory entry, it didn't waste the time to
grab a new block allocation for the inode. Therefore, the
inode's i_alloc pointer was still NULL and it crashes trying to
reference it.
In the case of sentinel directory entries, the entire dirent is
reused, not just the "free space" portion of it, and therefore
the function gfs2_dirent_find_space should use the value 0
rather than GFS2_DIRENT_SIZE(0) for the actual dirent size.
Fixing this calculation enables the reproducer programs to work
properly.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2010-07-14 18:12:26 -04:00
|
|
|
|
2006-09-05 14:30:40 +02:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-06 12:10:45 -08:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:46:23 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2014-03-06 12:10:45 -08:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-14 15:56:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-13 16:21:47 +00:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-13 16:21:47 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-25 09:26:04 -04:00
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2014-03-06 12:10:45 -08:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
remove lots of IS_ERR_VALUE abuses
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.
This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.
Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.
I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.
I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-27 23:23:25 +02:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
remove lots of IS_ERR_VALUE abuses
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.
This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.
Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.
I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.
I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-27 23:23:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
remove lots of IS_ERR_VALUE abuses
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.
This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.
Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.
I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.
I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-27 23:23:25 +02:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2010-08-11 09:53:11 +01:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-25 09:26:04 -04:00
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 14:49:06 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-09-25 09:26:04 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-25 09:26:04 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-04-11 14:49:06 -04:00
|
|
|
|
2006-04-07 16:28:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2008-02-06 10:11:15 +00:00
|
|
|
|
2009-05-20 10:48:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2009-05-20 10:48:47 +01:00
|
|
|
|
2011-11-18 10:58:32 -05:00
|
|
|
|
2009-05-20 10:48:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2009-05-20 10:48:47 +01:00
|
|
|
|
2008-02-01 13:16:55 +00:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-10-14 16:49:30 +01:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2017-07-04 17:25:22 +01:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-10-14 10:46:30 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-14 15:56:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-02-14 15:56:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-10-14 10:46:30 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-11 09:53:11 +01:00
|
|
|
|
2008-02-12 14:17:27 +00:00
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-07-11 13:19:13 -04:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-10-14 10:46:30 -04:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
remove lots of IS_ERR_VALUE abuses
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.
However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.
Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.
This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.
Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.
I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.
I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-27 23:23:25 +02:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2014-03-06 12:10:45 -08:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-20 19:45:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2009-11-06 11:06:37 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-17 12:27:44 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-12-01 08:30:34 -06:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-13 00:06:10 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-13 00:06:10 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2008-02-12 14:17:27 +00:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-06-14 08:39:18 -04:00
|
|
|
|
2013-05-30 09:48:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2010-07-20 19:45:03 -07:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-06-14 08:39:18 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 12:04:26 -04:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-20 05:18:38 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-14 15:56:44 +00:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-05 09:34:20 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-02-14 15:56:44 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
|
|
|
|
|
2007-01-17 15:09:20 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2007-04-25 21:08:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-26 08:28:56 -05:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2010-07-28 17:56:23 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
|
|
|
|
|
2014-11-20 05:18:38 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 13:46:06 +00:00
|
|
|
|
|
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 13:46:06 +00:00
|
|
|
|
|
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-09 13:46:06 +00:00
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: add flag REQ_PRIO for metadata I/O
When gfs2 does metadata I/O, only REQ_META is used as a metadata hint of
the bio. But flag REQ_META is just a hint for block trace, not for block
layer code to handle a bio as metadata request.
For some of metadata I/Os of gfs2, A REQ_PRIO flag on the metadata bio
would be very informative to block layer code. For example, if bcache is
used as a I/O cache for gfs2, it will be possible for bcache code to get
the hint and cache the pre-fetched metadata blocks on cache device. This
behavior may be helpful to improve metadata I/O performance if the
following requests hit the cache.
Here are the locations in gfs2 code where a REQ_PRIO flag should be added,
- All places where REQ_READAHEAD is used, gfs2 code uses this flag for
metadata read ahead.
- In gfs2_meta_rq() where the first metadata block is read in.
- In gfs2_write_buf_to_page(), read in quota metadata blocks to have them
up to date.
These metadata blocks are probably to be accessed again in future, adding
a REQ_PRIO flag may have bcache to keep such metadata in fast cache
device. For system without a cache layer, REQ_PRIO can still provide hint
to block layer to handle metadata requests more properly.
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2017-07-21 07:48:22 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
|
|
|
|
|
2006-10-14 10:46:30 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-07-11 13:19:13 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-11-09 13:46:06 +00:00
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-10-27 12:16:06 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2008-04-09 09:33:41 -04:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
2017-05-26 08:28:56 -05:00
|
|
|
|
2007-04-18 09:38:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2013-05-16 14:14:48 -04:00
|
|
|
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 08:46:55 -06:00
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2008-02-07 00:15:26 -08:00
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2013-06-11 13:45:29 +01:00
|
|
|
|
|
|
|
|
|
gfs2: Fix gfs2_lookup_by_inum lock inversion
The current gfs2_lookup_by_inum takes the glock of a presumed inode
identified by block number, verifies that the block is indeed an inode,
and then instantiates and reads the new inode via gfs2_inode_lookup.
However, instantiating a new inode may block on freeing a previous
instance of that inode (__wait_on_freeing_inode), and freeing an inode
requires to take the glock already held, leading to lock inversion and
deadlock.
Fix this by first instantiating the new inode, then verifying that the
block is an inode (if required), and then reading in the new inode, all
in gfs2_inode_lookup.
If the block we are looking for is not an inode, we discard the new
inode via iget_failed, which marks inodes as bad and unhashes them.
Other tasks waiting on that inode will get back a bad inode back from
ilookup or iget_locked; in that case, retry the lookup.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2016-06-14 12:22:27 -05:00
|
|
|
|
|
|
|
|
|
2015-11-11 15:00:35 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
2006-04-12 17:39:45 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2008-02-12 14:17:27 +00:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
GFS2: Add meta readahead field in directory entries
The intent of this new field in the directory entry is to
allow a subsequent lookup to know how many blocks, which
are contiguous with the inode, contain metadata which relates
to the inode. This will then allow the issuing of a single
read to read these blocks, rather than reading the inode
first, and then issuing a second read for the metadata.
This only works under some fairly strict conditions, since
we do not have back pointers from inodes to directory entries
we must ensure that the blocks referenced in this way will
always belong to the inode.
This rules out being able to use this system for indirect
blocks, as these can change as a result of truncate/rewrite.
So the idea here is to restrict this to xattr blocks only
for the time being. For most inodes, that means only a
single block. Also, when using ACLs and/or SELinux or
other LSMs, these will be added at inode creation time
so that they will be contiguous with the inode on disk and
also will almost always be needed when we read the inode in
for permissions checks.
Once an xattr block for an inode is allocated, it will never
change until the inode is deallocated.
This patch adds the new field, a further patch will add the
readahead in due course.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2014-02-07 11:23:22 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
|
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2011-05-09 13:30:08 +01:00
|
|
|
|
GFS2: Add meta readahead field in directory entries
The intent of this new field in the directory entry is to
allow a subsequent lookup to know how many blocks, which
are contiguous with the inode, contain metadata which relates
to the inode. This will then allow the issuing of a single
read to read these blocks, rather than reading the inode
first, and then issuing a second read for the metadata.
This only works under some fairly strict conditions, since
we do not have back pointers from inodes to directory entries
we must ensure that the blocks referenced in this way will
always belong to the inode.
This rules out being able to use this system for indirect
blocks, as these can change as a result of truncate/rewrite.
So the idea here is to restrict this to xattr blocks only
for the time being. For most inodes, that means only a
single block. Also, when using ACLs and/or SELinux or
other LSMs, these will be added at inode creation time
so that they will be contiguous with the inode on disk and
also will almost always be needed when we read the inode in
for permissions checks.
Once an xattr block for an inode is allocated, it will never
change until the inode is deallocated.
This patch adds the new field, a further patch will add the
readahead in due course.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2014-02-07 11:23:22 +00:00
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2008-02-13 00:06:10 +01:00
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
2011-05-09 13:30:08 +01:00
|
|
|
|
|
|
|
|
|
2012-11-12 13:04:54 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2008-02-01 09:23:44 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-03-29 19:02:15 -05:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-09 16:42:37 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-05-09 16:42:37 +01:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-28 14:14:04 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-04-07 16:28:07 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2008-11-03 13:59:19 +00:00
|
|
|
|
2014-01-08 12:14:57 +00:00
|
|
|
|
VFS: (Scripted) Convert S_ISLNK/DIR/REG(dentry->d_inode) to d_is_*(dentry)
Convert the following where appropriate:
(1) S_ISLNK(dentry->d_inode) to d_is_symlink(dentry).
(2) S_ISREG(dentry->d_inode) to d_is_reg(dentry).
(3) S_ISDIR(dentry->d_inode) to d_is_dir(dentry). This is actually more
complicated than it appears as some calls should be converted to
d_can_lookup() instead. The difference is whether the directory in
question is a real dir with a ->lookup op or whether it's a fake dir with
a ->d_automount op.
In some circumstances, we can subsume checks for dentry->d_inode not being
NULL into this, provided we the code isn't in a filesystem that expects
d_inode to be NULL if the dirent really *is* negative (ie. if we're going to
use d_inode() rather than d_backing_inode() to get the inode pointer).
Note that the dentry type field may be set to something other than
DCACHE_MISS_TYPE when d_inode is NULL in the case of unionmount, where the VFS
manages the fall-through from a negative dentry to a lower layer. In such a
case, the dentry type of the negative union dentry is set to the same as the
type of the lower dentry.
However, if you know d_inode is not NULL at the call site, then you can use
the d_is_xxx() functions even in a filesystem.
There is one further complication: a 0,0 chardev dentry may be labelled
DCACHE_WHITEOUT_TYPE rather than DCACHE_SPECIAL_TYPE. Strictly, this was
intended for special directory entry types that don't have attached inodes.
The following perl+coccinelle script was used:
use strict;
my @callers;
open($fd, 'git grep -l \'S_IS[A-Z].*->d_inode\' |') ||
die "Can't grep for S_ISDIR and co. callers";
@callers = <$fd>;
close($fd);
unless (@callers) {
print "No matches\n";
exit(0);
}
my @cocci = (
'@@',
'expression E;',
'@@',
'',
'- S_ISLNK(E->d_inode->i_mode)',
'+ d_is_symlink(E)',
'',
'@@',
'expression E;',
'@@',
'',
'- S_ISDIR(E->d_inode->i_mode)',
'+ d_is_dir(E)',
'',
'@@',
'expression E;',
'@@',
'',
'- S_ISREG(E->d_inode->i_mode)',
'+ d_is_reg(E)' );
my $coccifile = "tmp.sp.cocci";
open($fd, ">$coccifile") || die $coccifile;
print($fd "$_\n") || die $coccifile foreach (@cocci);
close($fd);
foreach my $file (@callers) {
chomp $file;
print "Processing ", $file, "\n";
system("spatch", "--sp-file", $coccifile, $file, "--in-place", "--no-show-diff") == 0 ||
die "spatch failed";
}
[AV: overlayfs parts skipped]
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-01-29 12:02:35 +00:00
|
|
|
|
2011-05-09 16:42:37 +01:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-08-15 14:20:36 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2007-05-15 15:37:50 +01:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2008-11-04 10:05:22 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2016-09-14 07:48:04 -07:00
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
2011-03-22 13:54:03 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-06-14 15:32:57 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2012-04-04 22:11:16 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2013-06-19 12:15:53 -07:00
|
|
|
|
2013-05-30 09:48:56 -04:00
|
|
|
|
2015-02-01 22:59:54 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-31 17:49:26 -08:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2012-05-18 09:28:23 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2011-09-02 16:08:09 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-28 11:13:02 -06:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2017-06-30 07:55:08 -05:00
|
|
|
|
|
|
|
|
|
2007-06-01 14:11:58 +01:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-27 17:23:27 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2011-03-22 13:55:23 -04:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2008-02-12 14:17:27 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:49:07 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-14 12:36:02 +00:00
|
|
|
|
2011-03-22 13:54:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-31 15:07:05 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2006-09-04 12:04:26 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 12:04:26 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 12:04:26 -04:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2008-03-03 21:54:21 +03:00
|
|
|
|
2014-11-20 05:18:38 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-22 13:56:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2011-03-22 13:56:37 -04:00
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-22 13:56:37 -04:00
|
|
|
|
|
|
|
|
|
2011-06-15 10:29:37 +01:00
|
|
|
|
2011-03-22 13:56:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-02 12:05:27 -05:00
|
|
|
|
2011-03-22 13:56:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2014-01-08 11:05:29 +00:00
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2014-01-08 11:05:29 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2014-01-06 12:49:43 +00:00
|
|
|
|
|
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-04-07 16:28:07 -04:00
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2014-01-08 11:05:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-06 11:28:41 +00:00
|
|
|
|
2006-04-07 16:28:07 -04:00
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
|
|
|
|
|
2014-09-29 08:52:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 12:30:04 -05:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
|
|
