linux-kernel - Sparse annotation for "context imbalance" false positives?

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-next>] [day] [month] [year] [list]

Date:	Wed, 14 May 2008 20:16:39 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	linux-kernel@...r.kernel.org, linux-sparse@...r.kernel.org
Subject: Sparse annotation for "context imbalance" false positives?

Now that I've gotten the sparse noise in drivers/infiniband down to a
fairly low level, I'm starting to look at some of the more recalcitrant
false positive warnings.  One example is:

    drivers/infiniband/hw/mlx4/qp.c:605:2: warning: context imbalance in 'mlx4_ib_lock_cqs' - wrong count at exit

where the function being warned about is:

	static void mlx4_ib_lock_cqs(struct mlx4_ib_cq *send_cq, struct mlx4_ib_cq *recv_cq)
	{
		if (send_cq == recv_cq)
			spin_lock_irq(&send_cq->lock);
		else if (send_cq->mcq.cqn < recv_cq->mcq.cqn) {
			spin_lock_irq(&send_cq->lock);
			spin_lock_nested(&recv_cq->lock, SINGLE_DEPTH_NESTING);
		} else {
			spin_lock_irq(&recv_cq->lock);
			spin_lock_nested(&send_cq->lock, SINGLE_DEPTH_NESTING);
		}
	}

this function wraps up the locking rules for aquiring the completion
queue (CQ) locks associated with a queue pair (QP) -- the rule is that
if both the send and receive CQs are the same object, we (obviously)
only lock it once, otherwise we take the lock belonging to the CQ with a
numerically lower ID first (to avoid AB-BA deadlocks).

So obviously is it correct and intended that this function return
holding one or two locks, but I don't know how to tell sparse that.
I've tried messing around with __acquires() etc but it doesn't seem to
be exactly what I want.

Is there any way to tell sparse what's going on here, or do I just live
with the warnings?

Thanks,
  Roland
--
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/