[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Mar 2018 10:40:34 -0700
From: J Freyensee <why2jjj.linux@...il.com>
To: Igor Stoppa <igor.stoppa@...wei.com>, Matthew Wilcox <willy@...radead.org>
Cc: david@...morbit.com, rppt@...ux.vnet.ibm.com, keescook@...omium.org,
mhocko@...nel.org, labbott@...hat.com,
linux-security-module@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 5/8] Protectable Memory
>>> +struct pmalloc_data {
>>> + struct gen_pool *pool; /* Link back to the associated pool. */
>>> + bool protected; /* Status of the pool: RO or RW. */
>>> + struct kobj_attribute attr_protected; /* Sysfs attribute. */
>>> + struct kobj_attribute attr_avail; /* Sysfs attribute. */
>>> + struct kobj_attribute attr_size; /* Sysfs attribute. */
>>> + struct kobj_attribute attr_chunks; /* Sysfs attribute. */
>>> + struct kobject *pool_kobject;
>>> + struct list_head node; /* list of pools */
>>> +};
>> sysfs attributes aren't free, you know. I appreciate you want something
>> to help debug / analyse, but having one file for the whole subsystem or
>> at least one per pool would be a better idea.
> Which means that it should not be normal sysfs, but rather debugfs, if I
> understand correctly, since in sysfs 1 value -> 1 file.
Yes, that is a good idea, to use debugfs so you still have a means to
debug/analyze but can be also turned off for normal system execution.
Sorry I didn't think about that earlier to save a revision, that's one
of my favorite things I like to use for diagnosis.
Jay
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
