connection: only one KDBUS_ITEM_CANCEL_FD item is allowed

Make sure that only one KDBUS_ITEM_CANCEL_FD item is passed.

Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
pool: clean up error handling in kdbus_pool_copy()

Signed-off-by: Daniel Mack <daniel@zonque.org>
queue: up-chain error in kdbus_queue_entry_move()

Signed-off-by: Daniel Mack <daniel@zonque.org>
connection: catch return value of kdbus_queue_entry_move()

If kdbus_queue_entry_move(), we really shouldn't continue but
report the error up the call chain.

Signed-off-by: Daniel Mack <daniel@zonque.org>
test-sync: add no_cancel test

This test passes a CANCEL_FD but doesn't signal it. Therefore, it should
have no effect.

This catches wrong POLL masks in the kernel.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
node: make clear that ->parent is valid until destruction

So far we pretended that ->parent is no longer valid once a node was
deactivated. However, we always pinned the parent until destruction for
several reasons. Update our comments to make this clear.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
fs: bind domain-lifetime to root dentry

Make sure we activate domains *after* we allocated the root dentry, and
deactivate them *before* destroying the root dentry. This allows us to
access the root dentry as long as we hold an active reference to the
linked domain.

During mount, it doesn't matter in which order we activate the domain or
root dentry, as the underlying superblock is still locked and inaccessible
from user-space. Similarly, during sb-kill, all user-space mounts have
already been removed so the sb is inaccessible from user-space. It's
therefore safe to use any activation/deactivation order we want.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
node: add kdbus_node_is_deactivated()

This is similar to kdbus_node_is_active(), but returns 'true' if
kdbus_node_deactivate() was called on the node.

Similar to kdbus_node_is_active(), there is no guarantee that the node
stays in that state. Therefore, it's only safe to use it if you don't
care for reliability or if you have other means of synchronization against
node lifetime changes.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
fs: keep domain->dentry backlink

We don't really want backlinks into the VFS, however, we need some way to
thrash old VFS cache entries when objects get destructed. Therefore, safe
a pointer to the root dentry in every domain.

We don't pin the dentry, as this would create circular dependencies.
Instead, we bind the dentry validity to the active lifetime of the domain.
Therefore, you can only access domain->dentry as long as it is active.
Once umount() is called, we deactivate the domain and thus drop the dentry
cache.

This backlink will be needed in a follow-up that flushes caches on object
destruction.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
fs: flush VFS cache on node deactivation

Whenever a node is deactivated, we now invalidate any cached dentries.
This will make sure that we don't leave any dead entries in the VFS cache.
While this is not bad as is, it does make the cache slower. Therefore,
flush those entries as they will never be reused anyway.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>