Powered by Linux
Feature request: check for freeing an ERR_PTR — Semantic Matching Tool

Feature request: check for freeing an ERR_PTR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've noticed a number of bugs where there's an attempt to free a
pointer which turns out to be a ERR_PTR.  The basic pattern is this:

	bh = read_extent_tree_block(...);
	if (IS_ERR(bh)) {
		ret = PTR_ERR(bh);
		goto cleanup;
	}
	.
	.
	.

cleanup:
	brelse(bh);	/* or kfree for different sorts of pointers */


I suppose we could change brelse() and to do something like:

static inline void brelse(struct buffer_head *bh)
{
	if (bh && !IS_ERR(bh))
		__brelse(bh);
}

but that would tend to bloat the kernel since kfree() and brelse() get
used all over the kernel, and so usually better fix is something like
this:

	bh = read_extent_tree_block(...);
	if (unlikely(IS_ERR(bh))) {
		ret = PTR_ERR(bh);
		bh = NULL;
		goto cleanup;
	}

Hence, it would be nice if smatch could complain if functions like
kfree, brelse, etc. get called with a pointer that might be a an
ERR_PTR.

Thanks!!

						- Ted



--
To unsubscribe from this list: send the line "unsubscribe smatch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux