linux-kernel - Re: [RFC] ->get_link(), ->put

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:	Sun, 3 Jan 2016 21:40:23 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC] ->get_link(), ->put_link() and cookies

On Sun, Jan 03, 2016 at 12:41:47PM -0800, Linus Torvalds wrote:

> I like how it removes "put_link()" as a callback, but at the same time
> I think it's even more abstract than the cookie was.
> 
> The main worry I have is that the naming is generic, but there's only
> a single very specialized use for it. Do we expect other uses?

Quite possibly - I don't have anything specific planned right now, but
I would be surprised if there hadn't been open-coded equivalents
of that thing in many places, and not only "too many instances to touch"
kind of holy cows, at that (timers are obviously very similar, but these
_do_ have way too many instances to even think of converting them).

> Because if not, I think it would be clearer if it was named to be more
> concretely about putlink, and avoid the fact that it feels very
> abstract.
> 
> Don't get me wrong - abstract generalized helper functions are cool.
> But people aren't very abstract, and it tends to make for confusing
> code when you aren't intimately familiar with the rules.

The rules are pretty simple - there are 4 primitives total.
1) DEFINE_DELAYED_CALL(name) - usual DEFINE_MUTEX, etc. style initialized
declaration.
2) set_delayed_call(delayed_call, function, argument) - function is
void(void *), argument is void *.  A-la setup_timer().
3) clear_delayed_call(delayed_call) - resets.
4) do_delayed_call(delayed_call) - evaluates.

That's it.  If you have better suggestions re names, I'd be glad to take
them, but the set of primitives and the rules to go with those are as
simple as it gets.

Sure, we can give it a less generic name for now and just do what we'd done
for another generic thing (rcu_head, aka callback_head) when unrelated
uses show up, but I don't see much point going that way, TBH...
--
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/