[00/18] treewide: fix object files shared between several modules

Message ID 20221119225650.1044591-1-alobakin@pm.me
Headers
Series treewide: fix object files shared between several modules |

Message

Alexander Lobakin Nov. 19, 2022, 11:03 p.m. UTC
  This is a follow-up to the series[0] that adds Kbuild warning if an
object is linked into several modules (including vmlinux) in order
to prevent hidden side effects from appearing.
The original series, as well as this one, was inspired by the recent
issue[1] with the ZSTD modules on a platform which has such sets of
vmlinux cflags and module cflags so that objects built with those
two even refuse to link with each other.
The final goal is to forbid linking one object several times
entirely.

Patches 1-7 and 10-11 was runtime-tested by me. Pathes 8-9 and 12-18
are compile-time tested only (compile, link, modpost), so I
encourage the maintainers to review them carefully. At least the
last one, for cpsw, most likely has issues :D
Masahiro's patches are taken from his WIP tree[2], with the two last
finished by me.

This mostly is a monotonic work, all scores go to Masahiro and
Alexey :P

[0] https://lore.kernel.org/linux-kbuild/20221118191551.66448-1-masahiroy@kernel.org
[1] https://github.com/torvalds/linux/commit/637a642f5ca5e850186bb64ac75ebb0f124b458d
[2] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=tmp4

Alexander Lobakin (9):
  EDAC: i10nm, skx: fix mixed module-builtin object
  platform/x86: int3472: fix object shared between several modules
  mtd: tests: fix object shared between several modules
  crypto: octeontx2: fix objects shared between several modules
  dsa: ocelot: fix mixed module-builtin object
  net: dpaa2: fix mixed module-builtin object
  net: hns3: fix mixed module-builtin object
  net: octeontx2: fix mixed module-builtin object
  net: cpsw: fix mixed module-builtin object

