On Sun, Dec 23, 2018 at 6:36 AM Christian Brauner <christian@xxxxxxxxxx> wrote: > > The binderfs instance in the initial ipc namespace will always have a > reserve of 4 binder devices unless explicitly capped by specifying a lower > value via the "max" mount option. > This ensures when binder devices are removed (on accident or on purpose) > they can always be recreated without risking that all minor numbers have > already been used up. > > Cc: Todd Kjos <tkjos@xxxxxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Christian Brauner <christian.brauner@xxxxxxxxxx> > --- > v1: > - patch introduced > v0: > - patch not present > --- > drivers/android/binderfs.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c > index 873adda064ac..aa635c7ea727 100644 > --- a/drivers/android/binderfs.c > +++ b/drivers/android/binderfs.c > @@ -40,6 +40,8 @@ > #define INODE_OFFSET 3 > #define INTSTRLEN 21 > #define BINDERFS_MAX_MINOR (1U << MINORBITS) > +/* Ensure that the initial ipc namespace always has a devices available. */ > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4) Why do you ever need more minors per instance than the number of devices listed in CONFIG_ANDROID_BINDER_DEVICES? > > static struct vfsmount *binderfs_mnt; > > @@ -129,11 +131,14 @@ static int binderfs_binder_device_create(struct inode *ref_inode, > struct inode *inode = NULL; > struct super_block *sb = ref_inode->i_sb; > struct binderfs_info *info = sb->s_fs_info; > + bool use_reserve = (info->ipc_ns == &init_ipc_ns); > > /* Reserve new minor number for the new device. */ > mutex_lock(&binderfs_minors_mutex); > if (++info->device_count <= info->mount_opts.max) > - minor = ida_alloc_max(&binderfs_minors, BINDERFS_MAX_MINOR, > + minor = ida_alloc_max(&binderfs_minors, > + use_reserve ? BINDERFS_MAX_MINOR : > + BINDERFS_MAX_MINOR_CAPPED, > GFP_KERNEL); > else > minor = -ENOSPC; > -- > 2.19.1 > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
