From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935966AbdIYOlt convert rfc822-to-8bit (ORCPT ); Mon, 25 Sep 2017 10:41:49 -0400 Received: from smtp-out4.electric.net ([192.162.216.185]:63679 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933355AbdIYOlr (ORCPT ); Mon, 25 Sep 2017 10:41:47 -0400 From: David Laight To: "'Arnd Bergmann'" , Mauro Carvalho Chehab CC: Jiri Pirko , Arend van Spriel , Kalle Valo , "David S. Miller" , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Masahiro Yamada , Michal Marek , Andrew Morton , Kees Cook , Geert Uytterhoeven , "Greg Kroah-Hartman" , "linux-media@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-wireless@vger.kernel.org" , "brcm80211-dev-list.pdl@broadcom.com" , "brcm80211-dev-list@cypress.com" , "kasan-dev@googlegroups.com" , "linux-kbuild@vger.kernel.org" , Jakub Jelinek , =?Windows-1252?Q?Martin_Li=9Aka?= , "stable@vger.kernel.org" Subject: RE: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN Thread-Topic: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN Thread-Index: AQHTM+pQTq51yuwnA0mEOpAZrSrSVKLFsHEA Date: Mon, 25 Sep 2017 14:41:30 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD007F521@AcuExch.aculab.com> References: <20170922212930.620249-1-arnd@arndb.de> <20170922212930.620249-5-arnd@arndb.de> In-Reply-To: <20170922212930.620249-5-arnd@arndb.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann > Sent: 22 September 2017 22:29 ... > It seems that this is triggered in part by using strlcpy(), which the > compiler doesn't recognize as copying at most 'len' bytes, since strlcpy > is not part of the C standard. Neither is strncpy(). It'll almost certainly be a marker in a header file somewhere, so it should be possibly to teach it about other functions. David