From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751198AbdLIJFB (ORCPT ); Sat, 9 Dec 2017 04:05:01 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:39357 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbdLIJEt (ORCPT ); Sat, 9 Dec 2017 04:04:49 -0500 X-Google-Smtp-Source: AGs4zMZJeuQcq1J+w6QaX55Me+7q2j2CQyQ/zv1eOXaKEAvWhWtVAUY0Dbu2RyS0l9sUf8tNS0oMpAbvATHVW5Ggoh4= MIME-Version: 1.0 In-Reply-To: References: <1512738783-17452-1-git-send-email-geert+renesas@glider.be> From: Geert Uytterhoeven Date: Sat, 9 Dec 2017 10:04:48 +0100 X-Google-Sender-Auth: fG1bfjY7Z3RAP82k-siSexLWVRQ Message-ID: Subject: Re: [PATCH 0/2] of: overlay: Crash fix and improvement To: Frank Rowand Cc: Geert Uytterhoeven , Pantelis Antoniou , Rob Herring , "devicetree@vger.kernel.org" , Linux-Renesas , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Frank, On Sat, Dec 9, 2017 at 7:01 AM, Frank Rowand wrote: > On 12/08/17 05:13, Geert Uytterhoeven wrote: >> This patch series fixes memory corruption when applying overlays. >> I first noticed this when using OF configfs. After lots of failed >> debugging attempts, I bisected it to "of: overlay: add per overlay sysfs >> attributes", which is not upstream. But that was a red herring: that >> commit enlarged struct fragment to exactly 64-bytes, which just made it >> more likely to cause random corruption when writing beyond the end of an >> array of fragment structures. With the smaller structure size before, >> such writes usually ended up in the unused holes between allocated >> blocks, causing no harm. >> >> The first patch is the real fix, and applies to both v4.15-rc2 and Rob's >> for-next branch. >> The second patch is a small improvement, and applies to Rob's for-next >> branch only. > > Overlay FDT files should not have invalid contents. But they inevitably > will, so the code has to handle those cases. Thanks for finding this > problem and making the code better! Sure, people can throw anything at it ;-) In my case, I'm wondering if the dtbo was actually invalid? Simplification of the decompiled dtbo: /dts-v1/; / { fragment-name { target-path = [2f 00]; __overlay__ { node-name { compatible = "foo,bar"; gpios = <0xffffffff 0x0 0x0>; }; }; }; __fixups__ { bank0 = "/fragment-name/__overlay__/node-name:gpios:0"; }; }; So it has __fixup__, but no __symbols__, which looks totally valid to me. > For the full series: > > Reviewed-by: Frank Rowand Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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