Masahiro Yamada (9):
  block/rnbd: fix mixed module-builtin object
  drm/bridge: imx: fix mixed module-builtin object
  drm/bridge: imx: turn imx8{qm,qxp}-ldb into single-object modules
  sound: fix mixed module-builtin object
  mfd: rsmu: fix mixed module-builtin object
  mfd: rsmu: turn rsmu-{core,i2c,spi} into single-object modules
  net: liquidio: fix mixed module-builtin object
  net: enetc: fix mixed module-builtin object
  net: emac, cpsw: fix mixed module-builtin object (davinci_cpdma)

 drivers/block/rnbd/Makefile                   |   6 +-
 drivers/block/rnbd/rnbd-common.c              |  23 -
 drivers/block/rnbd/rnbd-proto.h               |  14 +-
 drivers/crypto/marvell/octeontx2/Makefile     |  11 +-
 drivers/crypto/marvell/octeontx2/cn10k_cpt.c  |   9 +-
 drivers/crypto/marvell/octeontx2/cn10k_cpt.h  |   2 -
 .../marvell/octeontx2/otx2_cpt_common.h       |   2 -
 .../marvell/octeontx2/otx2_cpt_mbox_common.c  |  14 +-
 drivers/crypto/marvell/octeontx2/otx2_cptlf.c |  11 +
 .../marvell/octeontx2/otx2_cptpf_main.c       |   2 +
 .../marvell/octeontx2/otx2_cptvf_main.c       |   2 +
 drivers/edac/Kconfig                          |  11 +-
 drivers/edac/Makefile                         |   7 +-
 drivers/edac/i10nm_base.c                     |   2 +
 drivers/edac/skx_base.c                       |   2 +
 drivers/edac/skx_common.c                     |  21 +-
 drivers/edac/skx_common.h                     |   4 +-
 drivers/gpu/drm/bridge/imx/Makefile           |   4 -
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c   | 221 -----
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h   | 213 +++-
 .../imx/{imx8qm-ldb-drv.c => imx8qm-ldb.c}    |   0
 .../imx/{imx8qxp-ldb-drv.c => imx8qxp-ldb.c}  |   0
 drivers/mfd/Kconfig                           |   8 +-
 drivers/mfd/Makefile                          |   3 +-
 drivers/mfd/{rsmu_core.c => rsmu-core.c}      |   3 +
 drivers/mfd/{rsmu_i2c.c => rsmu-i2c.c}        |   0
 drivers/mfd/{rsmu_spi.c => rsmu-spi.c}        |   0
 drivers/mtd/tests/Makefile                    |  17 +-
 drivers/mtd/tests/mtd_test.c                  |   9 +
 drivers/mtd/tests/nandbiterrs.c               |   2 +
 drivers/mtd/tests/oobtest.c                   |   2 +
 drivers/mtd/tests/pagetest.c                  |   2 +
 drivers/mtd/tests/readtest.c                  |   2 +
 drivers/mtd/tests/speedtest.c                 |   2 +
 drivers/mtd/tests/stresstest.c                |   2 +
 drivers/mtd/tests/subpagetest.c               |   2 +
 drivers/mtd/tests/torturetest.c               |   2 +
 drivers/net/dsa/ocelot/Kconfig                |  18 +-
 drivers/net/dsa/ocelot/Makefile               |  12 +-
 drivers/net/dsa/ocelot/felix.c                |   6 +
 drivers/net/dsa/ocelot/felix_vsc9959.c        |   2 +
 drivers/net/dsa/ocelot/seville_vsc9953.c      |   2 +
 drivers/net/ethernet/cavium/Kconfig           |   5 +
 drivers/net/ethernet/cavium/liquidio/Makefile |   4 +-
 .../cavium/liquidio/cn23xx_pf_device.c        |   4 +
 .../cavium/liquidio/cn23xx_vf_device.c        |   3 +
 .../ethernet/cavium/liquidio/cn66xx_device.c  |   1 +
 .../ethernet/cavium/liquidio/cn68xx_device.c  |   1 +
 .../net/ethernet/cavium/liquidio/lio_core.c   |  16 +
 .../ethernet/cavium/liquidio/lio_ethtool.c    |   1 +
 .../ethernet/cavium/liquidio/octeon_device.c  |  24 +
 .../ethernet/cavium/liquidio/octeon_droq.c    |   4 +
 .../ethernet/cavium/liquidio/octeon_mem_ops.c |   5 +
 .../net/ethernet/cavium/liquidio/octeon_nic.c |   3 +
 .../cavium/liquidio/request_manager.c         |  14 +
 .../cavium/liquidio/response_manager.c        |   3 +
 drivers/net/ethernet/freescale/dpaa2/Kconfig  |   6 +
 drivers/net/ethernet/freescale/dpaa2/Makefile |   6 +-
 .../net/ethernet/freescale/dpaa2/dpaa2-eth.c  |   2 +
 .../net/ethernet/freescale/dpaa2/dpaa2-mac.c  |  15 +-
 .../ethernet/freescale/dpaa2/dpaa2-switch.c   |   2 +
 drivers/net/ethernet/freescale/enetc/Kconfig  |   5 +
 drivers/net/ethernet/freescale/enetc/Makefile |   7 +-
 drivers/net/ethernet/freescale/enetc/enetc.c  |  21 +
 .../net/ethernet/freescale/enetc/enetc_cbdr.c |   7 +
 .../ethernet/freescale/enetc/enetc_ethtool.c  |   2 +
 .../net/ethernet/freescale/enetc/enetc_pf.c   |   2 +
 .../net/ethernet/freescale/enetc/enetc_vf.c   |   2 +
 drivers/net/ethernet/hisilicon/Kconfig        |   5 +
 drivers/net/ethernet/hisilicon/hns3/Makefile  |  13 +-
 .../hns3/hns3_common/hclge_comm_cmd.c         |  27 +-
 .../hns3/hns3_common/hclge_comm_cmd.h         |   8 -
 .../hns3/hns3_common/hclge_comm_rss.c         |  17 +
 .../hns3/hns3_common/hclge_comm_tqp_stats.c   |   5 +
 .../hisilicon/hns3/hns3pf/hclge_main.c        |   2 +
 .../hisilicon/hns3/hns3vf/hclgevf_main.c      |   2 +
 .../net/ethernet/marvell/octeontx2/Kconfig    |   5 +
 .../ethernet/marvell/octeontx2/nic/Makefile   |  14 +-
 .../marvell/octeontx2/nic/otx2_common.h       |   1 -
 .../marvell/octeontx2/nic/otx2_dcbnl.c        |   8 +-
 .../marvell/octeontx2/nic/otx2_devlink.c      |   2 +
 .../ethernet/marvell/octeontx2/nic/otx2_pf.c  |   2 +
 .../ethernet/marvell/octeontx2/nic/otx2_ptp.c |   2 +-
 .../ethernet/marvell/octeontx2/nic/otx2_vf.c  |   2 +
 drivers/net/ethernet/ti/Kconfig               |  13 +
 drivers/net/ethernet/ti/Makefile              |  16 +-
 drivers/net/ethernet/ti/am65-cpsw-nuss.c      |   2 +
 drivers/net/ethernet/ti/cpsw.c                |   3 +
 drivers/net/ethernet/ti/cpsw_ale.c            |  20 +
 drivers/net/ethernet/ti/cpsw_ethtool.c        |  24 +
 drivers/net/ethernet/ti/cpsw_new.c            |   3 +
 drivers/net/ethernet/ti/cpsw_priv.c           |  36 +
 drivers/net/ethernet/ti/cpsw_sl.c             |   8 +
 drivers/net/ethernet/ti/davinci_cpdma.c       |  33 +
 drivers/net/ethernet/ti/davinci_emac.c        |   2 +
 drivers/net/ethernet/ti/netcp_core.c          |   2 +
 drivers/net/ethernet/ti/netcp_ethss.c         |   2 +
 drivers/platform/x86/intel/int3472/Makefile   |   8 +-
 drivers/platform/x86/intel/int3472/common.c   |   8 +
 drivers/platform/x86/intel/int3472/discrete.c |   2 +
 drivers/platform/x86/intel/int3472/tps68470.c |   2 +
 sound/soc/codecs/Makefile                     |   6 +-
 sound/soc/codecs/wcd-clsh-v2.c                | 903 -----------------
 sound/soc/codecs/wcd-clsh-v2.h                | 917 +++++++++++++++++-
 104 files changed, 1679 insertions(+), 1288 deletions(-)
 delete mode 100644 drivers/block/rnbd/rnbd-common.c
 delete mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
 rename drivers/gpu/drm/bridge/imx/{imx8qm-ldb-drv.c => imx8qm-ldb.c} (100%)
 rename drivers/gpu/drm/bridge/imx/{imx8qxp-ldb-drv.c => imx8qxp-ldb.c} (100%)
 rename drivers/mfd/{rsmu_core.c => rsmu-core.c} (94%)
 rename drivers/mfd/{rsmu_i2c.c => rsmu-i2c.c} (100%)
 rename drivers/mfd/{rsmu_spi.c => rsmu-spi.c} (100%)
 delete mode 100644 sound/soc/codecs/wcd-clsh-v2.c

