On Mon, Apr 29, 2013 at 05:21:17PM -0700, Greg Kroah-Hartman wrote: > On Mon, Apr 29, 2013 at 05:14:45PM -0700, Simon Kirby wrote: > > On Mon, Apr 29, 2013 at 12:01:44PM -0700, Greg Kroah-Hartman wrote: > > > > > 3.8-stable review patch. If anyone has any objections, please let me know. > > > > I object. This breaks functionality I use every day (seeing who else is > > working on stuff with "w"). > > > > Furthermore, the patch does not actually fix the hole referenced (see > > ptmx-keystroke-latency.c on http://vladz.devzero.fr/013_ptmx-timing.php). > > I can still reproduce the timing capture even with this patch applied > > (in 3.9-rc8). > > How? There are no keystrokes being reported to other users, or did we > miss something with this patch? wget http://vladz.devzero.fr/svn/codes/PoC/ptmx-keystroke-latency.c gcc -O ptmx-keystroke-latency ptmx-keystroke-latency.c ./ptmx-keystroke-latency Log in to another tty, as another user. See keystroke timing. 3.9-rc8. Seems like it was missed. Meanwhile, idle times in "w" do not update. > > The grsec patch instead introdues another test within the inotify code > > (is_sidechannel_device()-related bits) -- untested by me, but probably > > more relevant. > > > > Even 37b7f3c76595e23257f61bd80b223de8658617ee, the "regression fix", > > which Linus merged in for the 3.9 release, is still a regression for me. > > And I applied that one as well. Right, so this restores updates but increases the granularity to 60 seconds. I'm complaining that this is still affects my occupational performance. > > 60 seconds means somebody is asleep in my environment, and so is still > > the kind of thing that just pisses me off. I'd rather revert this whole > > thing. > > Users taking a break for longer than a minute upset you? What are you > really trying to keep track of here? Really? In a team environment, a person idle for 30 seconds means they've stopped to look at something else. Now we have to wait 2 minutes to know if this has happened or not. Now it becomes faster to interrupt somebody to ask them if maintenance can be done, etc. > > I'd stand maybe 1 seconds as maximum granularity. You could do that with > > less code and no test. > > Patch to show this? I was thinking of just updating the seconds field of the timespec struct, or leaving this particular part and setting sb->s_time_gran to 100000000, though that would probably break other things. Since I've never looked at this stuff before, I'm not sure I should make a patch, but I can... Simon- -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html