[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d971a684-ccd9-3839-1e30-c166fd55cf49@inria.fr>
Date: Thu, 2 Jun 2022 07:28:29 +0900
From: Keisuke Nishimura <keisuke.nishimura@...ia.fr>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Julia Lawall <Julia.Lawall@...ia.fr>,
Arnd Bergmann <arnd@...db.de>,
Jani Nikula <jani.nikula@...el.com>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Russell King <linux@...linux.org.uk>,
Viresh Kumar <vireshk@...nel.org>,
Shiraz Hashim <shiraz.linux.kernel@...il.com>,
Ville Syrjälä <ville.syrjala@...ux.intel.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
SoC Team <soc@...nel.org>
Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID
block count and size helpers")
On 2022/06/01 1:41, Linus Torvalds wrote:
> On Tue, May 31, 2022 at 1:04 AM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> As an experiment: what kind of results would we get when looking
>> for packed structures and unions that contain any of these:
>
> I don't think we have that. Not only because it would already cause
> breakage, but simply because the kinds of structures that people pack
> aren't generally the kind that contain these kinds of things.
>
> That said, you might have a struct that is packed, but that
> intentionally aligns parts of itself, so it *could* be valid.
>
> But it would probably not be a bad idea to check that packed
> structures/unions don't have atomic types or locks in them. I _think_
> we're all good, but who knows..
I am Julia's student at INRIA and I heard from her that there is an
opportunity to use Coccinelle to find specific types in packed struct or
enum.
I found 13 definitions of packed structure that contains:
> - spinlock_t
> - atomic_t
> - dma_addr_t
> - phys_addr_t
> - size_t
> - struct mutex
> - struct device
- raw_spinlock_t
== Results ==
security/tomoyo/common.h: atomic_t in tomoyo_shared_acl_head
drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls.h: spinlock_t in
key_map
include/linux/ti-emif-sram.h: phys_addr_t in ti_emif_pm_data
drivers/scsi/wd719x.h: dma_addr_t in wd719x_scb
drivers/net/wireless/intel/ipw2x00/ipw2200.h: dma_addr_t in clx2_queue
drivers/infiniband/hw/irdma/osdep.h: dma_addr_t in irdma_dma_mem
drivers/infiniband/core/mad_priv.h: size_t in ib_mad_private
drivers/crypto/qat/qat_common/qat_asym_algs.c:
- dma_addr_t in qat_rsa_ctx
- dma_addr_t in qat_dh_ctx
drivers/atm/idt77252.h: dma_addr_t in idt77252_skb_prv
arch/s390/include/asm/kvm_host.h: atomic_t in kvm_s390_sie_block
drivers/net/wireless/ath/ath10k/core.h: dma_addr_t in ath10k_skb_cb
drivers/net/wireless/ath/ath11k/core.h: dma_addr_t in ath10k_skb_cb
drivers/crypto/ccp/ccp-dev.h: dma_addr_t in ccp_dma_info
The last 3 structures have a dma_adddr_t member defined as the first
member variable. Most of the others also seems valid.
I used this SmPL script to find them:
@e1@
type T;
identifier i;
position p;
attribute name __packed;
@@
T@p {
...
(
atomic_t i;
|
raw_spinlock_t i;
|
struct mutex i;
|
spinlock_t i;
|
dma_addr_t i;
|
phys_addr_t i;
|
size_t i;
|
struct device i;
)
...
}
__packed;
@e2@
type T;
identifier i;
position p;
@@
T@p {
...
(
atomic_t i;
|
raw_spinlock_t i;
|
struct mutex i;
|
spinlock_t i;
|
dma_addr_t i;
|
phys_addr_t i;
|
size_t i;
|
struct device i;
)
...
}
__attribute__((
(
pack
|
__pack__
)
,... ));
@script:python@
ps <<e1.p;
@@
for p in ps:
print p.file, p.line
@script:python@
ps <<e2.p;
@@
for p in ps:
print p.file, p.line
Keisuke
Powered by blists - more mailing lists