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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 44394C49360 for ; Mon, 14 Jun 2021 05:27:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 183026102A for ; Mon, 14 Jun 2021 05:27:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232351AbhFNF3k (ORCPT ); Mon, 14 Jun 2021 01:29:40 -0400 Received: from mail-pg1-f178.google.com ([209.85.215.178]:38804 "EHLO mail-pg1-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbhFNF3j (ORCPT ); Mon, 14 Jun 2021 01:29:39 -0400 Received: by mail-pg1-f178.google.com with SMTP id t17so7721195pga.5 for ; Sun, 13 Jun 2021 22:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SKkIWihex8iN4vHyV2ULlQRHidyqRPcEAHjFrEdw0eo=; b=Ztkc32hhSlxDlYO/aubdvIkMY/qTaOmjdAcpUSwoddC36oiCXbW0t6Fgj7dqeMLjGr GKKydNoa0tuWwuRm9W2Oku1KuwQbuQOU2vGNe8iqT5qZpembeOWkm6pzrzcJ4UtTfT3O 2e868LLS7FN9kx0eyKZAZvbNfNgLUlJuXj7X9NiAHHdoSF54ImmSfOU4XZRvkkb4q+zS 4n3axSTfriXtldwQE7uH4sqiNUTf1F6IEBtIlG+THkwuA/uo2Dwz3YbQDLu64X6E4IsQ KnRwXOZqqYRo41Ey01DOqng25fgXBzlcHhBQhLIZGYVo/TgWDOPU1MK/3+ddM/Lr4vPs Pwhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SKkIWihex8iN4vHyV2ULlQRHidyqRPcEAHjFrEdw0eo=; b=GzFkfv9862bVhOpbzLzlbNl7S7xDHj7pulu9xDhaWYqkci6jNiaHTK3mrKquKklD7k ZX6qG0sDuOGHpGNRG5/uauuZNbJ5Zi+IOAr5J0uRIkz1jpb+Ui8XEd3xmtt82WlWU7M1 KBpsSEiloF8t366oqqZ1LFkHfTAOOUkzEbbQ3JAeXhEXBpVdO9V1bKkPQvs5LiC1EAZQ v38ohCwYiUrftpH+WZ9RRfFpK2ezLVS2tIJ+Sq3rRz+lfu6z07+fEZMwBYnsjCumRqpO DhFM2Chzu9B06yWcehgrzLcBH4NBvgyM3DwrnD5I/txt5k4+AtEf46UClGKthejqS3Xq GPOw== X-Gm-Message-State: AOAM5300uMMJtHQGKQRP2ezNAEM4Q7GR2g86EpA4tJcEA4fhDG/m3tGJ VZvJYU9ajZitPvI//eNAXjogXw== X-Google-Smtp-Source: ABdhPJxQbwYoqWhTfdLy3aAMNginzsjm12had6Yj2Ufq28W5WByJrv24ex9t825/WyIyYjOTicJLzg== X-Received: by 2002:a62:87c9:0:b029:2ea:572c:e4b1 with SMTP id i192-20020a6287c90000b02902ea572ce4b1mr20241936pfe.34.1623648381981; Sun, 13 Jun 2021 22:26:21 -0700 (PDT) Received: from localhost ([136.185.134.182]) by smtp.gmail.com with ESMTPSA id gf10sm10515354pjb.35.2021.06.13.22.26.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Jun 2021 22:26:20 -0700 (PDT) Date: Mon, 14 Jun 2021 10:56:17 +0530 From: Viresh Kumar To: Arnd Bergmann Cc: Jean-Philippe Brucker , Stefan Hajnoczi , "Michael S. Tsirkin" , Viresh Kumar , Linus Walleij , Linux Kernel Mailing List , virtualization@lists.linux-foundation.org, Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , Stratos Mailing List , "Enrico Weigelt, metux IT consult" , Jason Wang , "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" Subject: Re: [Stratos-dev] [PATCH V3 1/3] gpio: Add virtio-gpio driver Message-ID: <20210614052617.jfdgunichi73eup5@vireshk-i7> References: <01000179f5da7763-2ea817c6-e176-423a-952e-de02443f71e2-000000@email.amazonses.com> <01000179f9276678-ae2bb25f-4c0c-4176-b906-650c585b9753-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11-06-21, 10:34, Arnd Bergmann wrote: > Extraneous __packed annotations do cause real problems: > > - On architectures without hardware unaligned accesses, the compiler is > forced to emit byte load/store instructions, which is slower and breaks > atomic updates to shared variables > > - If a function takes a pointer of a packed struct member, and passes that > pointer to a function that expects a regular aligned pointer, you > get undefined > behavior. Newer compilers produce a warning if you do that (we currently > shut up that warning because there are many false positives in the kernel), > but you can also run into CPU exceptions or broken code even on CPUs > that do support unaligned accesses when the variable ends up being > actually unaligned (as you just told the compiler that it is allowed to do). I understand that these problems will happen if the structure isn't aligned, but in this case the structure is aligned properly, just that we are explicitly telling the compiler to not add any padding (it won't have added any in here). Is it still harmful ? -- viresh