-----Original Message-----
From: chetan loke [mailto:loke.chetan@gmail.com]
Sent: Monday, March 26, 2012 10:12 AM
To: Richard Cochran
Cc: Keller, Jacob E; netdev@vger.kernel.org; e1000-
devel@lists.sourceforge.net; Kirsher, Jeffrey T; Ronciak, John;
john.stultz@linaro.org; tglx@linutronix.de
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
timecompare method

You are confusing 'blocking the driver's fast path' with
performance/optimization etc. We cannot let user-space code jam the system.
Kernel code should be designed such that
bugs(intentional/unintentional) in user-space code cannot cause system wide
adverse affects. Period.

I agree. But I also think a test case should be in order here. What actually
happens with a badly designed user app cramming ioctls. (Note that under most
system designs the ioctls require root access unless you change the default
permissions.)

Does your existing design limit (ab)users from pounding the ioctls?

As I mentioned earlier, it could be possible to take care of gettime and the
driver's Rx/Tx path by using a mixture of locks/kernel-thread.
But settime/adjtime still needs to be curbed.

I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the
kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
path, because if we take too long the software sees it as a dropped timestamp.
Also we have a pointer to the skb which is free'd right after the call for
(rx/tx)hwtstamp so we can't just copy that pointer.

Why isn't ioctl-rate limiting acceptable? Let's say an app that is trying to
set/adj NIC counter is running on host side then how often would it need to
read and correct/set/adj? once every msec(so 1000 times a second), once every
10 msec(100 times a second) etc?

So, will pounding the ioctl 1000 times, while processing ~820K
frames(1500 byte payload on 10G link) still cause a problem for the driver is
what we would need to see. rate can also be a factor of link-speed(?).

And we don't need 100 such apps. Only 1 app should be working in tandem with
the NIC. If other apps fail then atleast the sysadmin or users would know
someone else is (ab)using it.

How would we only allow one app? Any app with permissions could call the ioctls.
I do agree that having too many ioctls is a problem. Even in cases where PTP is
only enabled on a "trusted" system. Allowing the kernel to assume the system
is trusted means we introduce security holes. I am not sure of the right solution
or whether we need a different one, though. I am going to try and provide a test case
where someone hammers the ioctls in a loop, and see what happens.

quoted

Thanks,
Richard

Chetan