2019-05-29 07:17:56 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2013-05-06 23:50:15 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-02-08 18:51:30 +01:00
|
|
|
|
2017-02-08 18:51:29 +01:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2019-10-08 15:01:59 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2010-03-02 14:51:53 -08:00
|
|
|
|
2015-01-21 10:54:10 -05:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
2018-08-07 12:57:13 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2018-12-14 15:58:21 -08:00
|
|
|
|
2019-10-16 17:01:19 +02:00
|
|
|
|
2023-04-24 19:05:14 +08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2025-07-14 11:53:17 -07:00
|
|
|
|
|
|
|
|
|
2014-10-16 15:26:51 +02:00
|
|
|
|
2018-07-23 14:41:38 -07:00
|
|
|
|
2021-12-15 18:50:18 +05:30
|
|
|
|
2018-07-23 14:41:38 -07:00
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
binder: implement binderfs
As discussed at Linux Plumbers Conference 2018 in Vancouver [1] this is the
implementation of binderfs.
/* Abstract */
binderfs is a backwards-compatible filesystem for Android's binder ipc
mechanism. Each ipc namespace will mount a new binderfs instance. Mounting
binderfs multiple times at different locations in the same ipc namespace
will not cause a new super block to be allocated and hence it will be the
same filesystem instance.
Each new binderfs mount will have its own set of binder devices only
visible in the ipc namespace it has been mounted in. All devices in a new
binderfs mount will follow the scheme binder%d and numbering will always
start at 0.
/* Backwards compatibility */
Devices requested in the Kconfig via CONFIG_ANDROID_BINDER_DEVICES for the
initial ipc namespace will work as before. They will be registered via
misc_register() and appear in the devtmpfs mount. Specifically, the
standard devices binder, hwbinder, and vndbinder will all appear in their
standard locations in /dev. Mounting or unmounting the binderfs mount in
the initial ipc namespace will have no effect on these devices, i.e. they
will neither show up in the binderfs mount nor will they disappear when the
binderfs mount is gone.
/* binder-control */
Each new binderfs instance comes with a binder-control device. No other
devices will be present at first. The binder-control device can be used to
dynamically allocate binder devices. All requests operate on the binderfs
mount the binder-control device resides in.
Assuming a new instance of binderfs has been mounted at /dev/binderfs
via mount -t binderfs binderfs /dev/binderfs. Then a request to create a
new binder device can be made as illustrated in [2].
Binderfs devices can simply be removed via unlink().
/* Implementation details */
- dynamic major number allocation:
When binderfs is registered as a new filesystem it will dynamically
allocate a new major number. The allocated major number will be returned
in struct binderfs_device when a new binder device is allocated.
- global minor number tracking:
Minor are tracked in a global idr struct that is capped at
BINDERFS_MAX_MINOR. The minor number tracker is protected by a global
mutex. This is the only point of contention between binderfs mounts.
- struct binderfs_info:
Each binderfs super block has its own struct binderfs_info that tracks
specific details about a binderfs instance:
- ipc namespace
- dentry of the binder-control device
- root uid and root gid of the user namespace the binderfs instance
was mounted in
- mountable by user namespace root:
binderfs can be mounted by user namespace root in a non-initial user
namespace. The devices will be owned by user namespace root.
- binderfs binder devices without misc infrastructure:
New binder devices associated with a binderfs mount do not use the
full misc_register() infrastructure.
The misc_register() infrastructure can only create new devices in the
host's devtmpfs mount. binderfs does however only make devices appear
under its own mountpoint and thus allocates new character device nodes
from the inode of the root dentry of the super block. This will have
the side-effect that binderfs specific device nodes do not appear in
sysfs. This behavior is similar to devpts allocated pts devices and
has no effect on the functionality of the ipc mechanism itself.
[1]: https://goo.gl/JL2tfX
[2]: program to allocate a new binderfs binder device:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/android/binder_ctl.h>
int main(int argc, char *argv[])
{
int fd, ret, saved_errno;
size_t len;
struct binderfs_device device = { 0 };
if (argc < 2)
exit(EXIT_FAILURE);
len = strlen(argv[1]);
if (len > BINDERFS_MAX_NAME)
exit(EXIT_FAILURE);
memcpy(device.name, argv[1], len);
fd = open("/dev/binderfs/binder-control", O_RDONLY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open binder-control device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
ret = ioctl(fd, BINDER_CTL_ADD, &device);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to allocate new binder device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
printf("Allocated new binder device with major %d, minor %d, and "
"name %s\n", device.major, device.minor,
device.name);
exit(EXIT_SUCCESS);
}
Cc: Martijn Coenen <maco@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-14 13:11:14 +01:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2025-05-17 17:09:56 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:45 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2018-11-30 20:26:30 -05:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-22 19:37:02 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-09-04 13:07:03 +02:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Fix function prototypes for module_param_call()
Several function prototypes for the set/get functions defined by
module_param_call() have a slightly wrong argument types. This fixes
those in an effort to clean up the calls when running under type-enforced
compiler instrumentation for CFI. This is the result of running the
following semantic patch:
@match_module_param_call_function@
declarer name module_param_call;
identifier _name, _set_func, _get_func;
expression _arg, _mode;
@@
module_param_call(_name, _set_func, _get_func, _arg, _mode);
@fix_set_prototype
depends on match_module_param_call_function@
identifier match_module_param_call_function._set_func;
identifier _val, _param;
type _val_type, _param_type;
@@
int _set_func(
-_val_type _val
+const char * _val
,
-_param_type _param
+const struct kernel_param * _param
) { ... }
@fix_get_prototype
depends on match_module_param_call_function@
identifier match_module_param_call_function._get_func;
identifier _val, _param;
type _val_type, _param_type;
@@
int _get_func(
-_val_type _val
+char * _val
,
-_param_type _param
+const struct kernel_param * _param
) { ... }
Two additional by-hand changes are included for places where the above
Coccinelle script didn't notice them:
drivers/platform/x86/thinkpad_acpi.c
fs/lockd/svc.c
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
2017-10-17 19:04:42 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-22 19:37:02 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-04-29 23:56:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
2018-01-23 12:04:27 -06:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-02 13:23:30 +08:00
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2024-01-31 21:53:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-11 20:14:51 +00:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-05 19:24:44 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-03-11 18:09:12 +08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:45 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-15 14:26:55 +00:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2016-10-24 15:20:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2016-10-24 15:20:29 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-22 15:05:11 +00:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:50 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:01:50 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2022-08-01 18:25:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
2017-08-31 10:04:26 +02:00
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-02 22:07:32 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-11 11:02:43 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
|
|
|
|
|
2019-06-12 13:29:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-12 13:29:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-11 11:02:43 +08:00
|
|
|
|
|
|
|
|
|
2019-06-12 13:29:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
ANDROID: binder: remove WARN() for redundant txn error
binder_send_failed_reply() is called when a synchronous
transaction fails. It reports an error to the thread that
is waiting for the completion. Given that the transaction
is synchronous, there should never be more than 1 error
response to that thread -- this was being asserted with
a WARN().
However, when exercising the driver with syzbot tests, cases
were observed where multiple "synchronous" requests were
sent without waiting for responses, so it is possible that
multiple errors would be reported to the thread. This testing
was conducted with panic_on_warn set which forced the crash.
This is easily reproduced by sending back-to-back
"synchronous" transactions without checking for any
response (eg, set read_size to 0):
bwr.write_buffer = (uintptr_t)&bc1;
bwr.write_size = sizeof(bc1);
bwr.read_buffer = (uintptr_t)&br;
bwr.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr);
sleep(1);
bwr2.write_buffer = (uintptr_t)&bc2;
bwr2.write_size = sizeof(bc2);
bwr2.read_buffer = (uintptr_t)&br;
bwr2.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr2);
sleep(1);
The first transaction is sent to the servicemanager and the reply
fails because no VMA is set up by this client. After
binder_send_failed_reply() is called, the BINDER_WORK_RETURN_ERROR
is sitting on the thread's todo list since the read_size was 0 and
the client is not waiting for a response.
The 2nd transaction is sent and the BINDER_WORK_RETURN_ERROR has not
been consumed, so the thread's reply_error.cmd is still set (normally
cleared when the BINDER_WORK_RETURN_ERROR is handled). Therefore
when the servicemanager attempts to reply to the 2nd failed
transaction, the error is already set and it triggers this warning.
This is a user error since it is not waiting for the synchronous
transaction to complete. If it ever does check, it will see an
error.
Changed the WARN() to a pr_warn().
Signed-off-by: Todd Kjos <tkjos@android.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-02-07 12:38:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
2020-07-24 18:43:48 +05:30
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-07-13 21:31:05 -03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-13 10:06:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2024-03-30 19:01:14 +00:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2024-03-30 19:01:14 +00:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-14 15:58:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-06 19:26:07 +00:00
|
|
|
|
2018-12-14 15:58:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-30 13:49:07 +01:00
|
|
|
|
2019-12-11 14:10:35 -07:00
|
|
|
|
2022-06-05 14:01:42 -04:00
|
|
|
|
|
|
|
|
|
2019-12-11 14:10:35 -07:00
|
|
|
|
task_work: cleanup notification modes
A previous commit changed the notification mode from true/false to an
int, allowing notify-no, notify-yes, or signal-notify. This was
backwards compatible in the sense that any existing true/false user
would translate to either 0 (on notification sent) or 1, the latter
which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2.
Clean this up properly, and define a proper enum for the notification
mode. Now we have:
- TWA_NONE. This is 0, same as before the original change, meaning no
notification requested.
- TWA_RESUME. This is 1, same as before the original change, meaning
that we use TIF_NOTIFY_RESUME.
- TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the
notification.
Clean up all the callers, switching their 0/1/false/true to using the
appropriate TWA_* mode for notifications.
Fixes: e91b48162332 ("task_work: teach task_work_add() to do signal_wake_up()")
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-10-16 09:02:26 -06:00
|
|
|
|
2019-12-11 14:10:35 -07:00
|
|
|
|
2018-12-14 15:58:21 -08:00
|
|
|
|
2019-12-11 14:10:35 -07:00
|
|
|
|
2018-12-14 15:58:21 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2021-08-30 12:51:46 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
|
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2016-10-24 15:20:29 +02:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2021-11-25 17:52:18 +05:30
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2021-10-15 16:38:11 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2017-09-25 12:52:11 +05:30
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-30 12:51:46 -07:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2021-08-30 12:51:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-07-04 10:54:48 +01:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:13 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:13 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:13 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2025-10-03 18:08:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-03 18:08:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-15 14:00:15 +02:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-15 14:00:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2022-04-15 14:00:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2021-12-07 13:24:42 +01:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:49 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-24 18:44:03 +05:30
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2020-07-24 18:44:03 +05:30
|
|
|
|
2018-01-23 12:04:27 -06:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
Binder: add TF_UPDATE_TXN to replace outdated txn
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-26 15:00:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-17 10:37:45 -08:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:08 +00:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:50 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2016-02-09 21:05:32 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
2023-04-24 19:05:14 +08:00
|
|
|
|
2024-12-06 14:57:13 -08:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-08 15:01:59 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:05 +00:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:01:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:56 -07:00
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-02 22:04:45 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2019-07-15 12:18:04 -07:00
|
|
|
|
2018-03-28 11:14:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
2025-06-05 14:19:29 +00:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
binder: Prevent context manager from incrementing ref 0
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-27 14:04:24 +02:00
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
binder: Prevent context manager from incrementing ref 0
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-27 14:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:13 -07:00
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2015-01-21 10:54:10 -05:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2015-01-21 10:54:10 -05:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2025-07-27 18:29:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:50 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:50 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2019-04-24 12:31:18 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2021-10-12 09:56:14 -07:00
|
|
|
|
2024-10-23 14:21:55 -07:00
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
2019-04-24 12:31:18 -07:00
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2019-04-24 12:31:18 -07:00
|
|
|
|
2020-10-26 19:03:14 +08:00
|
|
|
|
2019-04-24 12:31:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2017-02-03 14:40:50 -08:00
|
|
|
|
2023-12-01 17:21:41 +00:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-20 15:37:43 -08:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-02-08 10:35:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-09 13:09:23 +02:00
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
2016-02-09 21:05:32 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-22 18:23:52 +00:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
|
|
|
|
|
2016-02-09 21:05:32 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:16 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2016-10-24 15:20:29 +02:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2015-01-21 10:54:10 -05:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
2019-12-13 12:25:31 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:51 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-12-13 12:25:31 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:17 -08:00
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-07-04 10:54:48 +01:00
|
|
|
|
2017-02-03 14:40:45 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:50 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
2017-06-29 12:01:48 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
binder: fix freeze race
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the binder
interface.
But freezing an app requires 2 steps, freezing the binder interface with
ioctl(BINDER_FREEZE) and then freezing the application main threads with
cgroupfs. This is not an atomic operation. The following race issue
might happen.
1) Binder interface is frozen by ioctl(BINDER_FREEZE);
2) Main thread A initiates a new sync binder transaction to process B;
3) Main thread A is frozen by "echo 1 > cgroup.freeze";
4) The response from process B reaches the frozen thread, which will
unexpectedly fail.
This patch provides a mechanism to check if there's any new pending
transaction happening between ioctl(BINDER_FREEZE) and freezing the
main thread. If there's any, the main thread freezing operation can
be rolled back to finish the pending transaction.
Furthermore, the response might reach the binder driver before the
rollback actually happens. That will still cause failed transaction.
As the other process doesn't wait for another response of the response,
the response transaction failure can be fixed by treating the response
transaction like an oneway/async one, allowing it to reach the frozen
thread. And it will be consumed when the thread gets unfrozen later.
NOTE: This patch reuses the existing definition of struct
binder_frozen_status_info but expands the bit assignments of __u32
member sync_recv.
To ensure backward compatibility, bit 0 of sync_recv still indicates
there's an outstanding sync binder transaction. This patch adds new
information to bit 1 of sync_recv, indicating the binder transaction
happens exactly when there's a race.
If an existing userspace app runs on a new kernel, a sync binder call
will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still
return the expected value (true). The app just doesn't check bit 1
intentionally so it doesn't have the ability to tell if there's a race.
This behavior is aligned with what happens on an old kernel which
doesn't set bit 1 at all.
A new userspace app can 1) check bit 0 to know if there's a sync binder
transaction happened when being frozen - same as before; and 2) check
bit 1 to know if that sync binder transaction happened exactly when
there's a race - a new information for rollback decision.
the same time, confirmed the pending transactions succeeded.
Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
Acked-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Li Li <dualli@google.com>
Test: stress test with apps being frozen and initiating binder calls at
Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-10 09:42:10 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:01:37 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2022-04-29 23:56:44 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-09-05 10:21:52 -07:00
|
|
|
|
2017-02-03 14:40:49 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:52 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2021-11-30 10:51:52 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2021-08-30 12:51:46 -07:00
|
|
|
|
2019-02-08 10:35:20 -08:00
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:56 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-04-24 12:31:18 -07:00
|
|
|
|
2024-10-23 14:21:54 -07:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-11 11:02:43 +08:00
|
|
|
|
|
|
|
|
|
android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=<empty>)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Sherry Yang <sherryy@android.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-13 17:28:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
2017-06-29 12:01:56 -07:00
|
|
|
|
2017-09-29 15:39:49 -07:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:56 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2025-01-10 17:50:50 +00:00
|
|
|
|
2022-04-29 23:56:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-10 17:50:50 +00:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-05-17 18:58:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2025-10-03 18:08:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2025-10-03 18:08:49 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2025-10-03 18:08:49 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2018-09-25 14:30:36 +00:00
|
|
|
|
2021-08-30 12:51:46 -07:00
|
|
|
|
|
|
|
|
|
2021-10-15 16:38:11 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2019-06-12 13:29:27 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-12 13:29:27 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-05 20:30:20 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-02 08:18:40 +02:00
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2020-10-27 22:56:55 +00:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
binder: Prevent context manager from incrementing ref 0
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-27 14:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Prevent context manager from incrementing ref 0
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-27 14:04:24 +02:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:51 -07:00
|
|
|
|
|
|
|
|
|
2018-11-06 15:55:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2018-11-06 15:55:32 -08:00
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2018-11-06 15:55:32 -08:00
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2018-11-06 15:55:32 -08:00
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2018-11-06 15:55:32 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2021-10-15 16:38:11 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:50 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2016-02-17 09:32:52 +08:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-07 13:57:37 -08:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2022-05-09 23:19:01 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-02 08:18:40 +02:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
freezer,sched: Rewrite core freezer logic
Rewrite the core freezer to behave better wrt thawing and be simpler
in general.
By replacing PF_FROZEN with TASK_FROZEN, a special block state, it is
ensured frozen tasks stay frozen until thawed and don't randomly wake
up early, as is currently possible.
As such, it does away with PF_FROZEN and PF_FREEZER_SKIP, freeing up
two PF_flags (yay!).
Specifically; the current scheme works a little like:
freezer_do_not_count();
schedule();
freezer_count();
And either the task is blocked, or it lands in try_to_freezer()
through freezer_count(). Now, when it is blocked, the freezer
considers it frozen and continues.
However, on thawing, once pm_freezing is cleared, freezer_count()
stops working, and any random/spurious wakeup will let a task run
before its time.
That is, thawing tries to thaw things in explicit order; kernel
threads and workqueues before doing bringing SMP back before userspace
etc.. However due to the above mentioned races it is entirely possible
for userspace tasks to thaw (by accident) before SMP is back.
This can be a fatal problem in asymmetric ISA architectures (eg ARMv9)
where the userspace task requires a special CPU to run.
As said; replace this with a special task state TASK_FROZEN and add
the following state transitions:
TASK_FREEZABLE -> TASK_FROZEN
__TASK_STOPPED -> TASK_FROZEN
__TASK_TRACED -> TASK_FROZEN
The new TASK_FREEZABLE can be set on any state part of TASK_NORMAL
(IOW. TASK_INTERRUPTIBLE and TASK_UNINTERRUPTIBLE) -- any such state
is already required to deal with spurious wakeups and the freezer
causes one such when thawing the task (since the original state is
lost).
The special __TASK_{STOPPED,TRACED} states *can* be restored since
their canonical state is in ->jobctl.
With this, frozen tasks need an explicit TASK_FROZEN wakeup and are
free of undue (early / spurious) wakeups.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20220822114649.055452969@infradead.org
2022-08-22 13:18:22 +02:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:29 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2019-06-28 09:50:12 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-25 23:24:54 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-08 18:16:34 +04:00
|
|
|
|
2017-06-29 12:01:49 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-11-15 09:21:35 +01:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
2018-05-10 02:05:03 +00:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-10 02:05:03 +00:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-23 12:16:54 -08:00
|
|
|
|
|
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2019-06-21 10:54:15 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2019-02-08 10:35:15 -08:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-15 16:38:11 -07:00
|
|
|
|
2018-08-28 13:46:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:38 +00:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-13 10:06:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2017-11-13 10:06:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2025-04-01 20:28:46 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:54 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:52 -07:00
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2020-10-09 16:24:55 -07:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2020-10-09 16:24:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-09 16:24:55 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-13 10:06:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-22 17:51:37 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-16 15:29:54 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-21 14:40:26 -08:00
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:54 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-09 16:24:55 -07:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:18 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2020-10-09 16:24:55 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2020-06-22 13:07:15 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-22 13:07:15 -07:00
|
|
|
|
|
|
|
|
|
2025-05-24 22:07:58 +00:00
|
|
|
|
2020-06-22 13:07:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:12 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2018-11-06 15:56:31 -08:00
|
|
|
|
|
|
|
|
|
2018-01-05 11:27:07 +01:00
|
|
|
|
|
|
|
|
|
2021-12-08 17:04:52 -08:00
|
|
|
|
|
|
|
|
|
2018-01-05 11:27:07 +01:00
|
|
|
|
2021-12-08 17:04:52 -08:00
|
|
|
|
|
|
|
|
|
2018-01-05 11:27:07 +01:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2018-02-16 09:47:15 +01:00
|
|
|
|
2021-12-08 17:04:52 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-16 09:47:15 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-03 06:39:46 -04:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2018-01-30 23:11:24 -08:00
|
|
|
|
2023-12-01 17:21:30 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:06 -07:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
2017-10-09 14:26:56 +02:00
|
|
|
|
2018-02-11 14:34:03 -08:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-15 20:03:51 +08:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-04 17:42:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2023-05-04 17:42:24 -04:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-04 17:42:24 -04:00
|
|
|
|
|
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2021-10-12 09:56:13 -07:00
|
|
|
|
2015-01-21 10:54:10 -05:00
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
|
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-07 15:38:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: fix freeze race
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the binder
interface.
But freezing an app requires 2 steps, freezing the binder interface with
ioctl(BINDER_FREEZE) and then freezing the application main threads with
cgroupfs. This is not an atomic operation. The following race issue
might happen.
1) Binder interface is frozen by ioctl(BINDER_FREEZE);
2) Main thread A initiates a new sync binder transaction to process B;
3) Main thread A is frozen by "echo 1 > cgroup.freeze";
4) The response from process B reaches the frozen thread, which will
unexpectedly fail.
This patch provides a mechanism to check if there's any new pending
transaction happening between ioctl(BINDER_FREEZE) and freezing the
main thread. If there's any, the main thread freezing operation can
be rolled back to finish the pending transaction.
Furthermore, the response might reach the binder driver before the
rollback actually happens. That will still cause failed transaction.
As the other process doesn't wait for another response of the response,
the response transaction failure can be fixed by treating the response
transaction like an oneway/async one, allowing it to reach the frozen
thread. And it will be consumed when the thread gets unfrozen later.
NOTE: This patch reuses the existing definition of struct
binder_frozen_status_info but expands the bit assignments of __u32
member sync_recv.
To ensure backward compatibility, bit 0 of sync_recv still indicates
there's an outstanding sync binder transaction. This patch adds new
information to bit 1 of sync_recv, indicating the binder transaction
happens exactly when there's a race.
If an existing userspace app runs on a new kernel, a sync binder call
will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still
return the expected value (true). The app just doesn't check bit 1
intentionally so it doesn't have the ability to tell if there's a race.
This behavior is aligned with what happens on an old kernel which
doesn't set bit 1 at all.
A new userspace app can 1) check bit 0 to know if there's a sync binder
transaction happened when being frozen - same as before; and 2) check
bit 1 to know if that sync binder transaction happened exactly when
there's a race - a new information for rollback decision.
the same time, confirmed the pending transactions succeeded.
Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
Acked-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Li Li <dualli@google.com>
Test: stress test with apps being frozen and initiating binder calls at
Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-10 09:42:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:12 +00:00
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:12 +00:00
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
2024-09-26 23:36:12 +00:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:12 +00:00
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:13 +00:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:12 +00:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: fix freeze race
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the binder
interface.
But freezing an app requires 2 steps, freezing the binder interface with
ioctl(BINDER_FREEZE) and then freezing the application main threads with
cgroupfs. This is not an atomic operation. The following race issue
might happen.
1) Binder interface is frozen by ioctl(BINDER_FREEZE);
2) Main thread A initiates a new sync binder transaction to process B;
3) Main thread A is frozen by "echo 1 > cgroup.freeze";
4) The response from process B reaches the frozen thread, which will
unexpectedly fail.
This patch provides a mechanism to check if there's any new pending
transaction happening between ioctl(BINDER_FREEZE) and freezing the
main thread. If there's any, the main thread freezing operation can
be rolled back to finish the pending transaction.
Furthermore, the response might reach the binder driver before the
rollback actually happens. That will still cause failed transaction.
As the other process doesn't wait for another response of the response,
the response transaction failure can be fixed by treating the response
transaction like an oneway/async one, allowing it to reach the frozen
thread. And it will be consumed when the thread gets unfrozen later.
NOTE: This patch reuses the existing definition of struct
binder_frozen_status_info but expands the bit assignments of __u32
member sync_recv.
To ensure backward compatibility, bit 0 of sync_recv still indicates
there's an outstanding sync binder transaction. This patch adds new
information to bit 1 of sync_recv, indicating the binder transaction
happens exactly when there's a race.
If an existing userspace app runs on a new kernel, a sync binder call
will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still
return the expected value (true). The app just doesn't check bit 1
intentionally so it doesn't have the ability to tell if there's a race.
This behavior is aligned with what happens on an old kernel which
doesn't set bit 1 at all.
A new userspace app can 1) check bit 0 to know if there's a sync binder
transaction happened when being frozen - same as before; and 2) check
bit 1 to know if that sync binder transaction happened exactly when
there's a race - a new information for rollback decision.
the same time, confirmed the pending transactions succeeded.
Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
Acked-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Li Li <dualli@google.com>
Test: stress test with apps being frozen and initiating binder calls at
Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-10 09:42:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: fix freeze race
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the binder
interface.
But freezing an app requires 2 steps, freezing the binder interface with
ioctl(BINDER_FREEZE) and then freezing the application main threads with
cgroupfs. This is not an atomic operation. The following race issue
might happen.
1) Binder interface is frozen by ioctl(BINDER_FREEZE);
2) Main thread A initiates a new sync binder transaction to process B;
3) Main thread A is frozen by "echo 1 > cgroup.freeze";
4) The response from process B reaches the frozen thread, which will
unexpectedly fail.
This patch provides a mechanism to check if there's any new pending
transaction happening between ioctl(BINDER_FREEZE) and freezing the
main thread. If there's any, the main thread freezing operation can
be rolled back to finish the pending transaction.
Furthermore, the response might reach the binder driver before the
rollback actually happens. That will still cause failed transaction.
As the other process doesn't wait for another response of the response,
the response transaction failure can be fixed by treating the response
transaction like an oneway/async one, allowing it to reach the frozen
thread. And it will be consumed when the thread gets unfrozen later.
NOTE: This patch reuses the existing definition of struct
binder_frozen_status_info but expands the bit assignments of __u32
member sync_recv.
To ensure backward compatibility, bit 0 of sync_recv still indicates
there's an outstanding sync binder transaction. This patch adds new
information to bit 1 of sync_recv, indicating the binder transaction
happens exactly when there's a race.
If an existing userspace app runs on a new kernel, a sync binder call
will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still
return the expected value (true). The app just doesn't check bit 1
intentionally so it doesn't have the ability to tell if there's a race.
This behavior is aligned with what happens on an old kernel which
doesn't set bit 1 at all.
A new userspace app can 1) check bit 0 to know if there's a sync binder
transaction happened when being frozen - same as before; and 2) check
bit 1 to know if that sync binder transaction happened exactly when
there's a race - a new information for rollback decision.
the same time, confirmed the pending transactions succeeded.
Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
Acked-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Li Li <dualli@google.com>
Test: stress test with apps being frozen and initiating binder calls at
Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-10 09:42:10 -07:00
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: fix freeze race
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the binder
interface.
But freezing an app requires 2 steps, freezing the binder interface with
ioctl(BINDER_FREEZE) and then freezing the application main threads with
cgroupfs. This is not an atomic operation. The following race issue
might happen.
1) Binder interface is frozen by ioctl(BINDER_FREEZE);
2) Main thread A initiates a new sync binder transaction to process B;
3) Main thread A is frozen by "echo 1 > cgroup.freeze";
4) The response from process B reaches the frozen thread, which will
unexpectedly fail.
This patch provides a mechanism to check if there's any new pending
transaction happening between ioctl(BINDER_FREEZE) and freezing the
main thread. If there's any, the main thread freezing operation can
be rolled back to finish the pending transaction.
Furthermore, the response might reach the binder driver before the
rollback actually happens. That will still cause failed transaction.
As the other process doesn't wait for another response of the response,
the response transaction failure can be fixed by treating the response
transaction like an oneway/async one, allowing it to reach the frozen
thread. And it will be consumed when the thread gets unfrozen later.
NOTE: This patch reuses the existing definition of struct
binder_frozen_status_info but expands the bit assignments of __u32
member sync_recv.
To ensure backward compatibility, bit 0 of sync_recv still indicates
there's an outstanding sync binder transaction. This patch adds new
information to bit 1 of sync_recv, indicating the binder transaction
happens exactly when there's a race.
If an existing userspace app runs on a new kernel, a sync binder call
will set bit 0 of sync_recv so ioctl(BINDER_GET_FROZEN_INFO) still
return the expected value (true). The app just doesn't check bit 1
intentionally so it doesn't have the ability to tell if there's a race.
This behavior is aligned with what happens on an old kernel which
doesn't set bit 1 at all.
A new userspace app can 1) check bit 0 to know if there's a sync binder
transaction happened when being frozen - same as before; and 2) check
bit 1 to know if that sync binder transaction happened exactly when
there's a race - a new information for rollback decision.
the same time, confirmed the pending transactions succeeded.
Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
Acked-by: Todd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Li Li <dualli@google.com>
Test: stress test with apps being frozen and initiating binder calls at
Link: https://lore.kernel.org/r/20210910164210.2282716-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-10 09:42:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-18 09:17:54 +08:00
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
2022-05-18 09:17:54 +08:00
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
2022-05-18 09:17:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2022-11-15 20:03:51 +08:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2024-04-21 17:37:49 +00:00
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:07 -07:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2019-01-14 09:10:21 -08:00
|
|
|
|
2014-06-03 22:27:21 +03:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-04-15 12:03:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-15 12:03:05 +02:00
|
|
|
|
2018-09-07 15:38:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-06 21:37:25 +02:00
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 23:56:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:49 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2021-03-15 18:16:29 -07:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-30 22:35:43 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2025-07-14 11:53:17 -07:00
|
|
|
|
2014-06-02 18:17:59 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-14 11:53:17 -07:00
|
|
|
|
2014-06-02 18:17:59 +05:30
|
|
|
|
2015-09-09 15:39:26 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-06-02 18:17:59 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-29 09:52:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2023-01-26 11:37:49 -08:00
|
|
|
|
2018-05-07 23:15:37 +09:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-29 09:52:16 +08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-12-29 11:03:37 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: use bitmap for faster descriptor lookup
When creating new binder references, the driver assigns a descriptor id
that is shared with userspace. Regrettably, the driver needs to keep the
descriptors small enough to accommodate userspace potentially using them
as Vector indexes. Currently, the driver performs a linear search on the
rb-tree of references to find the smallest available descriptor id. This
approach, however, scales poorly as the number of references grows.
This patch introduces the usage of bitmaps to boost the performance of
descriptor assignments. This optimization results in notable performance
gains, particularly in processes with a large number of references. The
following benchmark with 100,000 references showcases the difference in
latency between the dbitmap implementation and the legacy approach:
[ 587.145098] get_ref_desc_olocked: 15us (dbitmap on)
[ 602.788623] get_ref_desc_olocked: 47343us (dbitmap off)
Note the bitmap size is dynamically adjusted in line with the number of
references, ensuring efficient memory usage. In cases where growing the
bitmap is not possible, the driver falls back to the slow legacy method.
A previous attempt to solve this issue was proposed in [1]. However,
such method involved adding new ioctls which isn't great, plus older
userspace code would not have benefited from the optimizations either.
Link: https://lore.kernel.org/all/20240417191418.1341988-1-cmllamas@google.com/ [1]
Cc: Tim Murray <timmurray@google.com>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: John Stultz <jstultz@google.com>
Cc: Steven Moreland <smoreland@google.com>
Suggested-by: Nick Chen <chenjia3@oppo.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240612042535.1556708-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-12 04:25:13 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:00 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:36 -07:00
|
|
|
|
|
|
|
|
|
2021-10-12 09:56:12 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: implement binderfs
As discussed at Linux Plumbers Conference 2018 in Vancouver [1] this is the
implementation of binderfs.
/* Abstract */
binderfs is a backwards-compatible filesystem for Android's binder ipc
mechanism. Each ipc namespace will mount a new binderfs instance. Mounting
binderfs multiple times at different locations in the same ipc namespace
will not cause a new super block to be allocated and hence it will be the
same filesystem instance.
Each new binderfs mount will have its own set of binder devices only
visible in the ipc namespace it has been mounted in. All devices in a new
binderfs mount will follow the scheme binder%d and numbering will always
start at 0.
/* Backwards compatibility */
Devices requested in the Kconfig via CONFIG_ANDROID_BINDER_DEVICES for the
initial ipc namespace will work as before. They will be registered via
misc_register() and appear in the devtmpfs mount. Specifically, the
standard devices binder, hwbinder, and vndbinder will all appear in their
standard locations in /dev. Mounting or unmounting the binderfs mount in
the initial ipc namespace will have no effect on these devices, i.e. they
will neither show up in the binderfs mount nor will they disappear when the
binderfs mount is gone.
/* binder-control */
Each new binderfs instance comes with a binder-control device. No other
devices will be present at first. The binder-control device can be used to
dynamically allocate binder devices. All requests operate on the binderfs
mount the binder-control device resides in.
Assuming a new instance of binderfs has been mounted at /dev/binderfs
via mount -t binderfs binderfs /dev/binderfs. Then a request to create a
new binder device can be made as illustrated in [2].
Binderfs devices can simply be removed via unlink().
/* Implementation details */
- dynamic major number allocation:
When binderfs is registered as a new filesystem it will dynamically
allocate a new major number. The allocated major number will be returned
in struct binderfs_device when a new binder device is allocated.
- global minor number tracking:
Minor are tracked in a global idr struct that is capped at
BINDERFS_MAX_MINOR. The minor number tracker is protected by a global
mutex. This is the only point of contention between binderfs mounts.
- struct binderfs_info:
Each binderfs super block has its own struct binderfs_info that tracks
specific details about a binderfs instance:
- ipc namespace
- dentry of the binder-control device
- root uid and root gid of the user namespace the binderfs instance
was mounted in
- mountable by user namespace root:
binderfs can be mounted by user namespace root in a non-initial user
namespace. The devices will be owned by user namespace root.
- binderfs binder devices without misc infrastructure:
New binder devices associated with a binderfs mount do not use the
full misc_register() infrastructure.
The misc_register() infrastructure can only create new devices in the
host's devtmpfs mount. binderfs does however only make devices appear
under its own mountpoint and thus allocates new character device nodes
from the inode of the root dentry of the super block. This will have
the side-effect that binderfs specific device nodes do not appear in
sysfs. This behavior is similar to devpts allocated pts devices and
has no effect on the functionality of the ipc mechanism itself.
[1]: https://goo.gl/JL2tfX
[2]: program to allocate a new binderfs binder device:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/android/binder_ctl.h>
int main(int argc, char *argv[])
{
int fd, ret, saved_errno;
size_t len;
struct binderfs_device device = { 0 };
if (argc < 2)
exit(EXIT_FAILURE);
len = strlen(argv[1]);
if (len > BINDERFS_MAX_NAME)
exit(EXIT_FAILURE);
memcpy(device.name, argv[1], len);
fd = open("/dev/binderfs/binder-control", O_RDONLY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open binder-control device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
ret = ioctl(fd, BINDER_CTL_ADD, &device);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to allocate new binder device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
printf("Allocated new binder device with major %d, minor %d, and "
"name %s\n", device.major, device.minor,
device.name);
exit(EXIT_SUCCESS);
}
Cc: Martijn Coenen <maco@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-14 13:11:14 +01:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
2020-03-03 17:43:40 +01:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: implement binderfs
As discussed at Linux Plumbers Conference 2018 in Vancouver [1] this is the
implementation of binderfs.
/* Abstract */
binderfs is a backwards-compatible filesystem for Android's binder ipc
mechanism. Each ipc namespace will mount a new binderfs instance. Mounting
binderfs multiple times at different locations in the same ipc namespace
will not cause a new super block to be allocated and hence it will be the
same filesystem instance.
Each new binderfs mount will have its own set of binder devices only
visible in the ipc namespace it has been mounted in. All devices in a new
binderfs mount will follow the scheme binder%d and numbering will always
start at 0.
/* Backwards compatibility */
Devices requested in the Kconfig via CONFIG_ANDROID_BINDER_DEVICES for the
initial ipc namespace will work as before. They will be registered via
misc_register() and appear in the devtmpfs mount. Specifically, the
standard devices binder, hwbinder, and vndbinder will all appear in their
standard locations in /dev. Mounting or unmounting the binderfs mount in
the initial ipc namespace will have no effect on these devices, i.e. they
will neither show up in the binderfs mount nor will they disappear when the
binderfs mount is gone.
/* binder-control */
Each new binderfs instance comes with a binder-control device. No other
devices will be present at first. The binder-control device can be used to
dynamically allocate binder devices. All requests operate on the binderfs
mount the binder-control device resides in.
Assuming a new instance of binderfs has been mounted at /dev/binderfs
via mount -t binderfs binderfs /dev/binderfs. Then a request to create a
new binder device can be made as illustrated in [2].
Binderfs devices can simply be removed via unlink().
/* Implementation details */
- dynamic major number allocation:
When binderfs is registered as a new filesystem it will dynamically
allocate a new major number. The allocated major number will be returned
in struct binderfs_device when a new binder device is allocated.
- global minor number tracking:
Minor are tracked in a global idr struct that is capped at
BINDERFS_MAX_MINOR. The minor number tracker is protected by a global
mutex. This is the only point of contention between binderfs mounts.
- struct binderfs_info:
Each binderfs super block has its own struct binderfs_info that tracks
specific details about a binderfs instance:
- ipc namespace
- dentry of the binder-control device
- root uid and root gid of the user namespace the binderfs instance
was mounted in
- mountable by user namespace root:
binderfs can be mounted by user namespace root in a non-initial user
namespace. The devices will be owned by user namespace root.
- binderfs binder devices without misc infrastructure:
New binder devices associated with a binderfs mount do not use the
full misc_register() infrastructure.
The misc_register() infrastructure can only create new devices in the
host's devtmpfs mount. binderfs does however only make devices appear
under its own mountpoint and thus allocates new character device nodes
from the inode of the root dentry of the super block. This will have
the side-effect that binderfs specific device nodes do not appear in
sysfs. This behavior is similar to devpts allocated pts devices and
has no effect on the functionality of the ipc mechanism itself.
[1]: https://goo.gl/JL2tfX
[2]: program to allocate a new binderfs binder device:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/android/binder_ctl.h>
int main(int argc, char *argv[])
{
int fd, ret, saved_errno;
size_t len;
struct binderfs_device device = { 0 };
if (argc < 2)
exit(EXIT_FAILURE);
len = strlen(argv[1]);
if (len > BINDERFS_MAX_NAME)
exit(EXIT_FAILURE);
memcpy(device.name, argv[1], len);
fd = open("/dev/binderfs/binder-control", O_RDONLY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open binder-control device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
ret = ioctl(fd, BINDER_CTL_ADD, &device);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to allocate new binder device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
printf("Allocated new binder device with major %d, minor %d, and "
"name %s\n", device.major, device.minor,
device.name);
exit(EXIT_SUCCESS);
}
Cc: Martijn Coenen <maco@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-14 13:11:14 +01:00
|
|
|
|
|
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
2020-03-03 17:43:40 +01:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2017-12-22 19:37:02 +05:30
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
|
|
|
|
|
2018-11-30 20:26:30 -05:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-10 16:44:01 +01:00
|
|
|
|
|
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2017-06-29 12:01:49 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
2024-05-08 23:15:55 -04:00
|
|
|
|
2019-09-03 09:16:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:01 -07:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
|
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-17 13:58:29 -08:00
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:19 +02:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-03-12 11:42:02 +01:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:46 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2021-03-15 18:16:28 -07:00
|
|
|
|
2021-03-15 18:16:30 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2013-03-12 11:41:59 +01:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2013-03-12 11:42:00 +01:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:18 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2013-03-12 11:42:02 +01:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:30:23 +09:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-13 22:16:24 +05:30
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
2023-04-24 19:05:14 +08:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2025-07-27 18:29:05 +00:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2023-04-24 19:05:15 +08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2025-07-27 18:29:05 +00:00
|
|
|
|
2023-04-24 19:05:14 +08:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
2023-12-01 17:21:55 +00:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2025-03-25 18:49:00 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2024-09-26 23:36:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
2017-06-29 12:01:49 -07:00
|
|
|
|
2017-06-29 12:01:57 -07:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-04 17:49:34 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:59 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2018-12-05 15:19:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:02:09 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2024-09-26 23:36:19 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-12-22 09:00:45 +10:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-09 17:40:45 +08:00
|
|
|
|
|
|
|
|
|
2021-04-09 17:40:46 +08:00
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-12-22 09:00:45 +10:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2012-12-22 09:00:45 +10:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: frozen notification
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-09 00:00:47 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:44 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-31 10:04:18 +02:00
|
|
|
|
2017-06-29 12:02:05 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:04 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:58 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:08 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:40 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-08-31 11:56:36 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:02 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2025-05-10 01:34:38 +00:00
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-06-29 12:02:03 -07:00
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:11 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-27 17:06:00 -08:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-06-29 12:02:11 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:02:11 -07:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2018-11-30 20:26:30 -05:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2016-02-09 21:05:33 -08:00
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2016-02-09 21:05:33 -08:00
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2016-02-09 21:05:33 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:47 -08:00
|
|
|
|
2017-06-29 12:01:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
binder: implement binderfs
As discussed at Linux Plumbers Conference 2018 in Vancouver [1] this is the
implementation of binderfs.
/* Abstract */
binderfs is a backwards-compatible filesystem for Android's binder ipc
mechanism. Each ipc namespace will mount a new binderfs instance. Mounting
binderfs multiple times at different locations in the same ipc namespace
will not cause a new super block to be allocated and hence it will be the
same filesystem instance.
Each new binderfs mount will have its own set of binder devices only
visible in the ipc namespace it has been mounted in. All devices in a new
binderfs mount will follow the scheme binder%d and numbering will always
start at 0.
/* Backwards compatibility */
Devices requested in the Kconfig via CONFIG_ANDROID_BINDER_DEVICES for the
initial ipc namespace will work as before. They will be registered via
misc_register() and appear in the devtmpfs mount. Specifically, the
standard devices binder, hwbinder, and vndbinder will all appear in their
standard locations in /dev. Mounting or unmounting the binderfs mount in
the initial ipc namespace will have no effect on these devices, i.e. they
will neither show up in the binderfs mount nor will they disappear when the
binderfs mount is gone.
/* binder-control */
Each new binderfs instance comes with a binder-control device. No other
devices will be present at first. The binder-control device can be used to
dynamically allocate binder devices. All requests operate on the binderfs
mount the binder-control device resides in.
Assuming a new instance of binderfs has been mounted at /dev/binderfs
via mount -t binderfs binderfs /dev/binderfs. Then a request to create a
new binder device can be made as illustrated in [2].
Binderfs devices can simply be removed via unlink().
/* Implementation details */
- dynamic major number allocation:
When binderfs is registered as a new filesystem it will dynamically
allocate a new major number. The allocated major number will be returned
in struct binderfs_device when a new binder device is allocated.
- global minor number tracking:
Minor are tracked in a global idr struct that is capped at
BINDERFS_MAX_MINOR. The minor number tracker is protected by a global
mutex. This is the only point of contention between binderfs mounts.
- struct binderfs_info:
Each binderfs super block has its own struct binderfs_info that tracks
specific details about a binderfs instance:
- ipc namespace
- dentry of the binder-control device
- root uid and root gid of the user namespace the binderfs instance
was mounted in
- mountable by user namespace root:
binderfs can be mounted by user namespace root in a non-initial user
namespace. The devices will be owned by user namespace root.
- binderfs binder devices without misc infrastructure:
New binder devices associated with a binderfs mount do not use the
full misc_register() infrastructure.
The misc_register() infrastructure can only create new devices in the
host's devtmpfs mount. binderfs does however only make devices appear
under its own mountpoint and thus allocates new character device nodes
from the inode of the root dentry of the super block. This will have
the side-effect that binderfs specific device nodes do not appear in
sysfs. This behavior is similar to devpts allocated pts devices and
has no effect on the functionality of the ipc mechanism itself.
[1]: https://goo.gl/JL2tfX
[2]: program to allocate a new binderfs binder device:
#define _GNU_SOURCE
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/android/binder_ctl.h>
int main(int argc, char *argv[])
{
int fd, ret, saved_errno;
size_t len;
struct binderfs_device device = { 0 };
if (argc < 2)
exit(EXIT_FAILURE);
len = strlen(argv[1]);
if (len > BINDERFS_MAX_NAME)
exit(EXIT_FAILURE);
memcpy(device.name, argv[1], len);
fd = open("/dev/binderfs/binder-control", O_RDONLY | O_CLOEXEC);
if (fd < 0) {
printf("%s - Failed to open binder-control device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
ret = ioctl(fd, BINDER_CTL_ADD, &device);
saved_errno = errno;
close(fd);
errno = saved_errno;
if (ret < 0) {
printf("%s - Failed to allocate new binder device\n",
strerror(errno));
exit(EXIT_FAILURE);
}
printf("Allocated new binder device with major %d, minor %d, and "
"name %s\n", device.major, device.minor,
device.name);
exit(EXIT_SUCCESS);
}
Cc: Martijn Coenen <maco@android.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-14 13:11:14 +01:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-11 21:59:08 +02:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
binder: Create safe versions of binder log files
Binder defines several seq_files that can be accessed via debugfs or
binderfs. Some of these files (e.g., 'state' and 'transactions')
contain more granular information about binder's internal state that
is helpful for debugging, but they also leak userspace address data
through user-defined 'cookie' or 'ptr' values. Consequently, access
to these files must be heavily restricted.
Add two new files, 'state_hashed' and 'transactions_hashed', that
reproduce the information in the original files but use the kernel's
raw pointer obfuscation to hash any potential user addresses. This
approach allows systems to grant broader access to the new files
without having to change the security policy around the existing ones.
In practice, userspace populates these fields with user addresses, but
within the driver, these values only serve as unique identifiers for
their associated binder objects. Consequently, binder logs can
obfuscate these values and still retain meaning. While this strategy
prevents leaking information about the userspace memory layout in the
existing log files, it also decouples log messages about binder
objects from their user-defined identifiers.
Acked-by: Carlos Llamas <cmllamas@google.com>
Tested-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: "Tiffany Y. Yang" <ynaffit@google.com>
Link: https://lore.kernel.org/r/20250510013435.1520671-7-ynaffit@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-10 01:34:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-18 13:29:34 -08:00
|
|
|
|
|
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2024-12-18 13:29:34 -08:00
|
|
|
|
2025-05-17 17:09:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-26 10:30:54 +03:00
|
|
|
|
2025-05-17 17:09:56 +00:00
|
|
|
|
2024-12-18 13:29:34 -08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-03 17:43:40 +01:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2017-06-29 12:01:43 -07:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-17 17:09:56 +00:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-31 01:25:02 +01:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2019-01-31 01:25:02 +01:00
|
|
|
|
2023-07-13 16:06:37 +08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
2017-11-29 22:29:47 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-23 08:46:42 -07:00
|
|
|
|
2017-06-29 12:01:53 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-28 20:57:50 -07:00
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
2023-07-13 16:06:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-01 18:20:41 +00:00
|
|
|
|
2023-07-13 16:06:37 +08:00
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2019-09-04 13:07:03 +02:00
|
|
|
|
|
|
|
|
|
2019-01-26 11:23:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2019-01-26 11:23:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
2019-01-31 01:25:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2025-07-27 18:29:06 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-17 17:09:56 +00:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2017-08-21 16:13:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
|
|
|
|
|
2023-06-25 15:49:37 +00:00
|
|
|
|
2017-02-03 14:40:48 -08:00
|
|
|
|
2011-11-30 20:18:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-16 15:29:53 -07:00
|
|
|
|
|
|
|
|
|
