ida: don't use BUG_ON() for debugging
stable inclusion from stable-v5.10.130 commit e23cfb3fdcbbc5eb11eeebb97fa2607cd740bd97 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5YRJO Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e23cfb3fdcbbc5eb11eeebb97fa2607cd740bd97 -------------------------------- commit fc82bbf4 upstream. This is another old BUG_ON() that just shouldn't exist (see also commit a382f8fe: "signal handling: don't use BUG_ON() for debugging"). In fact, as Matthew Wilcox points out, this condition shouldn't really even result in a warning, since a negative id allocation result is just a normal allocation failure: "I wonder if we should even warn here -- sure, the caller is trying to free something that wasn't allocated, but we don't warn for kfree(NULL)" and goes on to point out how that current error check is only causing people to unnecessarily do their own index range checking before freeing it. This was noted by Itay Iellin, because the bluetooth HCI socket cookie code does *not* do that range checking, and ends up just freeing the error case too, triggering the BUG_ON(). The HCI code requires CAP_NET_RAW, and seems to just result in an ugly splat, but there really is no reason to BUG_ON() here, and we have generally striven for allocation models where it's always ok to just do free(alloc()); even if the allocation were to fail for some random reason (usually obviously that "random" reason being some resource limit). Fixes: 88eca020 ("ida: simplified functions for id allocation") Reported-by: NItay Iellin <ieitayie@gmail.com> Suggested-by: NMatthew Wilcox <willy@infradead.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Showing
想要评论请 注册 或 登录