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

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: <1276118920.11199.53.camel@powerslave>
Date:	Thu, 10 Jun 2010 00:28:40 +0300
From:	Luciano Coelho <luciano.coelho@...ia.com>
To:	ext Jan Engelhardt <jengelh@...ozas.de>
Cc:	ext Patrick McHardy <kaber@...sh.net>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Timo Teras <timo.teras@....fi>
Subject: Re: [PATCH v3] netfilter: Xtables: idletimer target implementation

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html