From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDC57C43381 for ; Mon, 18 Feb 2019 19:09:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 895A8217D9 for ; Mon, 18 Feb 2019 19:09:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S1yFyeQ1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728406AbfBRTJW (ORCPT ); Mon, 18 Feb 2019 14:09:22 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:44151 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728391AbfBRTJV (ORCPT ); Mon, 18 Feb 2019 14:09:21 -0500 Received: by mail-pg1-f196.google.com with SMTP id y1so8900349pgk.11 for ; Mon, 18 Feb 2019 11:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:in-reply-to:references:mime-version:content-transfer-encoding :autocrypt:subject:to:cc:from:message-id; bh=hfp/wV6uLx+/+iArqxX0yeJdur8kGJJYtXIt77d6wpU=; b=S1yFyeQ1/rSXZti+3ZCM+3eTX5D9TguZm5vfG/4ILM47TpMR9Iwi7Pem1Ba/maXhZ8 1wLnz8qqol6whmcVuQ04o10nzwygG6Wgm4BGYxGzH+le+fZ7sizL3EhFPwtH2UopJ74g Sfj39L2UuU4VwV2uCy4NFzBqD7rkDRxLKiuMYhDUGOZtBWx2Q2b879dlllANgIK2En0/ oPS6OK1yiFpOQDx5zDuEfFGZDZ8y1AZV+VV9bEyAyOHWBTTeoEMHB3w4l2lwKhD8p7FN j7BQdtDyd0/mh03V3KzavomZ3+YpvwyaDWpnSmOZNc5gfIqRNXfyuHII1UrzxZWc45b/ 2U+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:references:mime-version :content-transfer-encoding:autocrypt:subject:to:cc:from:message-id; bh=hfp/wV6uLx+/+iArqxX0yeJdur8kGJJYtXIt77d6wpU=; b=Nka9r2sDs3YIjYyQv8H9lHdoeJuAju2XH+bbnNh/hnQZa4UwMoRLIJjlGhH31vai9x 1I3g5dS0Ggh8Kwriz6og47iKVOhaQiVsjagEVygDuMaJVIiaTjbr1HH8A4tkIOTRRryj WBQltFjSieSpSTrceKwJN20YETsmJqbAOgQtnEWOC+ol38ym39bFpsWIYBSA7s45SzeV d60r9kniiVjbQf8pO6/mbrn7XrIO2Ku0aKusV5sib5f83hXpG92fpa9ue/+M9ZdKcC7D WHpKAAog7L2XkV0Iyq6YzaJZZDj7IzwLwNq/IwEGZ4+ztkhVocgsoEpjjJNLmJq7yQb5 wMiA== X-Gm-Message-State: AHQUAua8yxme8CPjk4Xo8x4QM8klMZLCXK119UKzG5zqDn4+pfVMbEKp QoAfn6j1lzk2pQgiDo+wRog= X-Google-Smtp-Source: AHgI3IZosuGXCl3Iybq11PWSldw0t6lt+g1XivsC21WmE3mxK8ER6ltxCybq7blyXOuwIvHNjBkt9Q== X-Received: by 2002:a63:fa06:: with SMTP id y6mr20378815pgh.177.1550516960500; Mon, 18 Feb 2019 11:09:20 -0800 (PST) Received: from localhost ([2607:fb90:22d0:5857:1e8f:4152:bf79:f64b]) by smtp.gmail.com with ESMTPSA id 22sm28736974pfk.53.2019.02.18.11.09.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 11:09:19 -0800 (PST) Date: Mon, 18 Feb 2019 11:09:14 -0800 In-Reply-To: References: <62c1c008-8484-3e6c-239a-906efb55a6d0@gmail.com> <2b9ecca4-4a92-44e0-f85e-2877dd08013a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Autocrypt: addr=f.fainelli@gmail.com; keydata= mQGiBEjPuBIRBACW9MxSJU9fvEOCTnRNqG/13rAGsj+vJqontvoDSNxRgmafP8d3nesnqPyRxGlk aOSDuu09rxuW+69Y2f1TzjFuGpBk4ysWOR85O2Nx8AJ6fYGCoeTbovrNlGT1M9obSFGQX3IzRnWo qlfudjTO5TKoqkbOgpYqIo5n1QbEjCCwCwCg3DOH/4ug2AUUlcIT9/l3pGvoRJ0EAICDzi3l7pmC 5IWn2n1mvP5247urtHFs/uusE827DDj3K8Upn2vYiOFMBhGsxAk6YKV6IP0dZdWX6fqkJJlu9cSD vWtO1hXeHIfQIE/xcqvlRH783KrihLcsmnBqOiS6rJDO2x1eAgC8meAXSAgsrBhcgGl2Rl5gh/jk eA5ykwbxA/9u1eEuL70Qzt5APJmqVXR+kWvrqdBVPoUNy/tQ8mYcnzJJ63ng3tHhnwHXZOu8hL4n qwlYHRa9eeglXYhBqja4ZvIvCEqSmEukfivk+DlIgVoOAJbhqIWgvr3SIEuR6ayY3f5j0f2ejUMY lYYnKdiHXFlF9uXm1ELrb0YX4GMHz7QnRmxvcmlhbiBGYWluZWxsaSA8Zi5mYWluZWxsaUBnbWFp bC5jb20+iGYEExECACYCGyMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCVF/S8QUJHlwd3wAKCRBh V5kVtWN2DvCVAJ4u4/bPF4P3jxb4qEY8I2gS6hG0gACffNWlqJ2T4wSSn+3o7CCZNd7SLSC5BA0E SM+4EhAQAL/o09boR9D3Vk1Tt7+gpYr3WQ6hgYVON905q2ndEoA2J0dQxJNRw3snabHDDzQBAcqO vdi7YidfBVdKi0wxHhSuRBfuOppupdXkb7zxuPQuSveCLqqZWRQ+Cc2QgF7SBqgznbe6Ngout5qX Y5Dcagk9LqFNGhJQzUGHAsIshap1f0B1PoUyUNeEInV98D8Xd/edM3mhO9nRpUXRK9Bvt4iEZUXG uVtZLT52nK6Wv2EZ1TiTOiqZlf1P+vxYLBx9eKmabPdm3yjalhY8yr1S1vL0gSA/C6W1o/Towdie F1rWN/MYHlkpyj9cRpc281gAO0AP3V1G00YzBEdYyi0gaJbCEQnq8Vz1vDXFxHzyhgGz7umBsVKm YwZgA8DrrB0MoaP35wuGR3RJcaG30AnJpEDkBYHznI2apxdcuTPOHZyEilIRrBGzDwGtAhldzlBo BwE3Z3MY31TOpACu1ZpNOMysZ6xiE35pWkwc0KYm4hJA5GFfmWSN6DniimW3pmdDIiw4Ifcx8b3m FrROBbDIW13E51j9RjbO/nAaK9ndZ5LRO1B/8Fwat7bLzmsCiEXOJY7NNpIEpkoNoEUfCcZwmLrU +eOTPzaF6drw6ayewEi5yzPg3TAT6FV3oBsNg3xlwU0gPK3v6gYPX5w9+ovPZ1/qqNfOrbsEFRui SVsZQ5s3AAMFD/9XjlnnVDh9GX/r/6hjmr4U9tEsM+VQXaVXqZuHKaSmojOLUCP/YVQo7IiYaNss CS4FCPe4yrL4FJJfJAsbeyDykMN7wAnBcOkbZ9BPJPNCbqU6dowLOiy8AuTYQ48mvIyQ4Ijnb6GT rtxIUDQeOBNuQC/gyyx3nbL/lVlHbxr4tb6YkhkO6shjXhQh7nQb33FjGO4PWU11Nr9i/qoV8QCo 12MQEo244RRA6VMud06y/E449rWZFSTwGqb0FS0seTcYNvxt8PB2izX+HZA8SL54j479ubxhfuoT u5nXdtFYFj5Lj5x34LKPx7MpgAmj0H7SDhpFWF2FzcC1bjiW9mjWHaKaX23Awt97AqQZXegbfkJw X2Y53ufq8Np3e1542lh3/mpiGSilCsaTahEGrHK+lIusl6mzJoil+u3k01ofvJMK0ZdzGUZ/aPMZ 16LofjFA+MNxWrZFrkYmiGdv+LG45zSlZyIvzSiG2lKykuVag+IijCIom78P9jRtB1q1Q5lwZp2T LAJlz92DmFwBg1hyFzwDADjZ2nrDxKUiybXIgZp9aU2d++ptEGCVJOfEW4qpWCCLPbOT7XBr+g/4 H3qWbs3j/cDDq7LuVYIe+wchy/iXEJaQVeTCy5arMQorqTFWlEOgRA8OP47L9knl9i4xuR0euV6D ChDrguup2aJVU4hPBBgRAgAPAhsMBQJUX9LxBQkeXB3fAAoJEGFXmRW1Y3YOj4UAn3nrFLPZekMe qX5aD/aq/dsbXSfyAKC45Go0YyxVHGuUuzv+GKZ6nsysJw== Subject: Re: [BUG] [FIX] net: dsa: oops in br_vlan_enabled To: Frank Wunderlich CC: netdev@vger.kernel.org, Andrew Lunn , Vivien Didelot From: Florian Fainelli Message-ID: <90613F26-F51D-419C-8D72-FC54BAFB6492@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On February 18, 2019 9:11:27 AM PST, Frank Wunderlich wrote: >Hi, > >tried your Patch but crashes the same way: Yes the lower_dev targeted by switched does point to the DSA slave network= device, but we really don't have dp->bridge_dev assigned since the physica= l DSA port was not enslaved in the bridge=2E Will follow up with a correct = version late today=2E > >[ 107=2E416972] [] (br_vlan_enabled [bridge]) from >[] (dsa_po >rt_vlan_add+0x60/0xbc [dsa_core]) =20 > =20 >[ 107=2E426939] [] (dsa_port_vlan_add [dsa_core]) from >[] (ds >a_slave_port_obj_add+0x64/0x68 [dsa_core]) =20 > =20 >[ 107=2E437666] [] (dsa_slave_port_obj_add [dsa_core]) from >[ >] (__switchdev_port_obj_add+0x50/0xc4) =20 > =20 >[ 107=2E448029] [] (__switchdev_port_obj_add) from >[] (__swit >chdev_port_obj_add+0xa0/0xc4) =20 > =20 >[ 107=2E457612] [] (__switchdev_port_obj_add) from >[] (switch >dev_port_obj_add_now+0x60/0x130) =20 > =20 >[ 107=2E467453] [] (switchdev_port_obj_add_now) from >[] (swit >chdev_port_obj_add+0x44/0x190) =20 > =20 >[ 107=2E477181] [] (switchdev_port_obj_add) from [] >(br_switc >hdev_port_vlan_add+0x60/0x7c [bridge]) =20 > =20 >[ 107=2E487644] [] (br_switchdev_port_vlan_add [bridge]) from >[0>] (__vlan_add+0xb0/0x620 [bridge]) > >regards Frank > > >> Gesendet: Montag, 18=2E Februar 2019 um 00:20 Uhr >> Von: "Florian Fainelli" >> An: "Frank Wunderlich" , >netdev@vger=2Ekernel=2Eorg, "Andrew Lunn" , "Vivien >Didelot" >> Betreff: Re: [BUG] [FIX] net: dsa: oops in br_vlan_enabled >> >>=20 >>=20 >> On 2/17/2019 9:13 AM, Florian Fainelli wrote: >> > Hi Frank, >> >=20 >> > On 2/16/2019 8:22 AM, Frank Wunderlich wrote: >> >> Hi, >> >> >> >> i've found an oops in 4=2E19=2E23/10, seems to be fixed anyhow in 5= =2E0 >(also works in 4=2E14=2E101) >> >> >> >> root@bpi-r2:~# ip link add link lan0 name lan0=2E5 type vlan id 5 >> >> root@bpi-r2:~# ip addr add 192=2E168=2E5=2E200/24 brd 192=2E168=2E5= =2E255 dev >lan0=2E5 >> >> root@bpi-r2:~# ip link set dev lan0 up >> >> root@bpi-r2:~# ip link set dev lan0=2E5 up >> >=20 >> > So that these steps don't involve a bridge, and because we don't >(yet) >> > implment ndo_vlan_rx_{add,kill}_vid() netdevice_ops, there is no >VLAN >> > programming, it's all software >> >=20 >> >> >> >> 12: lan0=2E5@lan0: mtu 1500 >qdisc noqueue state LOWERLAYERDOWN group default qlen 1000 >> >> link/ether 02:02:02:02:02:02 brd ff:ff:ff:ff:ff:ff >> >> inet 192=2E168=2E5=2E200/24 brd 192=2E168=2E5=2E255 scope global= lan0=2E5 >> >> valid_lft forever preferred_lft forever >> >> >> >> root@bpi-r2:~# brctl addbr bridge_name >> >> root@bpi-r2:~# brctl addif bridge_name lan0=2E5 >> >=20 >> > Unless you changed the bridge to have VLAN filtering/awareness >with: >> >=20 >> > echo 1 > /sys/class/net/bridge_name/bridge/vlan_filtering >> >=20 >> > There will be no VLAN configuration/objects pushed to DSA since >commit >> > 2ea7a679ca2abd251c1ec03f20508619707e1749 ("net: dsa: Don't add >vlans >> > when vlan filtering is disabled") so I am not sure how you got into >that >> > situation because prior to pushing a VLAN object, the port must be >part >> > of a bridge, so the steps typically look like: >> >=20 >> > - port_bridge_join which assigns dp->bridge_dev >> > - port_vlan_add >> >=20 >> > Does your 4=2E19=2E23 kernel somehow change how VLAN objects are push= ed >down >> > the switch driver? >> >=20 >> >> [ 352=2E057128] bridge_name: port 1(lan0=2E5) entered blocking stat= e >> >> [ 352=2E063065] bridge_name: port 1(lan0=2E5) entered disabled stat= e >> >> [ 352=2E069181] device lan0=2E5 entered promiscuous mode >> >> [ 352=2E074018] device lan0 entered promiscuous mode >> >> [ 352=2E078906] Unable to handle kernel NULL pointer dereference at >virtual address 00000558 >> >> =2E=2E=2E >> >> [ 352=2E493085] [] (br_vlan_enabled [bridge]) from >[] (dsa_port_vlan_add+0x60/0xbc [dsa_core]) >> >> [ 352=2E503050] [] (dsa_port_vlan_add [dsa_core]) from >[] (dsa_slave_port_obj_add+0x4c/0x50 [dsa_core]) >> >> [ 352=2E513776] [] (dsa_slave_port_obj_add [dsa_core]) >from [] (__switchdev_port_obj_add+0x50/0xc4) >> >> [ 352=2E524138] [] (__switchdev_port_obj_add) from >[] (__switchdev_port_obj_add+0xa0/0xc4) >> >> [ 352=2E533721] [] (__switchdev_port_obj_add) from >[] (switchdev_port_obj_add_now+0x60/0x130) >> >> [ 352=2E543562] [] (switchdev_port_obj_add_now) from >[] (switchdev_port_obj_add+0x44/0x190) >> >> [ 352=2E553284] [] (switchdev_port_obj_add) from >[] (br_switchdev_port_vlan_add+0x60/0x7c [bridge]) >> >> [ 352=2E563733] [] (br_switchdev_port_vlan_add [bridge]) >from [] (__vlan_add+0xb0/0x620 [bridge]) >> >> [ 352=2E574007] [] (__vlan_add [bridge]) from >[] (nbp_vlan_add+0xc4/0x150 [bridge]) >> >> [ 352=2E583073] [] (nbp_vlan_add [bridge]) from >[] (nbp_vlan_init+0x134/0x164 [bridge]) >> >> [ 352=2E592482] [] (nbp_vlan_init [bridge]) from >[] (br_add_if+0x40c/0x5fc [bridge]) >> >> [ 352=2E601632] [] (br_add_if [bridge]) from [] >(add_del_if+0x6c/0x80 [bridge]) >> >> [ 352=2E610351] [] (add_del_if [bridge]) from >[] (br_dev_ioctl+0x7c/0x9c [bridge]) >> >> [ 352=2E619290] [] (br_dev_ioctl [bridge]) from >[] (dev_ifsioc+0x184/0x324) >> >> [ 352=2E627582] [] (dev_ifsioc) from [] >(dev_ioctl+0x32c/0x5cc) >> >> [ 352=2E634837] [] (dev_ioctl) from [] >(sock_ioctl+0x3bc/0x580) >> >> >> >> >> >> since my 4=2E19=2E23 kernel is modified a bit i tried with 4=2E19=2E= 10 >without my net modifications and it is still reproducable with steps >above (create a vlan on dsa-user-port and then use it in a bridge) >> >> >> >> i fixed it with these changes: >>=20 >> Your fix is undoing the commit from Andrew I just referenced, so it >is >> definitively not the right fix because it will push VLAN objects down >to >> a non-VLAN aware bridge, not that this is really a problem, but it >> should not be happening anyway=2E >>=20 >> The problem appears to be the following though: you are enslaving a >VLAN >> device, which does not have switchdev_ops, so we recurse into the >lower >> device, which is the DSA network device, which does have >switchdev_ops >> defined=2E Once we are there we check the orig_dev against being a >bridge >> master network device, but we are not checking that it's a VLAN >device >> so we end-up assuming it is a DSA network device, we de-reference >> garbage by checking br_vlan_enabled(dp->bridge_dev) because there is >> simply no such data structure associated with the VLAN device=2E >>=20 >> The attached patch should help=2E >>=20 >> This is no longer a problem in newer kernels because the switchdev >> operations use a notifier which checks the target network device to >be DSA=2E >> --=20 >> Florian >>=20 --=20 Florian