--
2.38.1
  

Comments

Mark Brown Nov. 20, 2022, 11:58 a.m. UTC | #1
On Sat, Nov 19, 2022 at 11:03:57PM +0000, Alexander Lobakin wrote:

Your mails appear to be encrypted which isn't helping with
review...
  
Conor Dooley Nov. 20, 2022, 12:26 p.m. UTC | #2
On Sun, Nov 20, 2022 at 11:58:26AM +0000, Mark Brown wrote:
> On Sat, Nov 19, 2022 at 11:03:57PM +0000, Alexander Lobakin wrote:
> 
> Your mails appear to be encrypted which isn't helping with
> review...

https://lore.kernel.org/all/20221119225650.1044591-1-alobakin@pm.me/

Looks un-encrypted on lore. pm.me looks to be a protonmail domain - I
had issues with protonmail where it picked up Maz's key via Web Key
Directory. "Kernel.org publishes the WKD for all developers who have
kernel.org accounts" & unfortunately proton doesn't (or didn't) offer a
way to disable this. If someone's key is available it gets used & proton
told me, IIRC, that not having a way to disable this is a privacy
feature.

Unfortunately, my workaround was leaving protonmail.
  
Jakub Kicinski Nov. 21, 2022, 7:50 p.m. UTC | #3
On Sat, 19 Nov 2022 23:03:57 +0000 Alexander Lobakin wrote:
> Subject: [PATCH 00/18] treewide: fix object files shared between several modules

