On Tue, Aug 13, 2024 at 3:42 PM Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
>
> On Tue, Aug 13, 2024 at 3:02 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> >
> > On Tue, 2024-08-13 at 14:30 +0200, Christian Brauner wrote:
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index fd34b5755c0b..319c566a9e98 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -947,6 +947,7 @@ static inline unsigned imajor(const struct inode *inode)
> > > }
> > >
> > > struct fown_struct {
> > > + struct file *file; /* backpointer for security modules */
> >
> > This struct was 32 bytes before (on x86_64). Now it'll be 40. That's
> > fine, but it may be worthwhile to create a dedicated slabcache for this
> > now, since it's no longer a power-of-2 size.
> >
>
> creating a dedicated slab would be a waste imo
>
> If someone is concerned with memory usage here, I note that plausibly
> the file pointer can be plumbed through sigio code, eliding any use of
> the newly added ->file
>
> However, a real daredevil would check if the thing to do is perhaps to
> add a 48-byte malloc slab. But that would require quite a bit of
> looking at allocations elsewhere, collecting stats and whatnot. Noting
> this just in case, I have negative interest in looking at this.
>
Some massaging of the struct brings me back to 32 bytes despite the pointer:
- rwlock -> spinlock
- signum int->short
- pid_type to 1 byte enum
but I don't think making this work is necessary at this point
struct fown_struct_poc {
struct file * file; /* 0 8 */
spinlock_t lock; /* 8 4 */
short int signum; /* 12 2 */
/* Bitfield combined with previous fields */
enum pid_type pid_type:8; /* 12:16 4 */
/* XXX 8 bits hole, try to pack */
struct pid * pid; /* 16 8 */
kuid_t uid; /* 24 4 */
kuid_t euid; /* 28 4 */
/* size: 32, cachelines: 1, members: 7 */
/* sum members: 30 */
/* sum bitfield members: 8 bits, bit holes: 1, sum bit holes: 8 bits */
/* last cacheline: 32 bytes */
};
--
Mateusz Guzik <mjguzik gmail.com>
