linux-kernel - Re: [RFC PATCH] tty, add kref to sysrq handlers

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]

Date:	Fri, 27 Apr 2012 18:39:22 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Prarit Bhargava <prarit@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] tty, add kref to sysrq handlers

> If the lock were removed, however, there is one _unlikely_ circumstance in
> which the array would be left unprotected.  That would be the situation in
> which a module was loaded and the sysrq handler was registered during the
> execution of the module.  Again, the possibility of the scenario is very
> small and given the existing usage of unregister_sysrq_key() in the tree
> it seems like removing the lock is sufficient.

It's asking for later disasters I think.

I'm not sure I see we need a kref - that looks like overkill, and its
probably even more elegantly done with RCU ?

> Of course, I'm more than willing to hear additional suggestions.  A rw
> lock still requires that it be taken with irqs disabled so IMO it is out
> of the question.

One approach would be to defer the work. Is there any reason a slow sysrq
handler shouldn't be expected to behave itself and schedule work to run
later. The module unload killing the work will take care of all the other
unload stuff.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/