diff options
Diffstat (limited to 'meta/recipes-devtools/pseudo/files/delete_mismatches.patch')
-rw-r--r-- | meta/recipes-devtools/pseudo/files/delete_mismatches.patch | 51 |
1 files changed, 0 insertions, 51 deletions
diff --git a/meta/recipes-devtools/pseudo/files/delete_mismatches.patch b/meta/recipes-devtools/pseudo/files/delete_mismatches.patch deleted file mode 100644 index 6c78d787c7..0000000000 --- a/meta/recipes-devtools/pseudo/files/delete_mismatches.patch +++ /dev/null | |||
@@ -1,51 +0,0 @@ | |||
1 | When we see cases where the inode no longer matches the file path, pseudo | ||
2 | notices but currently reuses the database entry. This can happen where for | ||
3 | example, a file is deleted and a new file created outside of pseudo where | ||
4 | the inode number is reused. | ||
5 | |||
6 | Change this to ignore the likely stale database entry instead. We're | ||
7 | seeing bugs where inode reuse for deleted files causes permission corruption. | ||
8 | (See bug #14057 for example). We don't want to delete the database entry | ||
9 | as the permissions may need to be applied to that file (and testing shows | ||
10 | we do need the path matching code which handles that). | ||
11 | |||
12 | I appreciate this should never happen under the original design of pseudo | ||
13 | where all file accesses are monitored by pseudo. The reality is to do that, | ||
14 | we'd have to run pseudo: | ||
15 | |||
16 | a) for all tasks | ||
17 | b) as one pseudo database for all of TMPDIR | ||
18 | |||
19 | Neither of these is realistically possible for performance reasons. | ||
20 | |||
21 | I believe pseudo to be much better at catching all accesses than it | ||
22 | might once have been. As such, these "fixups" are in the cases I've | ||
23 | seen in the logs, always incorrect. | ||
24 | |||
25 | It therefore makes more sense to ignore the database data rather than | ||
26 | corrupt the file permissions or worse. Looking at the pseudo logs | ||
27 | in my heavily reused build directories, the number of these | ||
28 | errors is staggering. This issue would explain many weird bugs we've | ||
29 | seen over the years. | ||
30 | |||
31 | There is a risk that we could not map permissions in some case where | ||
32 | we currently would. I have not seen evidence of this in any logs I've | ||
33 | read though. This change, whilst going against the original design, | ||
34 | is in my view the safer option for the project at this point given we | ||
35 | don't use pseudo as originally designed and never will be able to. | ||
36 | |||
37 | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> | ||
38 | Upstream-Status: Pending | ||
39 | |||
40 | Index: git/pseudo.c | ||
41 | =================================================================== | ||
42 | --- git.orig/pseudo.c | ||
43 | +++ git/pseudo.c | ||
44 | @@ -699,6 +701,7 @@ pseudo_op(pseudo_msg_t *msg, const char | ||
45 | (unsigned long long) msg_header.ino, | ||
46 | path_by_ino ? path_by_ino : "no path", | ||
47 | msg->path); | ||
48 | + found_ino = 0; | ||
49 | } | ||
50 | } | ||
51 | } else { | ||