Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

On Mon, 2005-04-25 at 15:22 -0500, Dmitry Torokhov wrote:
> On 4/25/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > While thinking about locking schema
> > with respect to sysfs files I recalled,
> > why I implemented such a logic -
> > now one can _always_ remove _any_ module
> > [corresponding object is removed from accessible
> > pathes and waits untill all exsting users are gone],
> > which is very good - I really like it in networking model,
> > while with whole device driver model
> > if we will read device's file very quickly
> > in several threads we may end up not unloading it at all.
> 
> I am sorrry, that is complete bull*. sysfs also allows removing
> modules at an arbitrary time (and usually without annoying "waiting
> for refcount" at that)... You just seem to not understand how driver
> code works, thus the need of inventing your own schema.

Ok, let's try again - now with explanation, 
since it looks like you did not even try to understand what I said.
If you will remove objects from ->remove() callback
you may end up with rmmod being stuck.
Explanation: each read still gets reference counter, 
while in rmmod path there is a wait until it is zero.
If there are too many simultaneous reads - even
if each will put reference counter at the end, we still can have
non zero refcnt each time we check it in rmmod path.
That is why object must be removed from accessible pathes
first, and only freed in ->remove() callback.

> BTW, I am looking at the connector code ATM and I am just amazed at
> all wied refounting stuff that is going on there. what a single
> actomic_dec_and_test() call without checkng reurn vaue is supposed to
> do again?

It has explicit barrieres, which guarantees that
there will not be atomic operation vs. non atomic
reordering. 

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]