linux-kernel - Re: bonding: don't increase rx_dropped after processing LACPDUs

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

Message-ID: <CAMuHMdVuDC7LiYuOdVELsxbbyf1PVZ-QvHY_7pUxigk+DWfysg@mail.gmail.com>
Date:	Sun, 13 May 2012 14:08:20 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Jiri Bohac <jbohac@...e.cz>,
	"David S. Miller" <davem@...emloft.net>
Cc:	"netdev@...r.kernel.org.Linux Kernel Mailing List" 
	<linux-kernel@...r.kernel.org>
Subject: Re: bonding: don't increase rx_dropped after processing LACPDUs

On Sat, May 12, 2012 at 10:09 PM, Linux Kernel Mailing List
<linux-kernel@...r.kernel.org> wrote:
> Author:     Jiri Bohac <jbohac@...e.cz>

>    bonding: don't increase rx_dropped after processing LACPDUs
>
>    Since commit 3aba891d, bonding processes LACP frames (802.3ad
>    mode) with bond_handle_frame(). Currently a copy of the skb is
>    made and the original is left to be processed by other
>    rx_handlers and the rest of the network stack by returning
>    RX_HANDLER_ANOTHER.  As there is no protocol handler for
>    PKT_TYPE_LACPDU, the frame is dropped and dev->rx_dropped
>    increased.
>
>    Fix this by making bond_handle_frame() return RX_HANDLER_CONSUMED
>    if bonding has processed the LACP frame.
>
>    Signed-off-by: Jiri Bohac <jbohac@...e.cz>
>    Signed-off-by: David S. Miller <davem@...emloft.net>

> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1444,8 +1444,9 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
>        struct sk_buff *skb = *pskb;
>        struct slave *slave;
>        struct bonding *bond;
> -       void (*recv_probe)(struct sk_buff *, struct bonding *,
> +       int (*recv_probe)(struct sk_buff *, struct bonding *,
>                                struct slave *);

drivers/net/bonding/bonding.h:struct bonding still has a version that
returns void:

        void     (*recv_probe)(struct sk_buff *, struct bonding *,
                               struct slave *);

drivers/net/bonding/bond_main.c: In function ‘bond_handle_frame’:
drivers/net/bonding/bond_main.c:1463: warning: assignment from
incompatible pointer type
drivers/net/bonding/bond_main.c: In function ‘bond_open’:
drivers/net/bonding/bond_main.c:3441: warning: assignment from
incompatible pointer type
drivers/net/bonding/bond_main.c:3448: warning: assignment from
incompatible pointer type

Can this cause crashes on architectures where the caller needs to
preserve space for the return value?

Don't know why I only start seeing this in -rc7, as the prototypes for the
functions related to the latter 2 warnings haven't changed recently.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/