sony-yuga: add proc_fdinfo patch from LG Hammerhead kernel to fix logind complaints (MR 2615)

This commit is contained in:
Wouter92 2021-10-18 16:42:35 +02:00
parent 28ef1ffb4d
commit d552491a24
No known key found for this signature in database
GPG key ID: 6FE3B029D9D9FAFF
2 changed files with 83 additions and 0 deletions

View file

@ -39,6 +39,7 @@ source="
psmouse_base.patch
kgsl_iommu_sync_lock.patch
02_reduce_lzo_compression.patch
proc_fdinfo.patch
"
builddir="$srcdir/$_repository-$_commit"
_outdir="out"
@ -70,4 +71,5 @@ ea1d3b5a234fa565e3c1a792de48f4fc4e6023d281d303c8e319c7ef28edc5739ab0e4dea0139a41
f7e31cfe422696922aec52002e56c58103183966edee3bb8e1995d33f8d37b07c32280a8ecc213874e358a6ff367418556a4542fba7e3c17e4b8e82e05c3a543 psmouse_base.patch
448bad436377a22c93ac401b9aecb504fe8e84b9511a3dd28f3cc125f3725cc1168ef03dee9f8f1085a9fbb7910b9e75cd25a382ccce626b427c8e27f7c17ffc kgsl_iommu_sync_lock.patch
ef5b912c26fea4ab882592bdf7487942c64b123de8d25d08d976f29743f311742ee2f773bf2d110ddb5095f254dbb0bd4487c5cfce77311929082599199e7ebd 02_reduce_lzo_compression.patch
93f7870b2063d4ddb1f35dc4de4b213d83e0f54f59511b3050e880763f2374b3816ac0c879de76fe8a0b61d62c1753c5dda7326961164a8fcbfc8a9232309569 proc_fdinfo.patch
"

View file

@ -0,0 +1,81 @@
From 25437b2a54dd619a96e268ecaf303b089aa785e4 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 4 Jun 2012 11:00:45 -0700
Subject: [PATCH] vfs: Fix /proc/<tid>/fdinfo/<fd> file handling
commit 0640113be25d283e0ff77a9f041e1242182387f0 upstream.
Cyrill Gorcunov reports that I broke the fdinfo files with commit
30a08bf2d31d ("proc: move fd symlink i_mode calculations into
tid_fd_revalidate()"), and he's quite right.
The tid_fd_revalidate() function is not just used for the <tid>/fd
symlinks, it's also used for the <tid>/fdinfo/<fd> files, and the
permission model for those are different.
So do the dynamic symlink permission handling just for symlinks, making
the fdinfo files once more appear as the proper regular files they are.
Of course, Al Viro argued (probably correctly) that we shouldn't do the
symlink permission games at all, and make the symlinks always just be
the normal 'lrwxrwxrwx'. That would have avoided this issue too, but
since somebody noticed that the permissions had changed (which was the
reason for that original commit 30a08bf2d31d in the first place), people
do apparently use this feature.
[ Basically, you can use the symlink permission data as a cheap "fdinfo"
replacement, since you see whether the file is open for reading and/or
writing by just looking at st_mode of the symlink. So the feature
does make sense, even if the pain it has caused means we probably
shouldn't have done it to begin with. ]
Change-Id: I6499a97dc8993b3dd6b4df5af2724990ee91fd3b
Reported-and-tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/base.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2f198dad12c5..c8cb15dcca08 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1838,7 +1838,7 @@ static int tid_fd_revalidate(struct dentry *dentry, struct nameidata *nd)
rcu_read_lock();
file = fcheck_files(files, fd);
if (file) {
- unsigned i_mode, f_mode = file->f_mode;
+ unsigned f_mode = file->f_mode;
rcu_read_unlock();
put_files_struct(files);
@@ -1854,12 +1854,14 @@ static int tid_fd_revalidate(struct dentry *dentry, struct nameidata *nd)
inode->i_gid = 0;
}
- i_mode = S_IFLNK;
- if (f_mode & FMODE_READ)
- i_mode |= S_IRUSR | S_IXUSR;
- if (f_mode & FMODE_WRITE)
- i_mode |= S_IWUSR | S_IXUSR;
- inode->i_mode = i_mode;
+ if (S_ISLNK(inode->i_mode)) {
+ unsigned i_mode = S_IFLNK;
+ if (f_mode & FMODE_READ)
+ i_mode |= S_IRUSR | S_IXUSR;
+ if (f_mode & FMODE_WRITE)
+ i_mode |= S_IWUSR | S_IXUSR;
+ inode->i_mode = i_mode;
+ }
security_task_to_inode(task, inode);
put_task_struct(task);
@@ -1894,6 +1896,7 @@ static struct dentry *proc_fd_instantiate(struct inode *dir,
ei = PROC_I(inode);
ei->fd = fd;
+ inode->i_mode = S_IFLNK;
inode->i_op = &proc_pid_link_inode_operations;
inode->i_size = 64;
ei->op.proc_get_link = proc_fd_link;