netdev - Re: [PATCH net-next] igmp: remove useless (void) cast

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

Message-Id: <20130603.003846.2026148588738043632.davem@davemloft.net>
Date:	Mon, 03 Jun 2013 00:38:46 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	xiyou.wangcong@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] igmp: remove useless (void) cast

From: Cong Wang <xiyou.wangcong@...il.com>
Date: Sat, 1 Jun 2013 02:51:05 +0000 (UTC)

> On Sat, 01 Jun 2013 at 01:44 GMT, Stephen Hemminger <stephen@...workplumber.org> wrote:
>> Back in the old Unix lint days, it was common to put (void) in front
>> of functions when return value was being ignored. Now this is considered
>> unnecessary, catch up with the fashion.
>>
> 
> None of the callers of ip_mc_leave_src() checks its return value, so I
> think we can just make it void.

So ip_mc_leave_src() calls ip_mc_del_src and all the call chains essentially
ignore the one error case that ip_mc_del_src() has, namely "!in_dev".

Most call chains validate that in_dev is not NULL before it ends up calling
ip_mc_del_src().

However, ip_mc_leave_group() is peculiar, it seems to expect that
sometimes "in_dev" can be NULL, and still signals -ENODEV when this
happens even though it still did all of the adjustments to the
socket's multicast group blobs.

Someone really needs to audit this code before we start just pretending
the error returns do not matter.

I'm not applying this patch for now, there are too many loose ends.

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