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] [day] [month] [year] [list]
Message-ID: <d8552b13-dbbb-7e4b-9e56-3264435d9225@linux.microsoft.com>
Date:   Fri, 5 Jun 2020 09:20:06 -0700
From:   Jordan Hand <jorhand@...ux.microsoft.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: [PATCH] software node: recursively unregister child swnodes



On 6/5/20 12:54 AM, Greg Kroah-Hartman wrote:
> Right now, the way the driver model and sysfs/kobjects work is that all
> objects must be removed in child-first order.  The problem of your
> change where you want to try to remove the devices in parent-first order
> is that you do not really know if you still have a reference to a child
> device somewhere else, which would prevent this all from happening
> correctly, right?
> 
> So if you "know" it is safe to drop a child, that's great, and expected.
> Don't work to make  this one tiny user of the kobjects (which I'm still
> not quite sure why they are kobjects and not devices), do things in a
> different way from the rest of the kernel without a strong reason to do
> so.
> 
> thanks,
> 
> greg k-h
> 

I see, thanks for taking the time to explain, the reason for the 
existing behavior is more clear to me now. I agree it is better to have 
the caller remove the nodes in the correct order rather than having the 
swnode infrastructure try to have some special behavior.

Thanks,
Jordan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