linux-kernel - [PATCH 0/9] Convert all to the caller hold lock version

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130508181304.GA12344@udknight>
Date:	Thu, 9 May 2013 02:13:04 +0800
From:	Wang YanQing <udknight@...il.com>
To:	gregkh@...uxfoundation.org
Cc:	jslaby@...e.cz, alan@...ux.intel.com, airlied@...hat.com,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/9] Convert all to the caller hold lock version

After commit 50e244cc793d511b86adea24972f3a7264cae114 
     (fb: rework locking to fix lock ordering on takeover)
and 
     commit e93a9a868792ad71cdd09d75e5a02d8067473c4e
     (fb: Yet another band-aid for fixing lockdep mess)

We have two version functions implement almost the same function,
except the caller/callee hold lock.

fbcon_takeover vs do_fbcon_takeover
register_con_driver vs do_register_con_driver
take_over_console vs do_take_over_console
unbind_con_driver vs do_unbind_con_driver
bind_con_driver vs do_bind_con_driver
unregister_con_driver vs do_unregister_con_driver

This issue bring us much code duplication,
like do_fbcon_takeover and fbcon_takeover,
they have almost the same.

Although some of them had been re-written 
as a wrapper for another, but the wrapper
is so trivial, we can just throw them away.

Also those two versions of almost the same
functions will confuse API's user.

After all, I think this issue is not good
for long time maintain.

This series patch convert all to the
new version which caller hold the lock,
and then delete the old version away.

Thanks

--
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/