Could you repost the networking changes separately in v2?
I'm not seeing any reason why this would have to be a treewide
series when merging.

> monotonic

monotonous, unless you mean steady progress ;)
  
Mark Brown Nov. 22, 2022, 11:28 a.m. UTC | #4
On Sun, Nov 20, 2022 at 12:26:00PM +0000, Conor Dooley wrote:
> On Sun, Nov 20, 2022 at 11:58:26AM +0000, Mark Brown wrote:
> > On Sat, Nov 19, 2022 at 11:03:57PM +0000, Alexander Lobakin wrote:

> > Your mails appear to be encrypted which isn't helping with
> > review...

> https://lore.kernel.org/all/20221119225650.1044591-1-alobakin@pm.me/

> Looks un-encrypted on lore. pm.me looks to be a protonmail domain - I
> had issues with protonmail where it picked up Maz's key via Web Key
> Directory. "Kernel.org publishes the WKD for all developers who have
> kernel.org accounts" & unfortunately proton doesn't (or didn't) offer a
> way to disable this. If someone's key is available it gets used & proton
> told me, IIRC, that not having a way to disable this is a privacy
> feature.

It wasn't obviously encrypted to my key either...
  
Alexander Lobakin Nov. 22, 2022, 9:37 p.m. UTC | #5
From: Mark Brown <broonie@kernel.org>
Date: Sun, 20 Nov 2022 11:58:26 +0000

> On Sat, Nov 19, 2022 at 11:03:57PM +0000, Alexander Lobakin wrote:
> 
> Your mails appear to be encrypted which isn't helping with
> review...

Oh I'm sorry. I gave ProtonMail one more chance. I had the same
issue with them at spring, they told me then that it's a super-pro
builtin feature that I can't disable :clownface: They promised to
"think on it" tho, so I thought maybe after half a year...
Nope. Ok, whatever. My workaround will be the same as Conor's, just
to change the provider lol.
Should be better now?

Thanks,
Olek
  
Mark Brown Nov. 23, 2022, 11:51 a.m. UTC | #6
On Tue, Nov 22, 2022 at 10:37:54PM +0100, Alexander Lobakin wrote:
> From: Mark Brown <broonie@kernel.org>
> > On Sat, Nov 19, 2022 at 11:03:57PM +0000, Alexander Lobakin wrote:

> > Your mails appear to be encrypted which isn't helping with
> > review...

> Oh I'm sorry. I gave ProtonMail one more chance. I had the same
> issue with them at spring, they told me then that it's a super-pro
> builtin feature that I can't disable :clownface: They promised to
> "think on it" tho, so I thought maybe after half a year...
> Nope. Ok, whatever. My workaround will be the same as Conor's, just
> to change the provider lol.
> Should be better now?

Yes, everything's fine now - thanks for looking into it.
  
