linux-ext4 - Re: [PATCH 0/3] Improve kobject handling in fs/ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171128105011.GB83442@rschirone-mbp.local>
Date:   Tue, 28 Nov 2017 11:50:11 +0100
From:   "Riccardo S." <sirmy15@...il.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        gregkh@...uxfoundation.org
Subject: Re: [PATCH 0/3] Improve kobject handling in fs/ext4

On 11/27, Theodore Ts'o wrote:
> On Tue, Nov 28, 2017 at 12:17:58AM +0100, Riccardo Schirone wrote:
> > This patch tries to correctly use kobjects in fs/ext4. In particular it
> > allocates kobjects/ksets dynamically, instead of statically, and improve
> > error handling in case kobject_* functions fail.
> 
> I don't see the point of allocating the kobjects in question
> dynamically?  There is only one of them, so why not use static
> allocation?  What is "incorrect" about not doing dynamically allocated
> kobjects/ksets?
> 
> Regards,
> 
> 						- Ted

According to Documentation/kobject.txt that's how they should be
allocated.  The reason for this being they are dynamic objects, so you
don't really know what is their life time. Other parts of the kernel
could get a reference to those kobjects (since they are registered in
the system) and it's not said the module is the last one to access them.

If you declare them statically, what would happen when you remove the
module that statically defines them? What if there's still someone
holding a reference to one of those kobjects?

Regards,

Riccardo