summaryrefslogtreecommitdiff
path: root/kernel/latencytop.c
diff options
context:
space:
mode:
authorEvgeniy Polyakov <zbr@ioremap.net>2010-02-02 23:58:48 (GMT)
committerDavid S. Miller <davem@davemloft.net>2010-02-02 23:58:48 (GMT)
commitf98bfbd78c37c5946cc53089da32a5f741efdeb7 (patch)
tree885c756a95f28d4d00868f6eb06ab9c45f11b2e2 /kernel/latencytop.c
parenta4c89051c83693e6cd5655b90300ec23a35e04f1 (diff)
downloadlinux-fsl-qoriq-f98bfbd78c37c5946cc53089da32a5f741efdeb7.tar.xz
connector: Delete buggy notification code.
On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this? Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered. Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the code. Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'kernel/latencytop.c')
0 files changed, 0 insertions, 0 deletions