Masahiro Yamada Nov. 23, 2022, 9:39 p.m. UTC | #7
On Sun, Nov 20, 2022 at 8:04 AM Alexander Lobakin <alobakin@pm.me> wrote:
>
> This is a follow-up to the series[0] that adds Kbuild warning if an
> object is linked into several modules (including vmlinux) in order
> to prevent hidden side effects from appearing.
> The original series, as well as this one, was inspired by the recent
> issue[1] with the ZSTD modules on a platform which has such sets of
> vmlinux cflags and module cflags so that objects built with those
> two even refuse to link with each other.
> The final goal is to forbid linking one object several times
> entirely.
>
> Patches 1-7 and 10-11 was runtime-tested by me. Pathes 8-9 and 12-18
> are compile-time tested only (compile, link, modpost), so I
> encourage the maintainers to review them carefully. At least the
> last one, for cpsw, most likely has issues :D
> Masahiro's patches are taken from his WIP tree[2], with the two last
> finished by me.
>
> This mostly is a monotonic work, all scores go to Masahiro and
> Alexey :P
>
> [0] https://lore.kernel.org/linux-kbuild/20221118191551.66448-1-masahiroy@kernel.org
> [1] https://github.com/torvalds/linux/commit/637a642f5ca5e850186bb64ac75ebb0f124b458d
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=tmp4
>
> Alexander Lobakin (9):
>   EDAC: i10nm, skx: fix mixed module-builtin object
>   platform/x86: int3472: fix object shared between several modules
>   mtd: tests: fix object shared between several modules
>   crypto: octeontx2: fix objects shared between several modules
>   dsa: ocelot: fix mixed module-builtin object
>   net: dpaa2: fix mixed module-builtin object
>   net: hns3: fix mixed module-builtin object
>   net: octeontx2: fix mixed module-builtin object
>   net: cpsw: fix mixed module-builtin object
>
> Masahiro Yamada (9):
>   block/rnbd: fix mixed module-builtin object
>   drm/bridge: imx: fix mixed module-builtin object
>   drm/bridge: imx: turn imx8{qm,qxp}-ldb into single-object modules
>   sound: fix mixed module-builtin object
>   mfd: rsmu: fix mixed module-builtin object
>   mfd: rsmu: turn rsmu-{core,i2c,spi} into single-object modules
>   net: liquidio: fix mixed module-builtin object
>   net: enetc: fix mixed module-builtin object
>   net: emac, cpsw: fix mixed module-builtin object (davinci_cpdma)




Please split this series and send them to each subsystem.
You can grab authorship for 08, 09
since most of the efforts came from you.


Thanks for helping with this work!
  
Alexander Lobakin Nov. 23, 2022, 9:40 p.m. UTC | #8
From: Jakub Kicinski <kuba@kernel.org>
Date: Mon, 21 Nov 2022 11:50:34 -0800

> On Sat, 19 Nov 2022 23:03:57 +0000 Alexander Lobakin wrote:
> > Subject: [PATCH 00/18] treewide: fix object files shared between several modules
> 
> Could you repost the networking changes separately in v2?
> I'm not seeing any reason why this would have to be a treewide
> series when merging.

Yes, it will be split on a per-subsys basis. So this mostly is an
RFC, must've prefixed it <.<

> 
> > monotonic
> 
> monotonous, unless you mean steady progress ;)

Oh thanks, it was "monotonous" actually :D

Olek
  
Alexander Lobakin Feb. 10, 2023, 5:31 p.m. UTC | #9
From: Alexander Lobakin <alobakin@pm.me>
Date: Sat, 19 Nov 2022 23:03:57 +0000

> This is a follow-up to the series[0] that adds Kbuild warning if an
> object is linked into several modules (including vmlinux) in order
> to prevent hidden side effects from appearing.
> The original series, as well as this one, was inspired by the recent
> issue[1] with the ZSTD modules on a platform which has such sets of
> vmlinux cflags and module cflags so that objects built with those
> two even refuse to link with each other.
> The final goal is to forbid linking one object several times
> entirely.

Oh well,

Sorry for quite abandoning the series. A bit busy RN to work on the kernel
outside work. If someone wants to pick patches related to his driver and
send them separately, just how the Ocelot folks did, feel free to.
I'll get back to this one in approx 2-4 weeks.

>
> Patches 1-7 and 10-11 was runtime-tested by me. Pathes 8-9 and 12-18
> are compile-time tested only (compile, link, modpost), so I
> encourage the maintainers to review them carefully. At least the
> last one, for cpsw, most likely has issues :D
> Masahiro's patches are taken from his WIP tree[2], with the two last
> finished by me.

[...]

> --
> 2.38.1

Thanks,
Olek