Re: [PATCH v3] netfilter: Xtables: idletimer target implementation

[Luciano Coelho <luciano.coelho@nokia.com>]

On Wed, 2010-06-09 at 23:05 +0200, ext Jan Engelhardt wrote:
> On Wednesday 2010-06-09 20:42, Luciano Coelho wrote:
> >
> >> I'll move the sysfs file creation to outside that function so I can keep
> >> the lock until after the timer is added to the list.  Thanks for
> >> clarifying!
> >
> >Hmmm... after struggling with this for a while, I think it's not really
> >possible to simply create the sysfs file outside of the lock, because if
> >the sysfs creation fails, we will again risk a race condition.
> 
> Well if sysfs_add can return an error code when a file already
> exists (instead of adding it again), it's much easier. Try checking.

Unfortunately sysfs_add and sysfs_create will throw a kernel warning if
we try to create a file that already exists.  But this was not really
the problem.

Now I just throw an WARN_ON if the sysfs file creation fails, the other
sysfs functions I'm calling can handle this situation.  This shouldn't
happen in normal cases and, if it does, the timer will run normally, but
there won't be a sysfs file associated with it (and there won't be any
notification).

As I just wrote in another email, I thought I had figured out a way to
do it without a workqueue.  But now that I looked into the code again, I
think there might still be some race conditions... For example: If
someone deletes the timer immediately after I released the lock and
before I created the sysfs entry... The deletion won't cause problems if
the file is not there, it will just nop.  But the creation of the file
after the timer has been deleted will cause the file to be dangling in
sysfs without any timer associated with it... :(


-- 
Cheers,
Luca.