All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, linux-arm-kernel,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, linux-crypto, linux-decnet-user, linux-ext4,
	linux-fbdev, linux-geode, linux-gpio, linux-hams, linux-hwmon,
	linux-i3c, linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, linux-media, linux-mmc, linux-mm, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches,
	Kees Cook, Gustavo A. R. Silva

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-sctp, linux-renesas-soc, linux-security-module,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-sctp, linux-renesas-soc, linux-security-module,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-sctp, linux-renesas-soc, linux-security-module,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-sctp, linux-renesas-soc, linux-security-module,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: intel-wired-lan

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:21 ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, Gustavo A. R. Silva,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

Hi all,

This series aims to fix almost all remaining fall-through warnings in
order to enable -Wimplicit-fallthrough for Clang.

In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
add multiple break/goto/return/fallthrough statements instead of just
letting the code fall through to the next case.

Notice that in order to enable -Wimplicit-fallthrough for Clang, this
change[1] is meant to be reverted at some point. So, this patch helps
to move in that direction.

Something important to mention is that there is currently a discrepancy
between GCC and Clang when dealing with switch fall-through to empty case
statements or to cases that only contain a break/continue/return
statement[2][3][4].

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

I'm happy to carry this whole series in my own tree if people are OK
with it. :)

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks!

Gustavo A. R. Silva (141):
  afs: Fix fall-through warnings for Clang
  ASoC: codecs: Fix fall-through warnings for Clang
  cifs: Fix fall-through warnings for Clang
  drm/amdgpu: Fix fall-through warnings for Clang
  drm/radeon: Fix fall-through warnings for Clang
  gfs2: Fix fall-through warnings for Clang
  gpio: Fix fall-through warnings for Clang
  IB/hfi1: Fix fall-through warnings for Clang
  igb: Fix fall-through warnings for Clang
  ima: Fix fall-through warnings for Clang
  ipv4: Fix fall-through warnings for Clang
  ixgbe: Fix fall-through warnings for Clang
  media: dvb-frontends: Fix fall-through warnings for Clang
  media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  netfilter: Fix fall-through warnings for Clang
  nfsd: Fix fall-through warnings for Clang
  nfs: Fix fall-through warnings for Clang
  qed: Fix fall-through warnings for Clang
  qlcnic: Fix fall-through warnings for Clang
  scsi: aic7xxx: Fix fall-through warnings for Clang
  scsi: aic94xx: Fix fall-through warnings for Clang
  scsi: bfa: Fix fall-through warnings for Clang
  staging: rtl8723bs: core: Fix fall-through warnings for Clang
  staging: vt6655: Fix fall-through warnings for Clang
  bnxt_en: Fix fall-through warnings for Clang
  ceph: Fix fall-through warnings for Clang
  drbd: Fix fall-through warnings for Clang
  drm/amd/display: Fix fall-through warnings for Clang
  e1000: Fix fall-through warnings for Clang
  ext2: Fix fall-through warnings for Clang
  ext4: Fix fall-through warnings for Clang
  floppy: Fix fall-through warnings for Clang
  fm10k: Fix fall-through warnings for Clang
  IB/mlx4: Fix fall-through warnings for Clang
  IB/qedr: Fix fall-through warnings for Clang
  ice: Fix fall-through warnings for Clang
  Input: pcspkr - Fix fall-through warnings for Clang
  isofs: Fix fall-through warnings for Clang
  ixgbevf: Fix fall-through warnings for Clang
  kprobes/x86: Fix fall-through warnings for Clang
  mm: Fix fall-through warnings for Clang
  net: 3c509: Fix fall-through warnings for Clang
  net: cassini: Fix fall-through warnings for Clang
  net/mlx4: Fix fall-through warnings for Clang
  net: mscc: ocelot: Fix fall-through warnings for Clang
  netxen_nic: Fix fall-through warnings for Clang
  nfp: Fix fall-through warnings for Clang
  perf/x86: Fix fall-through warnings for Clang
  pinctrl: Fix fall-through warnings for Clang
  RDMA/mlx5: Fix fall-through warnings for Clang
  reiserfs: Fix fall-through warnings for Clang
  security: keys: Fix fall-through warnings for Clang
  selinux: Fix fall-through warnings for Clang
  target: Fix fall-through warnings for Clang
  uprobes/x86: Fix fall-through warnings for Clang
  vxge: Fix fall-through warnings for Clang
  watchdog: Fix fall-through warnings for Clang
  xen-blkfront: Fix fall-through warnings for Clang
  regulator: as3722: Fix fall-through warnings for Clang
  habanalabs: Fix fall-through warnings for Clang
  tee: Fix fall-through warnings for Clang
  HID: usbhid: Fix fall-through warnings for Clang
  HID: input: Fix fall-through warnings for Clang
  ACPI: Fix fall-through warnings for Clang
  airo: Fix fall-through warnings for Clang
  ALSA: hdspm: Fix fall-through warnings for Clang
  ALSA: pcsp: Fix fall-through warnings for Clang
  ALSA: sb: Fix fall-through warnings for Clang
  ath5k: Fix fall-through warnings for Clang
  atm: fore200e: Fix fall-through warnings for Clang
  braille_console: Fix fall-through warnings for Clang
  can: peak_usb: Fix fall-through warnings for Clang
  carl9170: Fix fall-through warnings for Clang
  cfg80211: Fix fall-through warnings for Clang
  crypto: ccree - Fix fall-through warnings for Clang
  decnet: Fix fall-through warnings for Clang
  dm raid: Fix fall-through warnings for Clang
  drm/amd/pm: Fix fall-through warnings for Clang
  drm: Fix fall-through warnings for Clang
  drm/i915/gem: Fix fall-through warnings for Clang
  drm/nouveau/clk: Fix fall-through warnings for Clang
  drm/nouveau: Fix fall-through warnings for Clang
  drm/nouveau/therm: Fix fall-through warnings for Clang
  drm/via: Fix fall-through warnings for Clang
  firewire: core: Fix fall-through warnings for Clang
  hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  hwmon: (max6621) Fix fall-through warnings for Clang
  i3c: master: cdns: Fix fall-through warnings for Clang
  ide: Fix fall-through warnings for Clang
  iio: adc: cpcap: Fix fall-through warnings for Clang
  iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  libata: Fix fall-through warnings for Clang
  mac80211: Fix fall-through warnings for Clang
  media: atomisp: Fix fall-through warnings for Clang
  media: dvb_frontend: Fix fall-through warnings for Clang
  media: rcar_jpu: Fix fall-through warnings for Clang
  media: saa7134: Fix fall-through warnings for Clang
  mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  mt76: mt7615: Fix fall-through warnings for Clang
  mtd: cfi: Fix fall-through warnings for Clang
  mtd: mtdchar: Fix fall-through warnings for Clang
  mtd: onenand: Fix fall-through warnings for Clang
  mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  net: ax25: Fix fall-through warnings for Clang
  net: bridge: Fix fall-through warnings for Clang
  net: core: Fix fall-through warnings for Clang
  netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  net: netrom: Fix fall-through warnings for Clang
  net/packet: Fix fall-through warnings for Clang
  net: plip: Fix fall-through warnings for Clang
  net: rose: Fix fall-through warnings for Clang
  nl80211: Fix fall-through warnings for Clang
  phy: qcom-usb-hs: Fix fall-through warnings for Clang
  rds: Fix fall-through warnings for Clang
  rt2x00: Fix fall-through warnings for Clang
  rtl8xxxu: Fix fall-through warnings for Clang
  rtw88: Fix fall-through warnings for Clang
  rxrpc: Fix fall-through warnings for Clang
  scsi: aacraid: Fix fall-through warnings for Clang
  scsi: aha1740: Fix fall-through warnings for Clang
  scsi: csiostor: Fix fall-through warnings for Clang
  scsi: lpfc: Fix fall-through warnings for Clang
  scsi: stex: Fix fall-through warnings for Clang
  sctp: Fix fall-through warnings for Clang
  slimbus: messaging: Fix fall-through warnings for Clang
  staging: qlge: Fix fall-through warnings for Clang
  staging: vt6656: Fix fall-through warnings for Clang
  SUNRPC: Fix fall-through warnings for Clang
  tipc: Fix fall-through warnings for Clang
  tpm: Fix fall-through warnings for Clang
  ubi: Fix fall-through warnings for Clang
  usb: Fix fall-through warnings for Clang
  video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  video: fbdev: pm2fb: Fix fall-through warnings for Clang
  virtio_net: Fix fall-through warnings for Clang
  wcn36xx: Fix fall-through warnings for Clang
  xen/manage: Fix fall-through warnings for Clang
  xfrm: Fix fall-through warnings for Clang
  zd1201: Fix fall-through warnings for Clang
  Input: libps2 - Fix fall-through warnings for Clang

 arch/x86/events/core.c                                    | 2 +-
 arch/x86/kernel/kprobes/core.c                            | 1 +
 arch/x86/kernel/uprobes.c                                 | 2 ++
 drivers/accessibility/braille/braille_console.c           | 1 +
 drivers/acpi/sbshc.c                                      | 1 +
 drivers/ata/libata-eh.c                                   | 1 +
 drivers/atm/fore200e.c                                    | 1 +
 drivers/block/drbd/drbd_receiver.c                        | 1 +
 drivers/block/drbd/drbd_req.c                             | 1 +
 drivers/block/floppy.c                                    | 1 +
 drivers/block/xen-blkfront.c                              | 1 +
 drivers/char/tpm/eventlog/tpm1.c                          | 1 +
 drivers/crypto/ccree/cc_cipher.c                          | 3 +++
 drivers/firewire/core-topology.c                          | 1 +
 drivers/gpio/gpio-ath79.c                                 | 1 +
 drivers/gpio/gpiolib-acpi.c                               | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c                    | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c                     | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c                           | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c         | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c        | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c             | 1 +
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                 | 2 +-
 .../gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c    | 1 +
 drivers/gpu/drm/drm_bufs.c                                | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c              | 1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c                      | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c               | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c            | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c         | 1 +
 drivers/gpu/drm/radeon/ci_dpm.c                           | 2 +-
 drivers/gpu/drm/radeon/r300.c                             | 1 +
 drivers/gpu/drm/radeon/si_dpm.c                           | 2 +-
 drivers/gpu/drm/via/via_irq.c                             | 1 +
 drivers/hid/hid-input.c                                   | 1 +
 drivers/hid/usbhid/hid-core.c                             | 2 ++
 drivers/hwmon/corsair-cpro.c                              | 1 +
 drivers/hwmon/max6621.c                                   | 2 +-
 drivers/i3c/master/i3c-master-cdns.c                      | 2 ++
 drivers/ide/siimage.c                                     | 1 +
 drivers/iio/adc/cpcap-adc.c                               | 1 +
 drivers/infiniband/hw/hfi1/qp.c                           | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c                     | 5 +++++
 drivers/infiniband/hw/mlx4/mad.c                          | 1 +
 drivers/infiniband/hw/mlx5/qp.c                           | 1 +
 drivers/infiniband/hw/qedr/main.c                         | 1 +
 drivers/input/misc/pcspkr.c                               | 1 +
 drivers/input/serio/libps2.c                              | 2 +-
 drivers/md/dm-raid.c                                      | 1 +
 drivers/media/dvb-core/dvb_frontend.c                     | 1 +
 drivers/media/dvb-frontends/cx24120.c                     | 1 +
 drivers/media/dvb-frontends/dib0090.c                     | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c                   | 1 +
 drivers/media/dvb-frontends/m88rs2000.c                   | 1 +
 drivers/media/pci/saa7134/saa7134-tvaudio.c               | 1 +
 drivers/media/platform/rcar_jpu.c                         | 1 +
 drivers/media/usb/dvb-usb-v2/af9015.c                     | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c                    | 1 +
 drivers/misc/habanalabs/gaudi/gaudi.c                     | 1 +
 drivers/mmc/host/sdhci-of-arasan.c                        | 4 ++++
 drivers/mtd/chips/cfi_cmdset_0001.c                       | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c                       | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c                       | 2 ++
 drivers/mtd/mtdchar.c                                     | 1 +
 drivers/mtd/nand/onenand/onenand_samsung.c                | 1 +
 drivers/mtd/nand/raw/fsmc_nand.c                          | 1 +
 drivers/mtd/nand/raw/stm32_fmc2_nand.c                    | 2 ++
 drivers/mtd/ubi/build.c                                   | 1 +
 drivers/net/can/usb/peak_usb/pcan_usb_core.c              | 2 ++
 drivers/net/ethernet/3com/3c509.c                         | 1 +
 drivers/net/ethernet/broadcom/bnxt/bnxt.c                 | 1 +
 drivers/net/ethernet/intel/e1000/e1000_hw.c               | 1 +
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c              | 2 ++
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c             | 1 +
 drivers/net/ethernet/intel/igb/e1000_phy.c                | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c              | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c                  | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c            | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c           | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c              | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c              | 1 +
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c         | 1 +
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c     | 1 +
 drivers/net/ethernet/mscc/ocelot_vcap.c                   | 1 +
 drivers/net/ethernet/neterion/vxge/vxge-config.c          | 1 +
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c         | 1 +
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c      | 1 +
 drivers/net/ethernet/qlogic/qed/qed_l2.c                  | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c               | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c            | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c          | 1 +
 drivers/net/ethernet/sun/cassini.c                        | 1 +
 drivers/net/plip/plip.c                                   | 2 ++
 drivers/net/virtio_net.c                                  | 1 +
 drivers/net/wireless/ath/ath5k/mac80211-ops.c             | 1 +
 drivers/net/wireless/ath/carl9170/tx.c                    | 1 +
 drivers/net/wireless/ath/wcn36xx/smd.c                    | 2 +-
 drivers/net/wireless/cisco/airo.c                         | 1 +
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c              | 2 +-
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c        | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c          | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c     | 8 ++++----
 drivers/net/wireless/realtek/rtw88/fw.c                   | 2 +-
 drivers/net/wireless/zydas/zd1201.c                       | 2 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c                    | 1 +
 drivers/pinctrl/renesas/pinctrl-rza1.c                    | 1 +
 drivers/regulator/as3722-regulator.c                      | 3 ++-
 drivers/scsi/aacraid/commsup.c                            | 1 +
 drivers/scsi/aha1740.c                                    | 1 +
 drivers/scsi/aic7xxx/aic79xx_core.c                       | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c                       | 4 ++--
 drivers/scsi/aic94xx/aic94xx_scb.c                        | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c                       | 2 ++
 drivers/scsi/bfa/bfa_fcs_lport.c                          | 2 +-
 drivers/scsi/bfa/bfa_ioc.c                                | 6 ++++--
 drivers/scsi/csiostor/csio_wr.c                           | 1 +
 drivers/scsi/lpfc/lpfc_bsg.c                              | 1 +
 drivers/scsi/stex.c                                       | 1 +
 drivers/slimbus/messaging.c                               | 1 +
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c   | 1 +
 drivers/staging/qlge/qlge_main.c                          | 1 +
 drivers/staging/rtl8723bs/core/rtw_cmd.c                  | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c             | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c            | 1 +
 drivers/staging/vt6655/device_main.c                      | 1 +
 drivers/staging/vt6655/rxtx.c                             | 2 ++
 drivers/staging/vt6656/main_usb.c                         | 1 +
 drivers/target/target_core_iblock.c                       | 1 +
 drivers/target/target_core_pr.c                           | 1 +
 drivers/tee/tee_core.c                                    | 1 +
 drivers/usb/gadget/function/f_fs.c                        | 2 ++
 drivers/usb/gadget/function/f_loopback.c                  | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c                | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c                        | 2 ++
 drivers/usb/host/fotg210-hcd.c                            | 2 +-
 drivers/usb/host/isp116x-hcd.c                            | 1 +
 drivers/usb/host/max3421-hcd.c                            | 1 +
 drivers/usb/host/oxu210hp-hcd.c                           | 1 +
 drivers/usb/misc/yurex.c                                  | 1 +
 drivers/usb/musb/tusb6010.c                               | 1 +
 drivers/usb/storage/ene_ub6250.c                          | 1 +
 drivers/usb/storage/uas.c                                 | 1 +
 drivers/video/fbdev/geode/lxfb_ops.c                      | 1 +
 drivers/video/fbdev/pm2fb.c                               | 1 +
 drivers/watchdog/machzwd.c                                | 1 +
 drivers/xen/manage.c                                      | 1 +
 fs/afs/cmservice.c                                        | 5 +++++
 fs/afs/fsclient.c                                         | 4 ++++
 fs/afs/vlclient.c                                         | 1 +
 fs/ceph/dir.c                                             | 2 ++
 fs/cifs/inode.c                                           | 1 +
 fs/cifs/sess.c                                            | 1 +
 fs/cifs/smbdirect.c                                       | 1 +
 fs/ext2/inode.c                                           | 1 +
 fs/ext4/super.c                                           | 1 +
 fs/gfs2/inode.c                                           | 2 ++
 fs/gfs2/recovery.c                                        | 1 +
 fs/isofs/rock.c                                           | 1 +
 fs/nfs/nfs3acl.c                                          | 1 +
 fs/nfs/nfs4client.c                                       | 1 +
 fs/nfs/nfs4proc.c                                         | 2 ++
 fs/nfs/nfs4state.c                                        | 1 +
 fs/nfs/pnfs.c                                             | 2 ++
 fs/nfsd/nfs4state.c                                       | 1 +
 fs/nfsd/nfsctl.c                                          | 1 +
 fs/reiserfs/namei.c                                       | 1 +
 mm/mm_init.c                                              | 1 +
 mm/vmscan.c                                               | 1 +
 net/ax25/af_ax25.c                                        | 1 +
 net/bridge/br_input.c                                     | 1 +
 net/core/dev.c                                            | 1 +
 net/decnet/dn_route.c                                     | 2 +-
 net/ipv4/ah4.c                                            | 1 +
 net/ipv4/esp4.c                                           | 1 +
 net/ipv4/fib_semantics.c                                  | 1 +
 net/ipv4/ip_vti.c                                         | 1 +
 net/ipv4/ipcomp.c                                         | 1 +
 net/ipv4/netfilter/ipt_REJECT.c                           | 1 +
 net/mac80211/cfg.c                                        | 2 ++
 net/netfilter/nf_conntrack_proto_dccp.c                   | 1 +
 net/netfilter/nf_tables_api.c                             | 1 +
 net/netfilter/nft_ct.c                                    | 1 +
 net/netrom/nr_route.c                                     | 4 ++++
 net/packet/af_packet.c                                    | 1 +
 net/rds/tcp_connect.c                                     | 1 +
 net/rds/threads.c                                         | 2 ++
 net/rose/rose_route.c                                     | 2 ++
 net/rxrpc/af_rxrpc.c                                      | 1 +
 net/sctp/input.c                                          | 3 ++-
 net/sunrpc/rpc_pipe.c                                     | 1 +
 net/sunrpc/xprtsock.c                                     | 1 +
 net/tipc/link.c                                           | 1 +
 net/wireless/nl80211.c                                    | 1 +
 net/wireless/util.c                                       | 1 +
 net/xfrm/xfrm_interface.c                                 | 1 +
 security/integrity/ima/ima_main.c                         | 1 +
 security/integrity/ima/ima_policy.c                       | 2 ++
 security/keys/process_keys.c                              | 1 +
 security/selinux/hooks.c                                  | 1 +
 sound/drivers/pcsp/pcsp_input.c                           | 1 +
 sound/isa/sb/sb8_main.c                                   | 1 +
 sound/pci/rme9652/hdspm.c                                 | 1 +
 sound/soc/codecs/adav80x.c                                | 1 +
 sound/soc/codecs/arizona.c                                | 1 +
 sound/soc/codecs/cs42l52.c                                | 1 +
 sound/soc/codecs/cs42l56.c                                | 1 +
 sound/soc/codecs/cs47l92.c                                | 1 +
 sound/soc/codecs/wm8962.c                                 | 1 +
 209 files changed, 264 insertions(+), 26 deletions(-)

-- 
2.27.0


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (11 preceding siblings ...)
  (?)
@ 2020-11-20 18:23 ` Gustavo A. R. Silva
  2020-11-20 23:18   ` Joe Perches
  2020-11-23 16:10   ` David Howells
  -1 siblings, 2 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:23 UTC (permalink / raw)
  To: David Howells
  Cc: linux-afs, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple fallthrough pseudo-keywords
in places where the code is intended to fall through to the next
case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/afs/cmservice.c | 5 +++++
 fs/afs/fsclient.c  | 4 ++++
 fs/afs/vlclient.c  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
index a4e9e6e07e93..d17b31dfe63f 100644
--- a/fs/afs/cmservice.c
+++ b/fs/afs/cmservice.c
@@ -322,6 +322,8 @@ static int afs_deliver_cb_callback(struct afs_call *call)
 			return ret;
 
 		call->unmarshall++;
+
+		fallthrough;
 	case 5:
 		break;
 	}
@@ -419,6 +421,7 @@ static int afs_deliver_cb_init_call_back_state3(struct afs_call *call)
 
 		call->unmarshall++;
 
+		fallthrough;
 	case 2:
 		break;
 	}
@@ -531,6 +534,7 @@ static int afs_deliver_cb_probe_uuid(struct afs_call *call)
 
 		call->unmarshall++;
 
+		fallthrough;
 	case 2:
 		break;
 	}
@@ -664,6 +668,7 @@ static int afs_deliver_yfs_cb_callback(struct afs_call *call)
 		afs_extract_to_tmp(call);
 		call->unmarshall++;
 
+		fallthrough;
 	case 3:
 		break;
 	}
diff --git a/fs/afs/fsclient.c b/fs/afs/fsclient.c
index 1d95ed9dd86e..a00eaa155012 100644
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -405,6 +405,7 @@ static int afs_deliver_fs_fetch_data(struct afs_call *call)
 		req->file_size = vp->scb.status.size;
 
 		call->unmarshall++;
+		fallthrough;
 
 	case 5:
 		break;
@@ -1444,6 +1445,7 @@ static int afs_deliver_fs_get_volume_status(struct afs_call *call)
 		_debug("motd '%s'", p);
 
 		call->unmarshall++;
+		fallthrough;
 
 	case 8:
 		break;
@@ -1881,6 +1883,7 @@ static int afs_deliver_fs_inline_bulk_status(struct afs_call *call)
 		xdr_decode_AFSVolSync(&bp, &op->volsync);
 
 		call->unmarshall++;
+		fallthrough;
 
 	case 6:
 		break;
@@ -2015,6 +2018,7 @@ static int afs_deliver_fs_fetch_acl(struct afs_call *call)
 		xdr_decode_AFSVolSync(&bp, &op->volsync);
 
 		call->unmarshall++;
+		fallthrough;
 
 	case 4:
 		break;
diff --git a/fs/afs/vlclient.c b/fs/afs/vlclient.c
index dc9327332f06..29930ea16652 100644
--- a/fs/afs/vlclient.c
+++ b/fs/afs/vlclient.c
@@ -594,6 +594,7 @@ static int afs_deliver_yfsvl_get_endpoints(struct afs_call *call)
 			return ret;
 		call->unmarshall = 6;
 
+		fallthrough;
 	case 6:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 002/141] ASoC: codecs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:23   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:23 UTC (permalink / raw)
  To: Lars-Peter Clausen, Nuno Sá,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	James Schulman, David Rhodes, Charles Keepax, Richard Fitzgerald
  Cc: alsa-devel, linux-kernel, patches, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through, and also add fallthrough pseudo-keywords
in places where the code is intended to fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/soc/codecs/adav80x.c | 1 +
 sound/soc/codecs/arizona.c | 1 +
 sound/soc/codecs/cs42l52.c | 1 +
 sound/soc/codecs/cs42l56.c | 1 +
 sound/soc/codecs/cs47l92.c | 1 +
 sound/soc/codecs/wm8962.c  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/sound/soc/codecs/adav80x.c b/sound/soc/codecs/adav80x.c
index 4fd99280d7db..75a649108106 100644
--- a/sound/soc/codecs/adav80x.c
+++ b/sound/soc/codecs/adav80x.c
@@ -373,6 +373,7 @@ static int adav80x_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 	case SND_SOC_DAIFMT_CBM_CFM:
 		capture |= ADAV80X_CAPTURE_MODE_MASTER;
 		playback |= ADAV80X_PLAYBACK_MODE_MASTER;
+		break;
 	case SND_SOC_DAIFMT_CBS_CFS:
 		break;
 	default:
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 1228f2de0297..e32871b3f68a 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -1034,6 +1034,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w,
 				priv->out_down_delay++;
 				break;
 			}
+			break;
 		default:
 			break;
 		}
diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c
index f772628f233e..796b894c390f 100644
--- a/sound/soc/codecs/cs42l52.c
+++ b/sound/soc/codecs/cs42l52.c
@@ -944,6 +944,7 @@ static int cs42l52_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 261;
+		break;
 	case SND_TONE:
 		break;
 	default:
diff --git a/sound/soc/codecs/cs42l56.c b/sound/soc/codecs/cs42l56.c
index 97024a6ac96d..bb9599cc832b 100644
--- a/sound/soc/codecs/cs42l56.c
+++ b/sound/soc/codecs/cs42l56.c
@@ -1008,6 +1008,7 @@ static int cs42l56_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 261;
+		break;
 	case SND_TONE:
 		break;
 	default:
diff --git a/sound/soc/codecs/cs47l92.c b/sound/soc/codecs/cs47l92.c
index 6e34106c268f..52dc29942ec2 100644
--- a/sound/soc/codecs/cs47l92.c
+++ b/sound/soc/codecs/cs47l92.c
@@ -201,6 +201,7 @@ static int cs47l92_outclk_ev(struct snd_soc_dapm_widget *w,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 0bd3bbc2aacf..3af456010b9c 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3203,6 +3203,7 @@ static int wm8962_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 1000;
+		fallthrough;
 	case SND_TONE:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 002/141] ASoC: codecs: Fix fall-through warnings for Clang
@ 2020-11-20 18:23   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:23 UTC (permalink / raw)
  To: Lars-Peter Clausen, Nuno Sá,
	Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
	James Schulman, David Rhodes, Charles Keepax, Richard Fitzgerald
  Cc: patches, alsa-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through, and also add fallthrough pseudo-keywords
in places where the code is intended to fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/soc/codecs/adav80x.c | 1 +
 sound/soc/codecs/arizona.c | 1 +
 sound/soc/codecs/cs42l52.c | 1 +
 sound/soc/codecs/cs42l56.c | 1 +
 sound/soc/codecs/cs47l92.c | 1 +
 sound/soc/codecs/wm8962.c  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/sound/soc/codecs/adav80x.c b/sound/soc/codecs/adav80x.c
index 4fd99280d7db..75a649108106 100644
--- a/sound/soc/codecs/adav80x.c
+++ b/sound/soc/codecs/adav80x.c
@@ -373,6 +373,7 @@ static int adav80x_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 	case SND_SOC_DAIFMT_CBM_CFM:
 		capture |= ADAV80X_CAPTURE_MODE_MASTER;
 		playback |= ADAV80X_PLAYBACK_MODE_MASTER;
+		break;
 	case SND_SOC_DAIFMT_CBS_CFS:
 		break;
 	default:
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 1228f2de0297..e32871b3f68a 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -1034,6 +1034,7 @@ int arizona_out_ev(struct snd_soc_dapm_widget *w,
 				priv->out_down_delay++;
 				break;
 			}
+			break;
 		default:
 			break;
 		}
diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c
index f772628f233e..796b894c390f 100644
--- a/sound/soc/codecs/cs42l52.c
+++ b/sound/soc/codecs/cs42l52.c
@@ -944,6 +944,7 @@ static int cs42l52_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 261;
+		break;
 	case SND_TONE:
 		break;
 	default:
diff --git a/sound/soc/codecs/cs42l56.c b/sound/soc/codecs/cs42l56.c
index 97024a6ac96d..bb9599cc832b 100644
--- a/sound/soc/codecs/cs42l56.c
+++ b/sound/soc/codecs/cs42l56.c
@@ -1008,6 +1008,7 @@ static int cs42l56_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 261;
+		break;
 	case SND_TONE:
 		break;
 	default:
diff --git a/sound/soc/codecs/cs47l92.c b/sound/soc/codecs/cs47l92.c
index 6e34106c268f..52dc29942ec2 100644
--- a/sound/soc/codecs/cs47l92.c
+++ b/sound/soc/codecs/cs47l92.c
@@ -201,6 +201,7 @@ static int cs47l92_outclk_ev(struct snd_soc_dapm_widget *w,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 0bd3bbc2aacf..3af456010b9c 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3203,6 +3203,7 @@ static int wm8962_beep_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (hz)
 			hz = 1000;
+		fallthrough;
 	case SND_TONE:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 003/141] cifs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (13 preceding siblings ...)
  (?)
@ 2020-11-20 18:24 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Steve French
  Cc: linux-cifs, samba-technical, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break/goto statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/cifs/inode.c     | 1 +
 fs/cifs/sess.c      | 1 +
 fs/cifs/smbdirect.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 9ee5f304592f..ac01f9684b39 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -771,6 +771,7 @@ cifs_get_file_info(struct file *filp)
 		 */
 		rc = 0;
 		CIFS_I(inode)->time = 0;
+		goto cgfi_exit;
 	default:
 		goto cgfi_exit;
 	}
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index de564368a887..6c2c42f8d893 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -812,6 +812,7 @@ cifs_select_sectype(struct TCP_Server_Info *server, enum securityEnum requested)
 				return NTLMv2;
 			if (global_secflags & CIFSSEC_MAY_NTLM)
 				return NTLM;
+			break;
 		default:
 			break;
 		}
diff --git a/fs/cifs/smbdirect.c b/fs/cifs/smbdirect.c
index b029ed31ef91..10dfe5006792 100644
--- a/fs/cifs/smbdirect.c
+++ b/fs/cifs/smbdirect.c
@@ -246,6 +246,7 @@ smbd_qp_async_error_upcall(struct ib_event *event, void *context)
 	case IB_EVENT_CQ_ERR:
 	case IB_EVENT_QP_FATAL:
 		smbd_disconnect_rdma_connection(info);
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: amd-gfx, dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 3579565e0eab..98ca6b976b6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 0d8e203b10ef..e61121629b93 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3ebbddb63705..584b99b80c29 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
 				WREG32(reg, tmp);
 			}
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 9bcd0eebc6d7..d56b474b3a21 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
 	case CHIP_POLARIS12:
 	case CHIP_VEGAM:
 		vi_common_set_clockgating_state_by_smu(adev, state);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 3579565e0eab..98ca6b976b6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 0d8e203b10ef..e61121629b93 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3ebbddb63705..584b99b80c29 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
 				WREG32(reg, tmp);
 			}
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 9bcd0eebc6d7..d56b474b3a21 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
 	case CHIP_POLARIS12:
 	case CHIP_VEGAM:
 		vi_common_set_clockgating_state_by_smu(adev, state);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
 drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 3579565e0eab..98ca6b976b6e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 0d8e203b10ef..e61121629b93 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
 		WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
 			       PRIV_INSTR_INT_ENABLE,
 			       state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3ebbddb63705..584b99b80c29 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
 				WREG32(reg, tmp);
 			}
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 9bcd0eebc6d7..d56b474b3a21 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
 	case CHIP_POLARIS12:
 	case CHIP_VEGAM:
 		vi_common_set_clockgating_state_by_smu(adev, state);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: amd-gfx, dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
as replacement for /* fall through */ comments.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 drivers/gpu/drm/radeon/r300.c   | 1 +
 drivers/gpu/drm/radeon/si_dpm.c | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 886e9959496f..3d0a2e81b2de 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
 			break;
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 73f67bf222e1..213dc49b6322 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
 		/* valid register only on RV530 */
 		if (p->rdev->family == CHIP_RV530)
 			break;
+		fallthrough;
 		/* fallthrough do not move */
 	default:
 		goto fail;
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d1c73e9db889..d19c08e0ad5a 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
as replacement for /* fall through */ comments.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 drivers/gpu/drm/radeon/r300.c   | 1 +
 drivers/gpu/drm/radeon/si_dpm.c | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 886e9959496f..3d0a2e81b2de 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
 			break;
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 73f67bf222e1..213dc49b6322 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
 		/* valid register only on RV530 */
 		if (p->rdev->family == CHIP_RV530)
 			break;
+		fallthrough;
 		/* fallthrough do not move */
 	default:
 		goto fail;
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d1c73e9db889..d19c08e0ad5a 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
 			break;
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
@ 2020-11-20 18:24   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:24 UTC (permalink / raw)
  To: Alex Deucher, Christian König, David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
as replacement for /* fall through */ comments.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 drivers/gpu/drm/radeon/r300.c   | 1 +
 drivers/gpu/drm/radeon/si_dpm.c | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 886e9959496f..3d0a2e81b2de 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
 			break;
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 73f67bf222e1..213dc49b6322 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
 		/* valid register only on RV530 */
 		if (p->rdev->family == CHIP_RV530)
 			break;
+		fallthrough;
 		/* fallthrough do not move */
 	default:
 		goto fail;
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d1c73e9db889..d19c08e0ad5a 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
 		case RADEON_PCIE_GEN2:
 			if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
 			break;
-- 
2.27.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 006/141] gfs2: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:25   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Bob Peterson, Andreas Gruenbacher
  Cc: cluster-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple goto statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/gfs2/inode.c    | 2 ++
 fs/gfs2/recovery.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 077ccb1b3ccc..9a85214c2505 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -960,6 +960,7 @@ static int gfs2_link(struct dentry *old_dentry, struct inode *dir,
 		break;
 	case 0:
 		error = -EEXIST;
+		goto out_gunlock;
 	default:
 		goto out_gunlock;
 	}
@@ -1500,6 +1501,7 @@ static int gfs2_rename(struct inode *odir, struct dentry *odentry,
 			break;
 		case 0:
 			error = -EEXIST;
+			goto out_gunlock;
 		default:
 			goto out_gunlock;
 		}
diff --git a/fs/gfs2/recovery.c b/fs/gfs2/recovery.c
index c26c68ebd29d..5b2a01d9c463 100644
--- a/fs/gfs2/recovery.c
+++ b/fs/gfs2/recovery.c
@@ -437,6 +437,7 @@ void gfs2_recover_func(struct work_struct *work)
 		case GLR_TRYFAILED:
 			fs_info(sdp, "jid=%u: Busy\n", jd->jd_jid);
 			error = 0;
+			goto fail;
 
 		default:
 			goto fail;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 006/141] gfs2: Fix fall-through warnings for Clang
@ 2020-11-20 18:25   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: cluster-devel.redhat.com

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple goto statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/gfs2/inode.c    | 2 ++
 fs/gfs2/recovery.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 077ccb1b3ccc..9a85214c2505 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -960,6 +960,7 @@ static int gfs2_link(struct dentry *old_dentry, struct inode *dir,
 		break;
 	case 0:
 		error = -EEXIST;
+		goto out_gunlock;
 	default:
 		goto out_gunlock;
 	}
@@ -1500,6 +1501,7 @@ static int gfs2_rename(struct inode *odir, struct dentry *odentry,
 			break;
 		case 0:
 			error = -EEXIST;
+			goto out_gunlock;
 		default:
 			goto out_gunlock;
 		}
diff --git a/fs/gfs2/recovery.c b/fs/gfs2/recovery.c
index c26c68ebd29d..5b2a01d9c463 100644
--- a/fs/gfs2/recovery.c
+++ b/fs/gfs2/recovery.c
@@ -437,6 +437,7 @@ void gfs2_recover_func(struct work_struct *work)
 		case GLR_TRYFAILED:
 			fs_info(sdp, "jid=%u: Busy\n", jd->jd_jid);
 			error = 0;
+			goto fail;
 
 		default:
 			goto fail;
-- 
2.27.0



^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 007/141] gpio: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (17 preceding siblings ...)
  (?)
@ 2020-11-20 18:25 ` Gustavo A. R. Silva
  2020-11-20 18:56   ` Andy Shevchenko
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Alban Bedel, Linus Walleij, Bartosz Golaszewski, Mika Westerberg,
	Andy Shevchenko
  Cc: linux-gpio, linux-kernel, linux-acpi, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a break and a fallthrough statements
instead of just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpio/gpio-ath79.c   | 1 +
 drivers/gpio/gpiolib-acpi.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index d5359341cc6b..678ddd375891 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -123,6 +123,7 @@ static int ath79_gpio_irq_set_type(struct irq_data *data,
 	switch (flow_type) {
 	case IRQ_TYPE_EDGE_RISING:
 		polarity |= mask;
+		fallthrough;
 	case IRQ_TYPE_EDGE_FALLING:
 	case IRQ_TYPE_EDGE_BOTH:
 		break;
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index 834a12f3219e..23fa9df8241d 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -548,6 +548,7 @@ acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 008/141] IB/hfi1: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (18 preceding siblings ...)
  (?)
@ 2020-11-20 18:25 ` Gustavo A. R. Silva
  2020-11-22 14:30   ` Mike Marciniszyn
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Mike Marciniszyn, Dennis Dalessandro, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/infiniband/hw/hfi1/qp.c       | 1 +
 drivers/infiniband/hw/hfi1/tid_rdma.c | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/drivers/infiniband/hw/hfi1/qp.c b/drivers/infiniband/hw/hfi1/qp.c
index 356518e17fa6..681bb4e918c9 100644
--- a/drivers/infiniband/hw/hfi1/qp.c
+++ b/drivers/infiniband/hw/hfi1/qp.c
@@ -339,6 +339,7 @@ int hfi1_setup_wqe(struct rvt_qp *qp, struct rvt_swqe *wqe, bool *call_send)
 			return -EINVAL;
 		if (ibp->sl_to_sc[rdma_ah_get_sl(&ah->attr)] == 0xf)
 			return -EINVAL;
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/infiniband/hw/hfi1/tid_rdma.c b/drivers/infiniband/hw/hfi1/tid_rdma.c
index 73d197e21730..92aa2a9b3b5a 100644
--- a/drivers/infiniband/hw/hfi1/tid_rdma.c
+++ b/drivers/infiniband/hw/hfi1/tid_rdma.c
@@ -2826,6 +2826,7 @@ static bool handle_read_kdeth_eflags(struct hfi1_ctxtdata *rcd,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
@@ -3005,6 +3006,7 @@ bool hfi1_handle_kdeth_eflags(struct hfi1_ctxtdata *rcd,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
@@ -3221,6 +3223,7 @@ bool hfi1_tid_rdma_wqe_interlock(struct rvt_qp *qp, struct rvt_swqe *wqe)
 			req = wqe_to_tid_req(prev);
 			if (req->ack_seg != req->total_segs)
 				goto interlock;
+			break;
 		default:
 			break;
 		}
@@ -3239,9 +3242,11 @@ bool hfi1_tid_rdma_wqe_interlock(struct rvt_qp *qp, struct rvt_swqe *wqe)
 			req = wqe_to_tid_req(prev);
 			if (req->ack_seg != req->total_segs)
 				goto interlock;
+			break;
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 009/141] igb: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:25   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/igb/e1000_phy.c   | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c     | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 8c8eb82e6272..a018000f7db9 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -836,6 +836,7 @@ s32 igb_copper_link_setup_igp(struct e1000_hw *hw)
 			break;
 		case e1000_ms_auto:
 			data &= ~CR_1000T_MS_ENABLE;
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 28baf203459a..486d3e67d3a9 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -3022,6 +3022,7 @@ static int igb_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
 		break;
 	case ETHTOOL_SRXCLSRLDEL:
 		ret = igb_del_ethtool_nfc_entry(adapter, cmd);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 7cc5428c3b3d..f3ff565da0a1 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -1008,6 +1008,7 @@ static int igb_ptp_set_timestamp_mode(struct igb_adapter *adapter,
 	switch (config->tx_type) {
 	case HWTSTAMP_TX_OFF:
 		tsync_tx_ctl = 0;
+		break;
 	case HWTSTAMP_TX_ON:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 009/141] igb: Fix fall-through warnings for Clang
@ 2020-11-20 18:25   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/igb/e1000_phy.c   | 1 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c | 1 +
 drivers/net/ethernet/intel/igb/igb_ptp.c     | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c
index 8c8eb82e6272..a018000f7db9 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -836,6 +836,7 @@ s32 igb_copper_link_setup_igp(struct e1000_hw *hw)
 			break;
 		case e1000_ms_auto:
 			data &= ~CR_1000T_MS_ENABLE;
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 28baf203459a..486d3e67d3a9 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -3022,6 +3022,7 @@ static int igb_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
 		break;
 	case ETHTOOL_SRXCLSRLDEL:
 		ret = igb_del_ethtool_nfc_entry(adapter, cmd);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 7cc5428c3b3d..f3ff565da0a1 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -1008,6 +1008,7 @@ static int igb_ptp_set_timestamp_mode(struct igb_adapter *adapter,
 	switch (config->tx_type) {
 	case HWTSTAMP_TX_OFF:
 		tsync_tx_ctl = 0;
+		break;
 	case HWTSTAMP_TX_ON:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 010/141] ima: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (20 preceding siblings ...)
  (?)
@ 2020-11-20 18:25 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Mimi Zohar, Dmitry Kasatkin, James Morris, Serge E. Hallyn
  Cc: linux-integrity, linux-security-module, linux-kernel,
	linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 security/integrity/ima/ima_main.c   | 1 +
 security/integrity/ima/ima_policy.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 2d1af8899cab..600b97677085 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -743,6 +743,7 @@ int ima_load_data(enum kernel_load_data_id id, bool contents)
 			pr_err("impossible to appraise a module without a file descriptor. sig_enforce kernel parameter might help\n");
 			return -EACCES;	/* INTEGRITY_UNKNOWN */
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 9b5adeaa47fc..ea634fc3b82f 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -566,6 +566,7 @@ static bool ima_match_rules(struct ima_rule_entry *rule, struct inode *inode,
 			rc = ima_filter_rule_match(secid, rule->lsm[i].type,
 						   Audit_equal,
 						   rule->lsm[i].rule);
+			break;
 		default:
 			break;
 		}
@@ -802,6 +803,7 @@ void __init ima_init_policy(void)
 		add_rules(default_measurement_rules,
 			  ARRAY_SIZE(default_measurement_rules),
 			  IMA_DEFAULT_POLICY);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 011/141] ipv4: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (21 preceding siblings ...)
  (?)
@ 2020-11-20 18:25 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:25 UTC (permalink / raw)
  To: Steffen Klassert, Herbert Xu, David S. Miller, Alexey Kuznetsov,
	Hideaki YOSHIFUJI, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/ipv4/ah4.c           | 1 +
 net/ipv4/esp4.c          | 1 +
 net/ipv4/fib_semantics.c | 1 +
 net/ipv4/ip_vti.c        | 1 +
 net/ipv4/ipcomp.c        | 1 +
 5 files changed, 5 insertions(+)

diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index d99e1be94019..18d451414601 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -450,6 +450,7 @@ static int ah4_err(struct sk_buff *skb, u32 info)
 	case ICMP_DEST_UNREACH:
 		if (icmp_hdr(skb)->code != ICMP_FRAG_NEEDED)
 			return 0;
+		break;
 	case ICMP_REDIRECT:
 		break;
 	default:
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 8b07f3a4f2db..a12ef89e8520 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -987,6 +987,7 @@ static int esp4_err(struct sk_buff *skb, u32 info)
 	case ICMP_DEST_UNREACH:
 		if (icmp_hdr(skb)->code != ICMP_FRAG_NEEDED)
 			return 0;
+		break;
 	case ICMP_REDIRECT:
 		break;
 	default:
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 1f75dc686b6b..647a67516b80 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1872,6 +1872,7 @@ static int call_fib_nh_notifiers(struct fib_nh *nh,
 		    (nh->fib_nh_flags & RTNH_F_DEAD))
 			return call_fib4_notifiers(dev_net(nh->fib_nh_dev),
 						   event_type, &info.info);
+		break;
 	default:
 		break;
 	}
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index b957cbee2cf7..60e0311ec51f 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -349,6 +349,7 @@ static int vti4_err(struct sk_buff *skb, u32 info)
 	case ICMP_DEST_UNREACH:
 		if (icmp_hdr(skb)->code != ICMP_FRAG_NEEDED)
 			return 0;
+		break;
 	case ICMP_REDIRECT:
 		break;
 	default:
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index b42683212c65..bbb56f5e06dd 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -31,6 +31,7 @@ static int ipcomp4_err(struct sk_buff *skb, u32 info)
 	case ICMP_DEST_UNREACH:
 		if (icmp_hdr(skb)->code != ICMP_FRAG_NEEDED)
 			return 0;
+		break;
 	case ICMP_REDIRECT:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 012/141] ixgbe: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:26   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c  | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c    | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c    | 1 +
 4 files changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 8d3798a32f0e..cdfff510a27b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -1542,6 +1542,7 @@ s32 ixgbe_fdir_set_input_mask_82599(struct ixgbe_hw *hw,
 	switch (input_mask->formatted.vm_pool & 0x7F) {
 	case 0x0:
 		fdirm |= IXGBE_FDIRM_POOL;
+		break;
 	case 0x7F:
 		break;
 	default:
@@ -1557,6 +1558,7 @@ s32 ixgbe_fdir_set_input_mask_82599(struct ixgbe_hw *hw,
 			hw_dbg(hw, " Error on src/dst port mask\n");
 			return IXGBE_ERR_CONFIG;
 		}
+		break;
 	case IXGBE_ATR_L4TYPE_MASK:
 		break;
 	default:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 62ddb452f862..8d5a01be1d99 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -93,6 +93,7 @@ bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index df389a11d3af..0218f6c9b925 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -132,6 +132,7 @@ static void ixgbe_get_first_reg_idx(struct ixgbe_adapter *adapter, u8 tc,
 			else
 				*tx = (tc + 4) << 4;	/* 96, 112 */
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 22a874eee2e8..23ddfd79fc8b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -999,6 +999,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,
 	switch (config->tx_type) {
 	case HWTSTAMP_TX_OFF:
 		tsync_tx_ctl = 0;
+		break;
 	case HWTSTAMP_TX_ON:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 012/141] ixgbe: Fix fall-through warnings for Clang
@ 2020-11-20 18:26   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c  | 2 ++
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c    | 1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c    | 1 +
 4 files changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 8d3798a32f0e..cdfff510a27b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -1542,6 +1542,7 @@ s32 ixgbe_fdir_set_input_mask_82599(struct ixgbe_hw *hw,
 	switch (input_mask->formatted.vm_pool & 0x7F) {
 	case 0x0:
 		fdirm |= IXGBE_FDIRM_POOL;
+		break;
 	case 0x7F:
 		break;
 	default:
@@ -1557,6 +1558,7 @@ s32 ixgbe_fdir_set_input_mask_82599(struct ixgbe_hw *hw,
 			hw_dbg(hw, " Error on src/dst port mask\n");
 			return IXGBE_ERR_CONFIG;
 		}
+		break;
 	case IXGBE_ATR_L4TYPE_MASK:
 		break;
 	default:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 62ddb452f862..8d5a01be1d99 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -93,6 +93,7 @@ bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index df389a11d3af..0218f6c9b925 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -132,6 +132,7 @@ static void ixgbe_get_first_reg_idx(struct ixgbe_adapter *adapter, u8 tc,
 			else
 				*tx = (tc + 4) << 4;	/* 96, 112 */
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 22a874eee2e8..23ddfd79fc8b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -999,6 +999,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,
 	switch (config->tx_type) {
 	case HWTSTAMP_TX_OFF:
 		tsync_tx_ctl = 0;
+		break;
 	case HWTSTAMP_TX_ON:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 013/141] media: dvb-frontends: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (23 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  2020-11-22 16:31   ` Mauro Carvalho Chehab
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Jemma Denson, Patrick Boettcher, Mauro Carvalho Chehab,
	Malcolm Priestley
  Cc: linux-media, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break and a return statements
instead of just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/media/dvb-frontends/cx24120.c   | 1 +
 drivers/media/dvb-frontends/dib0090.c   | 2 ++
 drivers/media/dvb-frontends/drxk_hard.c | 1 +
 drivers/media/dvb-frontends/m88rs2000.c | 1 +
 4 files changed, 5 insertions(+)

diff --git a/drivers/media/dvb-frontends/cx24120.c b/drivers/media/dvb-frontends/cx24120.c
index 2464b63fe0cf..d8acd582c711 100644
--- a/drivers/media/dvb-frontends/cx24120.c
+++ b/drivers/media/dvb-frontends/cx24120.c
@@ -363,6 +363,7 @@ static void cx24120_check_cmd(struct cx24120_state *state, u8 id)
 	case CMD_DISEQC_BURST:
 		cx24120_msg_mpeg_output_global_config(state, 0);
 		/* Old driver would do a msleep(100) here */
+		return;
 	default:
 		return;
 	}
diff --git a/drivers/media/dvb-frontends/dib0090.c b/drivers/media/dvb-frontends/dib0090.c
index 08a85831e917..903da33642df 100644
--- a/drivers/media/dvb-frontends/dib0090.c
+++ b/drivers/media/dvb-frontends/dib0090.c
@@ -1765,6 +1765,8 @@ static int dib0090_dc_offset_calibration(struct dib0090_state *state, enum front
 		dib0090_write_reg(state, 0x1f, 0x7);
 		*tune_state = CT_TUNER_START;	/* reset done -> real tuning can now begin */
 		state->calibrate &= ~DC_CAL;
+		break;
+
 	default:
 		break;
 	}
diff --git a/drivers/media/dvb-frontends/drxk_hard.c b/drivers/media/dvb-frontends/drxk_hard.c
index a57470bf71bf..d7fc2595f15b 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -3294,6 +3294,7 @@ static int dvbt_sc_command(struct drxk_state *state,
 	case OFDM_SC_RA_RAM_CMD_USER_IO:
 	case OFDM_SC_RA_RAM_CMD_GET_OP_PARAM:
 		status = read16(state, OFDM_SC_RA_RAM_PARAM0__A, &(param0));
+		break;
 		/* All commands yielding 0 results */
 	case OFDM_SC_RA_RAM_CMD_SET_ECHO_TIMING:
 	case OFDM_SC_RA_RAM_CMD_SET_TIMER:
diff --git a/drivers/media/dvb-frontends/m88rs2000.c b/drivers/media/dvb-frontends/m88rs2000.c
index 39cbb3ea1c9d..b294ba87e934 100644
--- a/drivers/media/dvb-frontends/m88rs2000.c
+++ b/drivers/media/dvb-frontends/m88rs2000.c
@@ -390,6 +390,7 @@ static int m88rs2000_tab_set(struct m88rs2000_state *state,
 		case 0xff:
 			if (tab[i].reg == 0xaa && tab[i].val == 0xff)
 				return 0;
+			break;
 		case 0x00:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 014/141] media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (24 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  2020-11-22 16:31   ` Mauro Carvalho Chehab
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Antti Palosaari, Mauro Carvalho Chehab, Malcolm Priestley
  Cc: linux-media, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/media/usb/dvb-usb-v2/af9015.c  | 1 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c b/drivers/media/usb/dvb-usb-v2/af9015.c
index c70b3cef3176..d33514acc2b5 100644
--- a/drivers/media/usb/dvb-usb-v2/af9015.c
+++ b/drivers/media/usb/dvb-usb-v2/af9015.c
@@ -51,6 +51,7 @@ static int af9015_ctrl_msg(struct dvb_usb_device *d, struct req_t *req)
 		if (((req->addr & 0xff00) == 0xff00) ||
 		    ((req->addr & 0xff00) == 0xae00))
 			state->buf[0] = WRITE_VIRTUAL_MEMORY;
+		break;
 	case WRITE_VIRTUAL_MEMORY:
 	case COPY_FIRMWARE:
 	case DOWNLOAD_FIRMWARE:
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 5a7a9522d46d..67c37fb267e3 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -336,6 +336,7 @@ static void lme2510_int_response(struct urb *lme_urb)
 				st->signal_level = ibuf[5];
 				st->signal_sn = ibuf[4];
 				st->time_key = ibuf[7];
+				break;
 			default:
 				break;
 			}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 015/141] netfilter: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (25 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  2020-11-20 22:47   ` Florian Westphal
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, Jakub Kicinski
  Cc: netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/netfilter/nf_conntrack_proto_dccp.c | 1 +
 net/netfilter/nf_tables_api.c           | 1 +
 net/netfilter/nft_ct.c                  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
index b3f4a334f9d7..94001eb51ffe 100644
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -397,6 +397,7 @@ dccp_new(struct nf_conn *ct, const struct sk_buff *skb,
 			msg = "not picking up existing connection ";
 			goto out_invalid;
 		}
+		break;
 	case CT_DCCP_REQUEST:
 		break;
 	case CT_DCCP_INVALID:
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 0f58e98542be..78d0bbc8868c 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -8342,6 +8342,7 @@ static int nf_tables_check_loops(const struct nft_ctx *ctx,
 							data->verdict.chain);
 				if (err < 0)
 					return err;
+				break;
 			default:
 				break;
 			}
diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c
index 322bd674963e..fec68b75f39a 100644
--- a/net/netfilter/nft_ct.c
+++ b/net/netfilter/nft_ct.c
@@ -530,6 +530,7 @@ static void __nft_ct_set_destroy(const struct nft_ctx *ctx, struct nft_ct *priv)
 	case NFT_CT_ZONE:
 		if (--nft_ct_pcpu_template_refcnt == 0)
 			nft_ct_tmpl_put_pcpu();
+		break;
 #endif
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 016/141] nfsd: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (26 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  2020-11-20 18:27   ` Chuck Lever
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: J. Bruce Fields, Chuck Lever
  Cc: linux-nfs, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/nfsd/nfs4state.c | 1 +
 fs/nfsd/nfsctl.c    | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index d7f27ed6b794..cdab0d5be186 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3113,6 +3113,7 @@ nfsd4_exchange_id(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
 			goto out_nolock;
 		}
 		new->cl_mach_cred = true;
+		break;
 	case SP4_NONE:
 		break;
 	default:				/* checked by xdr code */
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index f6d5d783f4a4..9a3bb1e217f9 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -1165,6 +1165,7 @@ static struct inode *nfsd_get_inode(struct super_block *sb, umode_t mode)
 		inode->i_fop = &simple_dir_operations;
 		inode->i_op = &simple_dir_inode_operations;
 		inc_nlink(inode);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 017/141] nfs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (27 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Trond Myklebust, Anna Schumaker
  Cc: linux-nfs, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly add multiple break/goto/return/fallthrough
statements instead of just letting the code fall through to the next
case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/nfs/nfs3acl.c    | 1 +
 fs/nfs/nfs4client.c | 1 +
 fs/nfs/nfs4proc.c   | 2 ++
 fs/nfs/nfs4state.c  | 1 +
 fs/nfs/pnfs.c       | 2 ++
 5 files changed, 7 insertions(+)

diff --git a/fs/nfs/nfs3acl.c b/fs/nfs/nfs3acl.c
index c6c863382f37..68e206cf4c4e 100644
--- a/fs/nfs/nfs3acl.c
+++ b/fs/nfs/nfs3acl.c
@@ -111,6 +111,7 @@ struct posix_acl *nfs3_get_acl(struct inode *inode, int type)
 			fallthrough;
 		case -ENOTSUPP:
 			status = -EOPNOTSUPP;
+			goto getout;
 		default:
 			goto getout;
 	}
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index be7915c861ce..4bdd256b725a 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -609,6 +609,7 @@ int nfs40_walk_client_list(struct nfs_client *new,
 			 * changed. Schedule recovery!
 			 */
 			nfs4_schedule_path_down_recovery(pos);
+			goto out;
 		default:
 			goto out;
 		}
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 9e0ca9b2b210..98c9f3197647 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2229,6 +2229,7 @@ static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct
 		default:
 			printk(KERN_ERR "NFS: %s: unhandled error "
 					"%d.\n", __func__, err);
+			fallthrough;
 		case 0:
 		case -ENOENT:
 		case -EAGAIN:
@@ -9698,6 +9699,7 @@ nfs4_layoutcommit_done(struct rpc_task *task, void *calldata)
 	case -NFS4ERR_BADLAYOUT:     /* no layout */
 	case -NFS4ERR_GRACE:	    /* loca_recalim always false */
 		task->tk_status = 0;
+		break;
 	case 0:
 		break;
 	default:
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 4bf10792cb5b..3a51351bdc6a 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1125,6 +1125,7 @@ static void nfs_increment_seqid(int status, struct nfs_seqid *seqid)
 					" sequence-id error on an"
 					" unconfirmed sequence %p!\n",
 					seqid->sequence);
+			return;
 		case -NFS4ERR_STALE_CLIENTID:
 		case -NFS4ERR_STALE_STATEID:
 		case -NFS4ERR_BAD_STATEID:
diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
index 0e50b9d45c32..7f71f4f8347f 100644
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2824,6 +2824,7 @@ pnfs_do_write(struct nfs_pageio_descriptor *desc,
 	switch (trypnfs) {
 	case PNFS_NOT_ATTEMPTED:
 		pnfs_write_through_mds(desc, hdr);
+		break;
 	case PNFS_ATTEMPTED:
 		break;
 	case PNFS_TRY_AGAIN:
@@ -2968,6 +2969,7 @@ pnfs_do_read(struct nfs_pageio_descriptor *desc, struct nfs_pgio_header *hdr)
 	switch (trypnfs) {
 	case PNFS_NOT_ATTEMPTED:
 		pnfs_read_through_mds(desc, hdr);
+		break;
 	case PNFS_ATTEMPTED:
 		break;
 	case PNFS_TRY_AGAIN:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 018/141] qed: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (28 preceding siblings ...)
  (?)
@ 2020-11-20 18:26 ` Gustavo A. R. Silva
  2020-11-20 18:50   ` [EXT] " Igor Russkikh
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:26 UTC (permalink / raw)
  To: Ariel Elior, David S. Miller, Jakub Kicinski
  Cc: GR-everest-linux-l2, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/qlogic/qed/qed_l2.c    | 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 07824bf9d68d..dfaf10edfabf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -396,6 +396,7 @@ int qed_sp_eth_vport_start(struct qed_hwfn *p_hwfn,
 		tpa_param->tpa_ipv6_en_flg = 1;
 		tpa_param->tpa_pkt_split_flg = 1;
 		tpa_param->tpa_gro_consistent_flg = 1;
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index b8dc5c4591ef..ed2b6fe5a78d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -4734,6 +4734,7 @@ void qed_inform_vf_link_state(struct qed_hwfn *hwfn)
 			 */
 			link.speed = (hwfn->cdev->num_hwfns > 1) ?
 				     100000 : 40000;
+			break;
 		default:
 			/* In auto mode pass PF link image to VF */
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 019/141] qlcnic: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (29 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Shahed Shaikh, Manish Chopra, David S. Miller, Jakub Kicinski
  Cc: GR-Linux-NIC-Dev, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a break and a goto statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c   | 1 +
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index bdf15d2a6431..af4c516a9e7c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -1390,6 +1390,7 @@ static int qlcnic_process_rcv_ring(struct qlcnic_host_sds_ring *sds_ring, int ma
 			break;
 		case QLCNIC_RESPONSE_DESC:
 			qlcnic_handle_fw_message(desc_cnt, consumer, sds_ring);
+			goto skip;
 		default:
 			goto skip;
 		}
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 5a7e240fd469..3abbd22e2ed3 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -3456,6 +3456,7 @@ qlcnic_fwinit_work(struct work_struct *work)
 			adapter->fw_wait_cnt = 0;
 			return;
 		}
+		break;
 	case QLCNIC_DEV_FAILED:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 020/141] scsi: aic7xxx: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (30 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Hannes Reinecke, James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case, and by adding fallthrough
statements in places where the code is intended to fall through, and
finally by replacing /* FALLTHROUGH */ comments with the new
pseudo-keyword macro fallthrough.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/aic7xxx/aic79xx_core.c | 4 +++-
 drivers/scsi/aic7xxx/aic7xxx_core.c | 4 ++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c b/drivers/scsi/aic7xxx/aic79xx_core.c
index 98b02e7d38bb..dd8d6646b06f 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -6130,6 +6130,7 @@ ahd_free(struct ahd_softc *ahd)
 		fallthrough;
 	case 2:
 		ahd_dma_tag_destroy(ahd, ahd->shared_data_dmat);
+		break;
 	case 1:
 		break;
 	case 0:
@@ -6542,8 +6543,8 @@ ahd_fini_scbdata(struct ahd_softc *ahd)
 			kfree(hscb_map);
 		}
 		ahd_dma_tag_destroy(ahd, scb_data->hscb_dmat);
-		/* FALLTHROUGH */
 	}
+		fallthrough;
 	case 4:
 	case 3:
 	case 2:
@@ -8911,6 +8912,7 @@ ahd_handle_scsi_status(struct ahd_softc *ahd, struct scb *scb)
 					break;
 				case SIU_PFC_ILLEGAL_REQUEST:
 					printk("Illegal request\n");
+					break;
 				default:
 					break;
 				}
diff --git a/drivers/scsi/aic7xxx/aic7xxx_core.c b/drivers/scsi/aic7xxx/aic7xxx_core.c
index 725bb7f58054..2df664e3e954 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_core.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_core.c
@@ -4478,6 +4478,7 @@ ahc_free(struct ahc_softc *ahc)
 		fallthrough;
 	case 2:
 		ahc_dma_tag_destroy(ahc, ahc->shared_data_dmat);
+		fallthrough;
 	case 1:
 		break;
 	case 0:
@@ -5867,9 +5868,8 @@ ahc_search_qinfifo(struct ahc_softc *ahc, int target, char channel,
 				if ((scb->flags & SCB_ACTIVE) == 0)
 					printk("Inactive SCB in qinfifo\n");
 				ahc_done(ahc, scb);
-
-				/* FALLTHROUGH */
 			}
+				fallthrough;
 			case SEARCH_REMOVE:
 				break;
 			case SEARCH_COUNT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 021/141] scsi: aic94xx: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (31 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break and fallthrough statements
instead of just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/aic94xx/aic94xx_scb.c  | 2 ++
 drivers/scsi/aic94xx/aic94xx_task.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/scsi/aic94xx/aic94xx_scb.c b/drivers/scsi/aic94xx/aic94xx_scb.c
index e2d880a5f391..13677973da5c 100644
--- a/drivers/scsi/aic94xx/aic94xx_scb.c
+++ b/drivers/scsi/aic94xx/aic94xx_scb.c
@@ -721,6 +721,7 @@ static void set_speed_mask(u8 *speed_mask, struct asd_phy_desc *pd)
 		fallthrough;
 	case SAS_LINK_RATE_3_0_GBPS:
 		*speed_mask |= SAS_SPEED_15_DIS;
+		fallthrough;
 	default:
 	case SAS_LINK_RATE_1_5_GBPS:
 		/* nothing to do */
@@ -739,6 +740,7 @@ static void set_speed_mask(u8 *speed_mask, struct asd_phy_desc *pd)
 	switch (pd->min_sata_lrate) {
 	case SAS_LINK_RATE_3_0_GBPS:
 		*speed_mask |= SATA_SPEED_15_DIS;
+		fallthrough;
 	default:
 	case SAS_LINK_RATE_1_5_GBPS:
 		/* nothing to do */
diff --git a/drivers/scsi/aic94xx/aic94xx_task.c b/drivers/scsi/aic94xx/aic94xx_task.c
index f923ed019d4a..3d345057ede6 100644
--- a/drivers/scsi/aic94xx/aic94xx_task.c
+++ b/drivers/scsi/aic94xx/aic94xx_task.c
@@ -316,6 +316,7 @@ static void asd_task_tasklet_complete(struct asd_ascb *ascb,
 		break;
 	case SAS_PROTOCOL_SSP:
 		asd_unbuild_ssp_ascb(ascb);
+		break;
 	default:
 		break;
 	}
@@ -610,6 +611,7 @@ int asd_execute_task(struct sas_task *task, gfp_t gfp_flags)
 				break;
 			case SAS_PROTOCOL_SSP:
 				asd_unbuild_ssp_ascb(a);
+				break;
 			default:
 				break;
 			}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 022/141] scsi: bfa: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (32 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Anil Gurumurthy, Sudarsana Kalluru, James E.J. Bottomley,
	Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple break statements and replacing
/* fall through */ comments with the new pseudo-keyword macro
fallthrough; instead of just letting the code fall through to the next
case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/bfa/bfa_fcs_lport.c | 2 +-
 drivers/scsi/bfa/bfa_ioc.c       | 6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c b/drivers/scsi/bfa/bfa_fcs_lport.c
index 3486e402bfc1..49a14157f123 100644
--- a/drivers/scsi/bfa/bfa_fcs_lport.c
+++ b/drivers/scsi/bfa/bfa_fcs_lport.c
@@ -5671,7 +5671,7 @@ bfa_fcs_lport_scn_process_rscn(struct bfa_fcs_lport_s *port,
 				bfa_fcs_lport_ms_fabric_rscn(port);
 				break;
 			}
-			/* !!!!!!!!! Fall Through !!!!!!!!!!!!! */
+			fallthrough;
 
 		case FC_RSCN_FORMAT_AREA:
 		case FC_RSCN_FORMAT_DOMAIN:
diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c
index 325ad8a592bb..5740302d83ac 100644
--- a/drivers/scsi/bfa/bfa_ioc.c
+++ b/drivers/scsi/bfa/bfa_ioc.c
@@ -387,7 +387,7 @@ bfa_ioc_sm_getattr(struct bfa_ioc_s *ioc, enum ioc_event event)
 	case IOC_E_PFFAILED:
 	case IOC_E_HWERROR:
 		bfa_ioc_timer_stop(ioc);
-		/* !!! fall through !!! */
+		fallthrough;
 	case IOC_E_TIMEOUT:
 		ioc->cbfn->enable_cbfn(ioc->bfa, BFA_STATUS_IOC_FAILURE);
 		bfa_fsm_set_state(ioc, bfa_ioc_sm_fail);
@@ -437,7 +437,7 @@ bfa_ioc_sm_op(struct bfa_ioc_s *ioc, enum ioc_event event)
 	case IOC_E_PFFAILED:
 	case IOC_E_HWERROR:
 		bfa_hb_timer_stop(ioc);
-		/* !!! fall through !!! */
+		fallthrough;
 	case IOC_E_HBFAIL:
 		if (ioc->iocpf.auto_recover)
 			bfa_fsm_set_state(ioc, bfa_ioc_sm_fail_retry);
@@ -3299,6 +3299,7 @@ bfa_ablk_isr(void *cbarg, struct bfi_mbmsg_s *msg)
 	case BFI_ABLK_I2H_PORT_CONFIG:
 		/* update config port mode */
 		ablk->ioc->port_mode_cfg = rsp->port_mode;
+		break;
 
 	case BFI_ABLK_I2H_PF_DELETE:
 	case BFI_ABLK_I2H_PF_UPDATE:
@@ -5871,6 +5872,7 @@ bfa_dconf_sm_uninit(struct bfa_dconf_mod_s *dconf, enum bfa_dconf_event event)
 		break;
 	case BFA_DCONF_SM_EXIT:
 		bfa_fsm_send_event(&dconf->bfa->iocfc, IOCFC_E_DCONF_DONE);
+		break;
 	case BFA_DCONF_SM_IOCDISABLE:
 	case BFA_DCONF_SM_WR:
 	case BFA_DCONF_SM_FLASH_COMP:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 023/141] staging: rtl8723bs: core: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:27   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/rtl8723bs/core/rtw_cmd.c       | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c  | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index 2abe205e3453..232661e6a5c9 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1487,6 +1487,7 @@ void lps_ctrl_wk_hdl(struct adapter *padapter, u8 lps_ctrl_type)
 		break;
 	case LPS_CTRL_TRAFFIC_BUSY:
 		LPS_Leave(padapter, "LPS_CTRL_TRAFFIC_BUSY");
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index b912ad2f4b72..ea44d653a591 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1708,6 +1708,7 @@ unsigned int OnAssocRsp(struct adapter *padapter, union recv_frame *precv_frame)
 
 		case _ERPINFO_IE_:
 			ERP_IE_handler(padapter, pIE);
+			break;
 
 		default:
 			break;
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 372ce17c3569..2b13c683ba5c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -1505,6 +1505,7 @@ unsigned int is_ap_in_tkip(struct adapter *padapter)
 			case _RSN_IE_2_:
 				if (!memcmp((pIE->data + 8), RSN_TKIP_CIPHER, 4))
 					return true;
+				break;
 
 			default:
 				break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 023/141] staging: rtl8723bs: core: Fix fall-through warnings for Clang
@ 2020-11-20 18:27   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/rtl8723bs/core/rtw_cmd.c       | 1 +
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c  | 1 +
 drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index 2abe205e3453..232661e6a5c9 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1487,6 +1487,7 @@ void lps_ctrl_wk_hdl(struct adapter *padapter, u8 lps_ctrl_type)
 		break;
 	case LPS_CTRL_TRAFFIC_BUSY:
 		LPS_Leave(padapter, "LPS_CTRL_TRAFFIC_BUSY");
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index b912ad2f4b72..ea44d653a591 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1708,6 +1708,7 @@ unsigned int OnAssocRsp(struct adapter *padapter, union recv_frame *precv_frame)
 
 		case _ERPINFO_IE_:
 			ERP_IE_handler(padapter, pIE);
+			break;
 
 		default:
 			break;
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 372ce17c3569..2b13c683ba5c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -1505,6 +1505,7 @@ unsigned int is_ap_in_tkip(struct adapter *padapter)
 			case _RSN_IE_2_:
 				if (!memcmp((pIE->data + 8), RSN_TKIP_CIPHER, 4))
 					return true;
+				break;
 
 			default:
 				break;
-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 024/141] staging: vt6655: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:27   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Forest Bond, Greg Kroah-Hartman
  Cc: devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/vt6655/device_main.c | 1 +
 drivers/staging/vt6655/rxtx.c        | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c
index 09ab6d6f2429..0adbd2b67df0 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1579,6 +1579,7 @@ static int vnt_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 	case DISABLE_KEY:
 		if (test_bit(key->hw_key_idx, &priv->key_entry_inuse))
 			clear_bit(key->hw_key_idx, &priv->key_entry_inuse);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 477d19314634..1a64152de189 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -1004,6 +1004,7 @@ s_cbFillTxBufHead(struct vnt_private *pDevice, unsigned char byPktType,
 		switch (info->control.hw_key->cipher) {
 		case WLAN_CIPHER_SUITE_CCMP:
 			cbMICHDR = sizeof(struct vnt_mic_hdr);
+			break;
 		default:
 			break;
 		}
@@ -1318,6 +1319,7 @@ int vnt_generate_fifo_header(struct vnt_private *priv, u32 dma_idx,
 			break;
 		case WLAN_CIPHER_SUITE_CCMP:
 			tx_buffer_head->frag_ctl |= cpu_to_le16(FRAGCTL_AES);
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 024/141] staging: vt6655: Fix fall-through warnings for Clang
@ 2020-11-20 18:27   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Forest Bond, Greg Kroah-Hartman
  Cc: devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/vt6655/device_main.c | 1 +
 drivers/staging/vt6655/rxtx.c        | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c
index 09ab6d6f2429..0adbd2b67df0 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1579,6 +1579,7 @@ static int vnt_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 	case DISABLE_KEY:
 		if (test_bit(key->hw_key_idx, &priv->key_entry_inuse))
 			clear_bit(key->hw_key_idx, &priv->key_entry_inuse);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index 477d19314634..1a64152de189 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -1004,6 +1004,7 @@ s_cbFillTxBufHead(struct vnt_private *pDevice, unsigned char byPktType,
 		switch (info->control.hw_key->cipher) {
 		case WLAN_CIPHER_SUITE_CCMP:
 			cbMICHDR = sizeof(struct vnt_mic_hdr);
+			break;
 		default:
 			break;
 		}
@@ -1318,6 +1319,7 @@ int vnt_generate_fifo_header(struct vnt_private *priv, u32 dma_idx,
 			break;
 		case WLAN_CIPHER_SUITE_CCMP:
 			tx_buffer_head->frag_ctl |= cpu_to_le16(FRAGCTL_AES);
+			break;
 		default:
 			break;
 		}
-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 025/141] bnxt_en: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (35 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Michael Chan, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 7975f59735d6..b593237915e3 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2137,6 +2137,7 @@ static int bnxt_hwrm_handler(struct bnxt *bp, struct tx_cmp *txcmp)
 	case CMPL_BASE_TYPE_HWRM_ASYNC_EVENT:
 		bnxt_async_event_process(bp,
 					 (struct hwrm_async_event_cmpl *)txcmp);
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 016/141] nfsd: Fix fall-through warnings for Clang
  2020-11-20 18:26 ` [PATCH 016/141] nfsd: " Gustavo A. R. Silva
@ 2020-11-20 18:27   ` Chuck Lever
  2020-11-23 22:46     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Chuck Lever @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Bruce Fields, Linux NFS Mailing List, linux-kernel, linux-hardening



> On Nov 20, 2020, at 1:26 PM, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding a couple of break statements instead of
> just letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> fs/nfsd/nfs4state.c | 1 +
> fs/nfsd/nfsctl.c    | 1 +
> 2 files changed, 2 insertions(+)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index d7f27ed6b794..cdab0d5be186 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -3113,6 +3113,7 @@ nfsd4_exchange_id(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> 			goto out_nolock;
> 		}
> 		new->cl_mach_cred = true;
> +		break;
> 	case SP4_NONE:
> 		break;
> 	default:				/* checked by xdr code */
> diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> index f6d5d783f4a4..9a3bb1e217f9 100644
> --- a/fs/nfsd/nfsctl.c
> +++ b/fs/nfsd/nfsctl.c
> @@ -1165,6 +1165,7 @@ static struct inode *nfsd_get_inode(struct super_block *sb, umode_t mode)
> 		inode->i_fop = &simple_dir_operations;
> 		inode->i_op = &simple_dir_inode_operations;
> 		inc_nlink(inode);
> +		break;
> 	default:
> 		break;
> 	}
> -- 
> 2.27.0
> 

Acked-by: Chuck Lever <chuck.lever@oracle.com>

--
Chuck Lever




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 026/141] ceph: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (36 preceding siblings ...)
  (?)
@ 2020-11-20 18:27 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:27 UTC (permalink / raw)
  To: Jeff Layton, Ilya Dryomov
  Cc: ceph-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break and a goto statements instead
of just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/ceph/dir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
index a4d48370b2b3..e9b44f613932 100644
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@ -631,10 +631,12 @@ static loff_t ceph_dir_llseek(struct file *file, loff_t offset, int whence)
 	switch (whence) {
 	case SEEK_CUR:
 		offset += file->f_pos;
+		break;
 	case SEEK_SET:
 		break;
 	case SEEK_END:
 		retval = -EOPNOTSUPP;
+		goto out;
 	default:
 		goto out;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 027/141] drbd: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (37 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Philipp Reisner, Lars Ellenberg, Jens Axboe
  Cc: drbd-dev, linux-block, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement instead of just
letting the code fall through to the next, and by adding a fallthrough
pseudo-keyword in places whre the code is intended to fall through.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/block/drbd/drbd_receiver.c | 1 +
 drivers/block/drbd/drbd_req.c      | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c
index dc333dbe5232..c19bb74ac935 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -5863,6 +5863,7 @@ static int got_NegRSDReply(struct drbd_connection *connection, struct packet_inf
 		switch (pi->cmd) {
 		case P_NEG_RS_DREPLY:
 			drbd_rs_failed_io(device, sector, size);
+			break;
 		case P_RS_CANCEL:
 			break;
 		default:
diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 330f851cb8f0..9f212a923a3c 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -750,6 +750,7 @@ int __req_mod(struct drbd_request *req, enum drbd_req_event what,
 
 	case WRITE_ACKED_BY_PEER_AND_SIS:
 		req->rq_state |= RQ_NET_SIS;
+		fallthrough;
 	case WRITE_ACKED_BY_PEER:
 		/* Normal operation protocol C: successfully written on peer.
 		 * During resync, even in protocol != C,
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Harry Wentland, Leo Li, Alex Deucher, Christian König,
	David Airlie, Daniel Vetter
  Cc: amd-gfx, dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index ad394aefa5d9..23a373ca94b5 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 29d64e7e304f..fd1e64fa8744 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
 			break;
 		case 4:
 			result = get_soc_bb_info_v4_4(bp, soc_bb_info);
+			break;
 		default:
 			break;
 		}
@@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index fec87a2e210c..b9254a87ee73 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
 
 				return false;
 			}
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Harry Wentland, Leo Li, Alex Deucher, Christian König,
	David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index ad394aefa5d9..23a373ca94b5 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 29d64e7e304f..fd1e64fa8744 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
 			break;
 		case 4:
 			result = get_soc_bb_info_v4_4(bp, soc_bb_info);
+			break;
 		default:
 			break;
 		}
@@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index fec87a2e210c..b9254a87ee73 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
 
 				return false;
 			}
+			break;
 		default:
 			break;
 		}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Harry Wentland, Leo Li, Alex Deucher, Christian König,
	David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
 drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
 drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
index ad394aefa5d9..23a373ca94b5 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
@@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
index 29d64e7e304f..fd1e64fa8744 100644
--- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
+++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
@@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
 			break;
 		case 4:
 			result = get_soc_bb_info_v4_4(bp, soc_bb_info);
+			break;
 		default:
 			break;
 		}
@@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index fec87a2e210c..b9254a87ee73 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
 
 				return false;
 			}
+			break;
 		default:
 			break;
 		}
-- 
2.27.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 029/141] e1000: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/e1000/e1000_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c b/drivers/net/ethernet/intel/e1000/e1000_hw.c
index 4c0c9433bd60..19cf36360933 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c
@@ -1183,6 +1183,7 @@ static s32 e1000_copper_link_igp_setup(struct e1000_hw *hw)
 			break;
 		case e1000_ms_auto:
 			phy_data &= ~CR_1000T_MS_ENABLE;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 029/141] e1000: Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/e1000/e1000_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/e1000/e1000_hw.c b/drivers/net/ethernet/intel/e1000/e1000_hw.c
index 4c0c9433bd60..19cf36360933 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_hw.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_hw.c
@@ -1183,6 +1183,7 @@ static s32 e1000_copper_link_igp_setup(struct e1000_hw *hw)
 			break;
 		case e1000_ms_auto:
 			phy_data &= ~CR_1000T_MS_ENABLE;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 030/141] ext2: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (40 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  2020-11-23  9:37   ` Jan Kara
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Jan Kara; +Cc: linux-ext4, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/ext2/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 11c5c6fe75bb..78c417d3c898 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -1256,6 +1256,7 @@ static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
 				mark_inode_dirty(inode);
 				ext2_free_branches(inode, &nr, &nr+1, 3);
 			}
+			break;
 		case EXT2_TIND_BLOCK:
 			;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 031/141] ext4: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (41 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Theodore Ts'o, Andreas Dilger
  Cc: linux-ext4, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 6633b20224d5..ca04389fc718 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4877,6 +4877,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
 			       "requested data journaling mode");
 			goto failed_mount_wq;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 032/141] floppy: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (42 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Denis Efremov, Jens Axboe
  Cc: linux-block, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword in places where the
code is intended to fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/block/floppy.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 7df79ae6b0a1..21a2a7becba0 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -2124,6 +2124,7 @@ static void format_interrupt(void)
 	switch (interpret_errors()) {
 	case 1:
 		cont->error();
+		fallthrough;
 	case 2:
 		break;
 	case 0:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 033/141] fm10k: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
index 8e2e92bf3cd4..3e970e20695d 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
@@ -1039,6 +1039,7 @@ static s32 fm10k_mbx_create_reply(struct fm10k_hw *hw,
 	case FM10K_STATE_CLOSED:
 		/* generate new header based on data */
 		fm10k_mbx_create_disconnect_hdr(mbx);
+		break;
 	default:
 		break;
 	}
@@ -2017,6 +2018,7 @@ static s32 fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
 	case FM10K_STATE_CONNECT:
 		/* Update remote value to match local value */
 		mbx->remote = mbx->local;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 033/141] fm10k: Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
index 8e2e92bf3cd4..3e970e20695d 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
@@ -1039,6 +1039,7 @@ static s32 fm10k_mbx_create_reply(struct fm10k_hw *hw,
 	case FM10K_STATE_CLOSED:
 		/* generate new header based on data */
 		fm10k_mbx_create_disconnect_hdr(mbx);
+		break;
 	default:
 		break;
 	}
@@ -2017,6 +2018,7 @@ static s32 fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
 	case FM10K_STATE_CONNECT:
 		/* Update remote value to match local value */
 		mbx->remote = mbx->local;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                     ` (12 preceding siblings ...)
  (?)
@ 2020-11-20 18:28   ` Joe Perches
  -1 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, linux-arm-kernel,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, linux-crypto, linux-decnet-user, linux-ext4,
	linux-fbdev, linux-geode, linux-gpio, linux-hams, linux-hwmon,
	linux-i3c, linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, linux-media, linux-mmc, linux-mm, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Kees Cook

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, linux-arm-kernel,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, linux-crypto, linux-decnet-user, linux-ext4,
	linux-fbdev, linux-geode, linux-gpio, linux-hams, linux-hwmon,
	linux-i3c, linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, linux-media, linux-mmc, linux-mm, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Kees Cook

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:28   ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening

On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
> Hi all,
> 
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.

This was a bit hard to parse for a second or three.

Thanks Gustavo.

How was this change done?



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [PATCH 034/141] IB/mlx4: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (45 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Yishai Hadas, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/infiniband/hw/mlx4/mad.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 8bd16474708f..f3ace85552f3 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw/mlx4/mad.c
@@ -1523,6 +1523,7 @@ static void mlx4_ib_multiplex_mad(struct mlx4_ib_demux_pv_ctx *ctx, struct ib_wc
 			return;
 		} else
 			*slave_id = slave;
+		break;
 	default:
 		/* nothing */;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 035/141] IB/qedr: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (46 preceding siblings ...)
  (?)
@ 2020-11-20 18:28 ` Gustavo A. R. Silva
  2020-11-22 20:12   ` [EXT] " Michal Kalderon
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:28 UTC (permalink / raw)
  To: Michal Kalderon, Ariel Elior, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/infiniband/hw/qedr/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c
index 967641662b24..10707b451ab8 100644
--- a/drivers/infiniband/hw/qedr/main.c
+++ b/drivers/infiniband/hw/qedr/main.c
@@ -796,6 +796,7 @@ static void qedr_affiliated_event(void *context, u8 e_code, void *fw_handle)
 		}
 		xa_unlock_irqrestore(&dev->srqs, flags);
 		DP_NOTICE(dev, "SRQ event %d on handle %p\n", e_code, srq);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 036/141] ice: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:29   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:29 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
index bc2f4390b51d..c7b47ad36416 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
@@ -143,6 +143,7 @@ ice_rx_csum(struct ice_ring *ring, struct sk_buff *skb,
 	case ICE_RX_PTYPE_INNER_PROT_UDP:
 	case ICE_RX_PTYPE_INNER_PROT_SCTP:
 		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 036/141] ice: Fix fall-through warnings for Clang
@ 2020-11-20 18:29   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:29 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
index bc2f4390b51d..c7b47ad36416 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
@@ -143,6 +143,7 @@ ice_rx_csum(struct ice_ring *ring, struct sk_buff *skb,
 	case ICE_RX_PTYPE_INNER_PROT_UDP:
 	case ICE_RX_PTYPE_INNER_PROT_SCTP:
 		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 037/141] Input: pcspkr - Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (48 preceding siblings ...)
  (?)
@ 2020-11-20 18:30 ` Gustavo A. R. Silva
  2020-11-23  6:15   ` Dmitry Torokhov
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: linux-input, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/input/misc/pcspkr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/misc/pcspkr.c b/drivers/input/misc/pcspkr.c
index e5e0d8ba80e1..9c666b2f14fe 100644
--- a/drivers/input/misc/pcspkr.c
+++ b/drivers/input/misc/pcspkr.c
@@ -33,6 +33,7 @@ static int pcspkr_event(struct input_dev *dev, unsigned int type,
 	case SND_BELL:
 		if (value)
 			value = 1000;
+		break;
 	case SND_TONE:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 038/141] isofs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (49 preceding siblings ...)
  (?)
@ 2020-11-20 18:30 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/isofs/rock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 94ef92fe806c..4880146babaf 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -767,6 +767,7 @@ static int rock_ridge_symlink_readpage(struct file *file, struct page *page)
 			rs.cont_extent = isonum_733(rr->u.CE.extent);
 			rs.cont_offset = isonum_733(rr->u.CE.offset);
 			rs.cont_size = isonum_733(rr->u.CE.size);
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 039/141] ixgbevf: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:30   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: Jesse Brandeburg, Tony Nguyen, David S. Miller, Jakub Kicinski
  Cc: intel-wired-lan, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 82fce27f682b..afab78c51be0 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2639,6 +2639,7 @@ static void ixgbevf_set_num_queues(struct ixgbevf_adapter *adapter)
 			adapter->num_rx_queues = rss;
 			adapter->num_tx_queues = rss;
 			adapter->num_xdp_queues = adapter->xdp_prog ? rss : 0;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 039/141] ixgbevf: Fix fall-through warnings for Clang
@ 2020-11-20 18:30   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: intel-wired-lan

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 82fce27f682b..afab78c51be0 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2639,6 +2639,7 @@ static void ixgbevf_set_num_queues(struct ixgbevf_adapter *adapter)
 			adapter->num_rx_queues = rss;
 			adapter->num_tx_queues = rss;
 			adapter->num_xdp_queues = adapter->xdp_prog ? rss : 0;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 040/141] kprobes/x86: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (51 preceding siblings ...)
  (?)
@ 2020-11-20 18:30 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
  Cc: x86, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 arch/x86/kernel/kprobes/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 547c7abb39f5..983738bc08c0 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -864,6 +864,7 @@ static void resume_execution(struct kprobe *p, struct pt_regs *regs,
 			p->ainsn.boostable = true;
 			goto no_change;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 041/141] mm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (52 preceding siblings ...)
  (?)
@ 2020-11-20 18:30 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-mm, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement instead of just letting
the code fall through to the next, and by adding a fallthrough
pseudo-keyword in places where the code is intended to fall through.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 mm/mm_init.c | 1 +
 mm/vmscan.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mm/mm_init.c b/mm/mm_init.c
index b06a30fbedff..8e02e865cc65 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -173,6 +173,7 @@ static int __meminit mm_compute_batch_notifier(struct notifier_block *self,
 	case MEM_ONLINE:
 	case MEM_OFFLINE:
 		mm_compute_batch(sysctl_overcommit_memory);
+		break;
 	default:
 		break;
 	}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7b4e31eac2cf..a55c96891549 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1372,6 +1372,7 @@ static unsigned int shrink_page_list(struct list_head *page_list,
 				if (PageDirty(page) || PageWriteback(page))
 					goto keep_locked;
 				mapping = page_mapping(page);
+				fallthrough;
 			case PAGE_CLEAN:
 				; /* try to free the page below */
 			}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 042/141] net: 3c509: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (53 preceding siblings ...)
  (?)
@ 2020-11-20 18:30 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:30 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/3com/3c509.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/3com/3c509.c b/drivers/net/ethernet/3com/3c509.c
index 667f38c9e4c6..676cdc6900b5 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -1052,6 +1052,7 @@ el3_netdev_get_ecmd(struct net_device *dev, struct ethtool_link_ksettings *cmd)
 		break;
 	case 3:
 		cmd->base.port = PORT_BNC;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 043/141] net: cassini: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (54 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/sun/cassini.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index 9ff894ba8d3e..54f45d8c79a7 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -1599,6 +1599,7 @@ static inline int cas_mdio_link_not_up(struct cas *cp)
 			cas_phy_write(cp, MII_BMCR, val);
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 044/141] net/mlx4: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (55 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  2020-11-22  8:36   ` Tariq Toukan
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Tariq Toukan, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-rdma, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 1187ef1375e2..e6b8b8dc7894 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -2660,6 +2660,7 @@ int mlx4_FREE_RES_wrapper(struct mlx4_dev *dev, int slave,
 	case RES_XRCD:
 		err = xrcdn_free_res(dev, slave, vhcr->op_modifier, alop,
 				     vhcr->in_param, &vhcr->out_param);
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 045/141] net: mscc: ocelot: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (56 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Microchip Linux Driver Support, Vladimir Oltean, Claudiu Manoil,
	Alexandre Belloni, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/mscc/ocelot_vcap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mscc/ocelot_vcap.c b/drivers/net/ethernet/mscc/ocelot_vcap.c
index d8c778ee6f1b..8f3ed81b9a08 100644
--- a/drivers/net/ethernet/mscc/ocelot_vcap.c
+++ b/drivers/net/ethernet/mscc/ocelot_vcap.c
@@ -761,6 +761,7 @@ static void is1_entry_set(struct ocelot *ocelot, int ix,
 			vcap_key_bytes_set(vcap, &data, VCAP_IS1_HK_ETYPE,
 					   etype.value, etype.mask);
 		}
+		break;
 	}
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 046/141] netxen_nic: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (57 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Manish Chopra, Rahul Verma, David S. Miller, Jakub Kicinski
  Cc: GR-Linux-NIC-Dev, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a goto statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 94546ed5f867..2cd089cca622 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1686,6 +1686,7 @@ netxen_process_rcv_ring(struct nx_host_sds_ring *sds_ring, int max)
 			break;
 		case NETXEN_NIC_RESPONSE_DESC:
 			netxen_handle_fw_message(desc_cnt, consumer, sds_ring);
+			goto skip;
 		default:
 			goto skip;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 047/141] nfp: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (58 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Simon Horman, Jakub Kicinski, David S. Miller
  Cc: oss-drivers, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
index b3cabc274121..3b8e675087de 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
@@ -103,6 +103,7 @@ nfp_repr_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 *stats)
 	case NFP_PORT_PF_PORT:
 	case NFP_PORT_VF_PORT:
 		nfp_repr_vnic_get_stats64(repr->port, stats);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 048/141] perf/x86: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (59 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
	Mark Rutland, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
	Thomas Gleixner, Borislav Petkov, H. Peter Anvin
  Cc: x86, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword as a replacement for
a /* fall through */ comment, instead of letting the code fall through
to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 arch/x86/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index a88c94d65693..550c5e7002b9 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1174,7 +1174,7 @@ static inline void x86_assign_hw_event(struct perf_event *event,
 	case INTEL_PMC_IDX_METRIC_BASE ... INTEL_PMC_IDX_METRIC_END:
 		/* All the metric events are mapped onto the fixed counter 3. */
 		idx = INTEL_PMC_IDX_FIXED_SLOTS;
-		/* fall through */
+		fallthrough;
 	case INTEL_PMC_IDX_FIXED ... INTEL_PMC_IDX_FIXED_BTS-1:
 		hwc->config_base = MSR_ARCH_PERFMON_FIXED_CTR_CTRL;
 		hwc->event_base = MSR_ARCH_PERFMON_FIXED_CTR0 +
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 049/141] pinctrl: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (60 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  2020-11-20 19:04   ` Geert Uytterhoeven
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Geert Uytterhoeven, Linus Walleij
  Cc: linux-renesas-soc, linux-gpio, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/pinctrl/renesas/pinctrl-rza1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/renesas/pinctrl-rza1.c b/drivers/pinctrl/renesas/pinctrl-rza1.c
index 15dd007700c2..10020fe302b8 100644
--- a/drivers/pinctrl/renesas/pinctrl-rza1.c
+++ b/drivers/pinctrl/renesas/pinctrl-rza1.c
@@ -931,6 +931,7 @@ static int rza1_parse_pinmux_node(struct rza1_pinctrl *rza1_pctl,
 		case PIN_CONFIG_OUTPUT:	/* for DT backwards compatibility */
 		case PIN_CONFIG_OUTPUT_ENABLE:
 			pinmux_flags |= MUX_FLAGS_SWIO_OUTPUT;
+			break;
 		default:
 			break;
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 050/141] RDMA/mlx5: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (61 preceding siblings ...)
  (?)
@ 2020-11-20 18:31 ` Gustavo A. R. Silva
  2020-11-23  8:33   ` Leon Romanovsky
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:31 UTC (permalink / raw)
  To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding the new pseudo-keyword fallthrough; instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/infiniband/hw/mlx5/qp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 600e056798c0..ccaa4589331c 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -2460,6 +2460,7 @@ static int check_qp_type(struct mlx5_ib_dev *dev, struct ib_qp_init_attr *attr,
 	case IB_QPT_GSI:
 		if (dev->profile == &raw_eth_profile)
 			goto out;
+		fallthrough;
 	case IB_QPT_RAW_PACKET:
 	case IB_QPT_UD:
 	case MLX5_IB_QPT_REG_UMR:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 051/141] reiserfs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (62 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: reiserfs-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 fs/reiserfs/namei.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
index 1594687582f0..90bb49bfdba0 100644
--- a/fs/reiserfs/namei.c
+++ b/fs/reiserfs/namei.c
@@ -132,6 +132,7 @@ int search_by_entry_key(struct super_block *sb, const struct cpu_key *key,
 			return IO_ERROR;
 		}
 		PATH_LAST_POSITION(path)--;
+		break;
 
 	case ITEM_FOUND:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 052/141] security: keys: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (63 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  2020-11-23 22:54   ` Jarkko Sakkinen
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn
  Cc: keyrings, linux-security-module, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 security/keys/process_keys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 1fe8b934f656..e3d79a7b6db6 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -783,6 +783,7 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
 				if (need_perm != KEY_AUTHTOKEN_OVERRIDE &&
 				    need_perm != KEY_DEFER_PERM_CHECK)
 					goto invalid_key;
+				break;
 			case 0:
 				break;
 			}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 053/141] selinux: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (64 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  2020-11-23 23:31   ` Paul Moore
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Paul Moore, Stephen Smalley, Eric Paris
  Cc: selinux, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 security/selinux/hooks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6b1826fc3658..e57774367b3a 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4029,6 +4029,7 @@ static int selinux_kernel_load_data(enum kernel_load_data_id id, bool contents)
 	switch (id) {
 	case LOADING_MODULE:
 		rc = selinux_kernel_module_from_file(NULL);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 054/141] target: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (65 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: linux-scsi, target-devel, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement and a fallthrough
pseudo-keyword instead of letting the code fall through to the next
case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/target/target_core_iblock.c | 1 +
 drivers/target/target_core_pr.c     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index f2bd2e207e0b..8ed93fd205c7 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -211,6 +211,7 @@ static unsigned long long iblock_emulate_read_cap_with_block_size(
 			break;
 		case 512:
 			blocks_long <<= 3;
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index 5f79ea05f9b8..14db5e568f22 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -337,6 +337,7 @@ static int core_scsi3_pr_seq_non_holder(struct se_cmd *cmd, u32 pr_reg_type,
 	switch (pr_reg_type) {
 	case PR_TYPE_WRITE_EXCLUSIVE:
 		we = 1;
+		fallthrough;
 	case PR_TYPE_EXCLUSIVE_ACCESS:
 		/*
 		 * Some commands are only allowed for the persistent reservation
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 055/141] uprobes/x86: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (66 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
  Cc: x86, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 arch/x86/kernel/uprobes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 3fdaa042823d..90f44f44c209 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -1015,6 +1015,8 @@ int arch_uprobe_exception_notify(struct notifier_block *self, unsigned long val,
 		if (uprobe_post_sstep_notifier(regs))
 			ret = NOTIFY_STOP;
 
+		break;
+
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 056/141] vxge: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (67 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Jon Mason, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.c b/drivers/net/ethernet/neterion/vxge/vxge-config.c
index f5d48d7c4ce2..34c10ee086eb 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.c
@@ -3784,6 +3784,7 @@ vxge_hw_rts_rth_data0_data1_get(u32 j, u64 *data0, u64 *data1,
 			VXGE_HW_RTS_ACCESS_STEER_DATA1_RTH_ITEM1_ENTRY_EN |
 			VXGE_HW_RTS_ACCESS_STEER_DATA1_RTH_ITEM1_BUCKET_DATA(
 			itable[j]);
+		return;
 	default:
 		return;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 057/141] watchdog: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (68 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  2020-11-21 18:49   ` Guenter Roeck
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Wim Van Sebroeck, Guenter Roeck
  Cc: linux-watchdog, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/watchdog/machzwd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/machzwd.c b/drivers/watchdog/machzwd.c
index 743377c5b173..73f2221f6222 100644
--- a/drivers/watchdog/machzwd.c
+++ b/drivers/watchdog/machzwd.c
@@ -174,6 +174,7 @@ static inline void zf_set_timer(unsigned short new, unsigned char n)
 		fallthrough;
 	case WD2:
 		zf_writeb(COUNTER_2, new > 0xff ? 0xff : new);
+		fallthrough;
 	default:
 		return;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 058/141] xen-blkfront: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (69 preceding siblings ...)
  (?)
@ 2020-11-20 18:32 ` Gustavo A. R. Silva
  2020-11-20 21:36   ` boris.ostrovsky
  2020-11-23 10:28   ` Roger Pau Monné
  -1 siblings, 2 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:32 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk, Roger Pau Monné,
	Boris Ostrovsky, Juergen Gross, Stefano Stabellini, Jens Axboe
  Cc: xen-devel, linux-block, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/block/xen-blkfront.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 48629d3433b4..34b028be78ab 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2462,6 +2462,7 @@ static void blkback_changed(struct xenbus_device *dev,
 			break;
 		if (talk_to_blkback(dev, info))
 			break;
+		break;
 	case XenbusStateInitialising:
 	case XenbusStateInitialised:
 	case XenbusStateReconfiguring:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 059/141] regulator: as3722: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (70 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Liam Girdwood, Mark Brown
  Cc: linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/regulator/as3722-regulator.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/as3722-regulator.c b/drivers/regulator/as3722-regulator.c
index 33ca197860b3..7bebf9ce6271 100644
--- a/drivers/regulator/as3722-regulator.c
+++ b/drivers/regulator/as3722-regulator.c
@@ -455,7 +455,8 @@ static int as3722_sd_set_mode(struct regulator_dev *rdev,
 	switch (mode) {
 	case REGULATOR_MODE_FAST:
 		val = as3722_reg_lookup[id].mode_mask;
-	case REGULATOR_MODE_NORMAL: /* fall down */
+		fallthrough;
+	case REGULATOR_MODE_NORMAL:
 		break;
 	default:
 		return -EINVAL;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 060/141] habanalabs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (71 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  2020-11-21 12:34   ` Oded Gabbay
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Oded Gabbay, Arnd Bergmann, Greg Kroah-Hartman
  Cc: linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/misc/habanalabs/gaudi/gaudi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c b/drivers/misc/habanalabs/gaudi/gaudi.c
index 2519a34e25b7..eab4c0dc65c5 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -5436,6 +5436,7 @@ static void gaudi_handle_ecc_event(struct hl_device *hdev, u16 event_type,
 		params.num_memories = 33;
 		params.derr = true;
 		params.disable_clock_gating = true;
+		fallthrough;
 	default:
 		return;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 061/141] tee: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (72 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  2020-11-22  9:26   ` Jens Wiklander
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Jens Wiklander; +Cc: op-tee, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/tee/tee_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 6ade4a5c4840..5fdf26688230 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -452,6 +452,7 @@ static int params_to_user(struct tee_ioctl_param __user *uparams,
 		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
 			if (put_user((u64)p->u.memref.size, &up->b))
 				return -EFAULT;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 062/141] HID: usbhid: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (73 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  2020-11-25 13:02   ` Jiri Kosina
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Jiri Kosina, Benjamin Tissoires
  Cc: linux-usb, linux-input, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of break statements instead
of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/hid/usbhid/hid-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 17a29ee0ac6c..86257ce6d619 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -438,6 +438,7 @@ static void hid_irq_out(struct urb *urb)
 		break;
 	case -ESHUTDOWN:	/* unplug */
 		unplug = 1;
+		break;
 	case -EILSEQ:		/* protocol error or unplug */
 	case -EPROTO:		/* protocol error or unplug */
 	case -ECONNRESET:	/* unlink */
@@ -489,6 +490,7 @@ static void hid_ctrl(struct urb *urb)
 		break;
 	case -ESHUTDOWN:	/* unplug */
 		unplug = 1;
+		break;
 	case -EILSEQ:		/* protocol error or unplug */
 	case -EPROTO:		/* protocol error or unplug */
 	case -ECONNRESET:	/* unlink */
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 063/141] HID: input: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (74 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  2020-11-25 13:04   ` Jiri Kosina
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Jiri Kosina, Benjamin Tissoires
  Cc: linux-input, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a goto statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/hid/hid-input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 9770db624bfa..37601b800a2e 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -743,6 +743,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 				field->flags |= HID_MAIN_ITEM_RELATIVE;
 				break;
 			}
+			goto unknown;
 
 		default: goto unknown;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 064/141] ACPI: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (75 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  2020-11-23 11:43   ` Rafael J. Wysocki
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Rafael J. Wysocki, Len Brown
  Cc: linux-acpi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/acpi/sbshc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
index 53c2862c4c75..0b3de0e63633 100644
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -231,6 +231,7 @@ static int smbus_alarm(void *context)
 		case ACPI_SBS_BATTERY:
 			acpi_os_execute(OSL_NOTIFY_HANDLER,
 					acpi_smbus_callback, hc);
+			break;
 		default:;
 	}
 	mutex_unlock(&hc->lock);
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 065/141] airo: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (76 preceding siblings ...)
  (?)
@ 2020-11-20 18:33 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/cisco/airo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 87b9398b03fd..41a41e18b956 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -7067,6 +7067,7 @@ static int airo_set_power(struct net_device *dev,
 			local->config.rmode &= ~RXMODE_MASK;
 			local->config.rmode |= RXMODE_BC_MC_ADDR;
 			set_bit (FLAG_COMMIT, &local->flags);
+			break;
 		case IW_POWER_ON:
 			/* This is broken, fixme ;-) */
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:33   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/pci/rme9652/hdspm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c
index 4a1f576dd9cf..f25a448dd636 100644
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -6321,6 +6321,7 @@ static int snd_hdspm_hwdep_ioctl(struct snd_hwdep *hw, struct file *file,
 				(statusregister & HDSPM_RX_64ch) ? 1 : 0;
 			/* TODO: Mac driver sets it when f_s>48kHz */
 			status.card_specific.madi.frame_format = 0;
+			break;
 
 		default:
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
@ 2020-11-20 18:33   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:33 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/pci/rme9652/hdspm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c
index 4a1f576dd9cf..f25a448dd636 100644
--- a/sound/pci/rme9652/hdspm.c
+++ b/sound/pci/rme9652/hdspm.c
@@ -6321,6 +6321,7 @@ static int snd_hdspm_hwdep_ioctl(struct snd_hwdep *hw, struct file *file,
 				(statusregister & HDSPM_RX_64ch) ? 1 : 0;
 			/* TODO: Mac driver sets it when f_s>48kHz */
 			status.card_specific.madi.frame_format = 0;
+			break;
 
 		default:
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 067/141] ALSA: pcsp: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:34   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/drivers/pcsp/pcsp_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/drivers/pcsp/pcsp_input.c b/sound/drivers/pcsp/pcsp_input.c
index 52b475b310c3..e79603fe743d 100644
--- a/sound/drivers/pcsp/pcsp_input.c
+++ b/sound/drivers/pcsp/pcsp_input.c
@@ -54,6 +54,7 @@ static int pcspkr_input_event(struct input_dev *dev, unsigned int type,
 		case SND_BELL:
 			if (value)
 				value = 1000;
+			break;
 		case SND_TONE:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 067/141] ALSA: pcsp: Fix fall-through warnings for Clang
@ 2020-11-20 18:34   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/drivers/pcsp/pcsp_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/drivers/pcsp/pcsp_input.c b/sound/drivers/pcsp/pcsp_input.c
index 52b475b310c3..e79603fe743d 100644
--- a/sound/drivers/pcsp/pcsp_input.c
+++ b/sound/drivers/pcsp/pcsp_input.c
@@ -54,6 +54,7 @@ static int pcspkr_input_event(struct input_dev *dev, unsigned int type,
 		case SND_BELL:
 			if (value)
 				value = 1000;
+			break;
 		case SND_TONE:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 068/141] ALSA: sb: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:34   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/isa/sb/sb8_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/isa/sb/sb8_main.c b/sound/isa/sb/sb8_main.c
index 86d0d2fdf48a..8d01692c4f2a 100644
--- a/sound/isa/sb/sb8_main.c
+++ b/sound/isa/sb/sb8_main.c
@@ -506,6 +506,7 @@ static int snd_sb8_open(struct snd_pcm_substream *substream)
 		} else {
 			runtime->hw.rate_max = 15000;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 068/141] ALSA: sb: Fix fall-through warnings for Clang
@ 2020-11-20 18:34   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Jaroslav Kysela, Takashi Iwai
  Cc: alsa-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 sound/isa/sb/sb8_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/isa/sb/sb8_main.c b/sound/isa/sb/sb8_main.c
index 86d0d2fdf48a..8d01692c4f2a 100644
--- a/sound/isa/sb/sb8_main.c
+++ b/sound/isa/sb/sb8_main.c
@@ -506,6 +506,7 @@ static int snd_sb8_open(struct snd_pcm_substream *substream)
 		} else {
 			runtime->hw.rate_max = 15000;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 069/141] ath5k: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (80 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Jiri Slaby, Nick Kossifidis, Luis Chamberlain, Kalle Valo,
	David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/ath/ath5k/mac80211-ops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index 5e866a193ed0..8f2719ff463c 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -433,6 +433,7 @@ ath5k_configure_filter(struct ieee80211_hw *hw, unsigned int changed_flags,
 	case NL80211_IFTYPE_STATION:
 		if (ah->assoc)
 			rfilt |= AR5K_RX_FILTER_BEACON;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 070/141] atm: fore200e: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (81 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Chas Williams
  Cc: linux-atm-general, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/atm/fore200e.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 9a70bee84125..ba3ed1b77bc5 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -423,6 +423,7 @@ fore200e_shutdown(struct fore200e* fore200e)
 	/* XXX shouldn't we *start* by deregistering the device? */
 	atm_dev_deregister(fore200e->atm_dev);
 
+	fallthrough;
     case FORE200E_STATE_BLANK:
 	/* nothing to do for that state */
 	break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 071/141] braille_console: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (82 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/accessibility/braille/braille_console.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
index 9861302cc7db..359bead4b280 100644
--- a/drivers/accessibility/braille/braille_console.c
+++ b/drivers/accessibility/braille/braille_console.c
@@ -246,6 +246,7 @@ static int keyboard_notifier_call(struct notifier_block *blk,
 				beep(440);
 		}
 	}
+		break;
 	case KBD_UNBOUND_KEYCODE:
 	case KBD_UNICODE:
 	case KBD_KEYSYM:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 072/141] can: peak_usb: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (83 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  2020-11-21 13:17   ` Marc Kleine-Budde
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller, Jakub Kicinski
  Cc: linux-can, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index c2764799f9ef..fd65a155be3b 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -299,6 +299,8 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
 		if (net_ratelimit())
 			netdev_err(netdev, "Tx urb aborted (%d)\n",
 				   urb->status);
+		break;
+
 	case -EPROTO:
 	case -ENOENT:
 	case -ECONNRESET:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 073/141] carl9170: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (84 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Christian Lamparter, Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/ath/carl9170/tx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c
index 235cf77cd60c..6b8446ff48c8 100644
--- a/drivers/net/wireless/ath/carl9170/tx.c
+++ b/drivers/net/wireless/ath/carl9170/tx.c
@@ -840,6 +840,7 @@ static bool carl9170_tx_rts_check(struct ar9170 *ar,
 	case CARL9170_ERP_RTS:
 		if (likely(!multi))
 			return true;
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 074/141] cfg80211: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (85 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Johannes Berg, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/wireless/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index f01746894a4e..623a4dfb9877 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -335,6 +335,7 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
 	case WLAN_CIPHER_SUITE_WEP104:
 		if (key_idx > 3)
 			return -EINVAL;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 075/141] crypto: ccree - Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (86 preceding siblings ...)
  (?)
@ 2020-11-20 18:34 ` Gustavo A. R. Silva
  2020-11-22  7:54   ` Gilad Ben-Yossef
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:34 UTC (permalink / raw)
  To: Gilad Ben-Yossef, Herbert Xu, David S. Miller
  Cc: linux-crypto, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/crypto/ccree/cc_cipher.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index dafa6577a845..cdfee501fbd9 100644
--- a/drivers/crypto/ccree/cc_cipher.c
+++ b/drivers/crypto/ccree/cc_cipher.c
@@ -97,6 +97,7 @@ static int validate_keys_sizes(struct cc_cipher_ctx *ctx_p, u32 size)
 	case S_DIN_to_SM4:
 		if (size == SM4_KEY_SIZE)
 			return 0;
+		break;
 	default:
 		break;
 	}
@@ -139,9 +140,11 @@ static int validate_data_size(struct cc_cipher_ctx *ctx_p,
 		case DRV_CIPHER_CBC:
 			if (IS_ALIGNED(size, SM4_BLOCK_SIZE))
 				return 0;
+			break;
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 076/141] decnet: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (87 preceding siblings ...)
  (?)
@ 2020-11-20 18:35 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: linux-decnet-user, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/decnet/dn_route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 4cac31d22a50..2f3e5c49a221 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1407,7 +1407,7 @@ static int dn_route_input_slow(struct sk_buff *skb)
 			flags |= RTCF_DOREDIRECT;
 
 		local_src = DN_FIB_RES_PREFSRC(res);
-
+		break;
 	case RTN_BLACKHOLE:
 	case RTN_UNREACHABLE:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 077/141] dm raid: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Alasdair Kergon, Mike Snitzer
  Cc: dm-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/md/dm-raid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 9c1f7c4de65b..e98af0b9d00c 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -1854,6 +1854,7 @@ static int rs_check_takeover(struct raid_set *rs)
 		    ((mddev->layout == ALGORITHM_PARITY_N && mddev->new_layout == ALGORITHM_PARITY_N) ||
 		     __within_range(mddev->new_layout, ALGORITHM_LEFT_ASYMMETRIC, ALGORITHM_RIGHT_SYMMETRIC)))
 			return 0;
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [dm-devel] [PATCH 077/141] dm raid: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Alasdair Kergon, Mike Snitzer
  Cc: dm-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/md/dm-raid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 9c1f7c4de65b..e98af0b9d00c 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -1854,6 +1854,7 @@ static int rs_check_takeover(struct raid_set *rs)
 		    ((mddev->layout == ALGORITHM_PARITY_N && mddev->new_layout == ALGORITHM_PARITY_N) ||
 		     __within_range(mddev->new_layout, ALGORITHM_LEFT_ASYMMETRIC, ALGORITHM_RIGHT_SYMMETRIC)))
 			return 0;
+		break;
 
 	default:
 		break;
-- 
2.27.0

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Evan Quan, Alex Deucher, Christian König, David Airlie,
	Daniel Vetter
  Cc: amd-gfx, dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement instead of letting
the code fall through to the next case, and a fallthrough pseudo-keyword
as a replacement for a /* fall through */ comment,

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
 drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
index b5986d19dc08..afa1711c9620 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
@@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
 		case AMDGPU_PCIE_GEN2:
 			if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
 			break;
diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
index c3d2e6dcf62a..7d7d698c7976 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
@@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
 		break;
 	case SMU_BIF_TABLE:
 		polaris10_update_bif_smc_table(hwmgr);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Evan Quan, Alex Deucher, Christian König, David Airlie,
	Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement instead of letting
the code fall through to the next case, and a fallthrough pseudo-keyword
as a replacement for a /* fall through */ comment,

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
 drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
index b5986d19dc08..afa1711c9620 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
@@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
 		case AMDGPU_PCIE_GEN2:
 			if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
 			break;
diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
index c3d2e6dcf62a..7d7d698c7976 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
@@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
 		break;
 	case SMU_BIF_TABLE:
 		polaris10_update_bif_smc_table(hwmgr);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Evan Quan, Alex Deucher, Christian König, David Airlie,
	Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-hardening, dri-devel, amd-gfx, linux-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement instead of letting
the code fall through to the next case, and a fallthrough pseudo-keyword
as a replacement for a /* fall through */ comment,

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
 drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
index b5986d19dc08..afa1711c9620 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
@@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
 		case AMDGPU_PCIE_GEN2:
 			if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
 				break;
+			fallthrough;
 #endif
-			/* fall through */
 		default:
 			si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
 			break;
diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
index c3d2e6dcf62a..7d7d698c7976 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
@@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
 		break;
 	case SMU_BIF_TABLE:
 		polaris10_update_bif_smc_table(hwmgr);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 079/141] drm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter
  Cc: dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/drm_bufs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 7a01d0918861..aeb1327e3077 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -77,6 +77,7 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
 			if ((entry->map->offset & 0xffffffff) ==
 			    (map->offset & 0xffffffff))
 				return entry;
+			break;
 		default: /* Make gcc happy */
 			;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 079/141] drm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/drm_bufs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 7a01d0918861..aeb1327e3077 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -77,6 +77,7 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
 			if ((entry->map->offset & 0xffffffff) ==
 			    (map->offset & 0xffffffff))
 				return entry;
+			break;
 		default: /* Make gcc happy */
 			;
 		}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 080/141] drm/i915/gem: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter
  Cc: intel-gfx, dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dc8f052a0ffe..b699c1adb106 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -59,6 +59,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
 	switch (obj->mm.madv) {
 	case I915_MADV_DONTNEED:
 		i915_gem_object_truncate(obj);
+		return;
 	case __I915_MADV_PURGED:
 		return;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 080/141] drm/i915/gem: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter
  Cc: intel-gfx, Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dc8f052a0ffe..b699c1adb106 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -59,6 +59,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
 	switch (obj->mm.madv) {
 	case I915_MADV_DONTNEED:
 		i915_gem_object_truncate(obj);
+		return;
 	case __I915_MADV_PURGED:
 		return;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-gfx] [PATCH 080/141] drm/i915/gem: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter
  Cc: intel-gfx, Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dc8f052a0ffe..b699c1adb106 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -59,6 +59,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
 	switch (obj->mm.madv) {
 	case I915_MADV_DONTNEED:
 		i915_gem_object_truncate(obj);
+		return;
 	case __I915_MADV_PURGED:
 		return;
 	}
-- 
2.27.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 081/141] drm/nouveau/clk: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: dri-devel, nouveau, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
index da1770e47490..ae2733035ac2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
@@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src src)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 081/141] drm/nouveau/clk: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Gustavo A. R. Silva,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-hardening-u79uwXL29TY76Z2rM5mHXA

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
index da1770e47490..ae2733035ac2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
@@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src src)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 081/141] drm/nouveau/clk: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau, Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
index da1770e47490..ae2733035ac2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
@@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src src)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 082/141] drm/nouveau: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: dri-devel, nouveau, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of break statements instead
of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c        | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56b335a55966..037f312c948d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -461,6 +461,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, bool contig)
 			break;
 		case TTM_PL_TT:
 			error |= !(domain & NOUVEAU_GEM_DOMAIN_GART);
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..585344965504 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector *connector,
 			default:
 				break;
 			}
+			break;
 		case DRM_MODE_SCALE_FULLSCREEN:
 		case DRM_MODE_SCALE_CENTER:
 		case DRM_MODE_SCALE_ASPECT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 082/141] drm/nouveau: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Gustavo A. R. Silva,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-hardening-u79uwXL29TY76Z2rM5mHXA

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of break statements instead
of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c        | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56b335a55966..037f312c948d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -461,6 +461,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, bool contig)
 			break;
 		case TTM_PL_TT:
 			error |= !(domain & NOUVEAU_GEM_DOMAIN_GART);
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..585344965504 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector *connector,
 			default:
 				break;
 			}
+			break;
 		case DRM_MODE_SCALE_FULLSCREEN:
 		case DRM_MODE_SCALE_CENTER:
 		case DRM_MODE_SCALE_ASPECT:
-- 
2.27.0

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 082/141] drm/nouveau: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau, Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of break statements instead
of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nouveau_bo.c        | 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56b335a55966..037f312c948d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -461,6 +461,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, bool contig)
 			break;
 		case TTM_PL_TT:
 			error |= !(domain & NOUVEAU_GEM_DOMAIN_GART);
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..585344965504 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector *connector,
 			default:
 				break;
 			}
+			break;
 		case DRM_MODE_SCALE_FULLSCREEN:
 		case DRM_MODE_SCALE_CENTER:
 		case DRM_MODE_SCALE_ASPECT:
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 083/141] drm/nouveau/therm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: dri-devel, nouveau, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
index 0981b02790e2..bb2e71bf537f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
@@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 083/141] drm/nouveau/therm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Gustavo A. R. Silva,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-hardening-u79uwXL29TY76Z2rM5mHXA

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
index 0981b02790e2..bb2e71bf537f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
@@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 083/141] drm/nouveau/therm: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Ben Skeggs, David Airlie, Daniel Vetter
  Cc: nouveau, Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
index 0981b02790e2..bb2e71bf537f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
@@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line)
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: David Airlie, Daniel Vetter
  Cc: dri-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/via/via_irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, struct drm_file *file_priv)
 		irqwait->request.sequence +=
 			atomic_read(&cur_irq->irq_received);
 		irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+		break;
 	case VIA_IRQ_ABSOLUTE:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
@ 2020-11-20 18:35   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: David Airlie, Daniel Vetter
  Cc: Gustavo A. R. Silva, linux-kernel, dri-devel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/gpu/drm/via/via_irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, struct drm_file *file_priv)
 		irqwait->request.sequence +=
 			atomic_read(&cur_irq->irq_received);
 		irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+		break;
 	case VIA_IRQ_ABSOLUTE:
 		break;
 	default:
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 085/141] firewire: core: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (96 preceding siblings ...)
  (?)
@ 2020-11-20 18:35 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:35 UTC (permalink / raw)
  To: Stefan Richter
  Cc: linux1394-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/firewire/core-topology.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c
index ec68ed27b0a5..b63d55f5ebd3 100644
--- a/drivers/firewire/core-topology.c
+++ b/drivers/firewire/core-topology.c
@@ -58,6 +58,7 @@ static u32 *count_ports(u32 *sid, int *total_port_count, int *child_port_count)
 		case SELFID_PORT_PARENT:
 		case SELFID_PORT_NCONN:
 			(*total_port_count)++;
+			fallthrough;
 		case SELFID_PORT_NONE:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 086/141] hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (97 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  2020-11-21 18:50   ` Guenter Roeck
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Marius Zachmann, Jean Delvare, Guenter Roeck
  Cc: linux-hwmon, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/hwmon/corsair-cpro.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
index 591929ec217a..fa6aa4fc8b52 100644
--- a/drivers/hwmon/corsair-cpro.c
+++ b/drivers/hwmon/corsair-cpro.c
@@ -310,6 +310,7 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 087/141] hwmon: (max6621) Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (98 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  2020-11-21 18:50   ` Guenter Roeck
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Jean Delvare, Guenter Roeck
  Cc: linux-hwmon, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/hwmon/max6621.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c
index 367855d5edae..7821132e17fa 100644
--- a/drivers/hwmon/max6621.c
+++ b/drivers/hwmon/max6621.c
@@ -156,7 +156,7 @@ max6621_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
 		default:
 			break;
 		}
-
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 088/141] i3c: master: cdns: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:36   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Przemysław Gaj, Boris Brezillon
  Cc: linux-i3c, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/i3c/master/i3c-master-cdns.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
index 3f2226928fe0..5b37ffe5ad5b 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -1379,6 +1379,8 @@ static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master *master)
 
 		case IBIR_TYPE_MR:
 			WARN_ON(IBIR_XFER_BYTES(ibir) || (ibir & IBIR_ERROR));
+			break;
+
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 088/141] i3c: master: cdns: Fix fall-through warnings for Clang
@ 2020-11-20 18:36   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Przemysław Gaj, Boris Brezillon
  Cc: linux-i3c, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/i3c/master/i3c-master-cdns.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
index 3f2226928fe0..5b37ffe5ad5b 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -1379,6 +1379,8 @@ static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master *master)
 
 		case IBIR_TYPE_MR:
 			WARN_ON(IBIR_XFER_BYTES(ibir) || (ibir & IBIR_ERROR));
+			break;
+
 		default:
 			break;
 		}
-- 
2.27.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 089/141] ide: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (100 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: David S. Miller
  Cc: linux-ide, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/ide/siimage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ide/siimage.c b/drivers/ide/siimage.c
index c4b20f350b84..145c0ab3a856 100644
--- a/drivers/ide/siimage.c
+++ b/drivers/ide/siimage.c
@@ -493,6 +493,7 @@ static int init_chipset_siimage(struct pci_dev *dev)
 	case 0x30:
 		/* Clocking is disabled, attempt to force 133MHz clocking. */
 		sil_iowrite8(dev, tmp & ~0x20, scsc_addr);
+		break;
 	case 0x10:
 		/* On 133Mhz clocking. */
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 090/141] iio: adc: cpcap: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (101 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  2020-11-21 15:05   ` Jonathan Cameron
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Jonathan Cameron, Lars-Peter Clausen, Peter Meerwald-Stadler
  Cc: linux-iio, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/iio/adc/cpcap-adc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
index 64c3cc382311..f19c9aa93f17 100644
--- a/drivers/iio/adc/cpcap-adc.c
+++ b/drivers/iio/adc/cpcap-adc.c
@@ -557,6 +557,7 @@ static void cpcap_adc_setup_bank(struct cpcap_adc *ddata,
 		break;
 	case CPCAP_ADC_BATTP_PI16 ... CPCAP_ADC_BATTI_PI17:
 		value1 |= CPCAP_BIT_RAND1;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 091/141] iwlwifi: iwl-drv: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (102 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
	Intel Linux Wireless, Kalle Valo, David S. Miller,
	Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 9dcd2e990c9c..6a9be73d7661 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1579,7 +1579,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
 		break;
 	default:
 		WARN(1, "Invalid fw type %d\n", fw->type);
-		/* fall through */
+		fallthrough;
 	case IWL_FW_MVM:
 		op = &iwlwifi_opmode_table[MVM_OP_MODE];
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 092/141] libata: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (103 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-ide, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/ata/libata-eh.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index b6f92050e60c..2db1e9c66088 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -2613,6 +2613,7 @@ int ata_eh_reset(struct ata_link *link, int classify,
 			switch (tmp) {
 			case -EAGAIN:
 				rc = -EAGAIN;
+				break;
 			case 0:
 				break;
 			default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 093/141] mac80211: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (104 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Johannes Berg, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/mac80211/cfg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7276e66ae435..1d1a4f3c8d66 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -405,6 +405,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
 	case WLAN_CIPHER_SUITE_WEP104:
 		if (WARN_ON_ONCE(fips_enabled))
 			return -EINVAL;
+		break;
 	case WLAN_CIPHER_SUITE_CCMP:
 	case WLAN_CIPHER_SUITE_CCMP_256:
 	case WLAN_CIPHER_SUITE_AES_CMAC:
@@ -3307,6 +3308,7 @@ static int ieee80211_set_csa_beacon(struct ieee80211_sub_if_data *sdata,
 			if (cfg80211_get_chandef_type(&params->chandef) !=
 			    cfg80211_get_chandef_type(&sdata->u.ibss.chandef))
 				return -EINVAL;
+			break;
 		case NL80211_CHAN_WIDTH_5:
 		case NL80211_CHAN_WIDTH_10:
 		case NL80211_CHAN_WIDTH_20_NOHT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 094/141] media: atomisp: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:36   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Sakari Ailus, Greg Kroah-Hartman
  Cc: linux-media, devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
index b4813cd50daa..4a18da6bf0c1 100644
--- a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
+++ b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
@@ -368,6 +368,7 @@ static mipi_predictor_t sh_css_csi2_compression_type_2_mipi_predictor(
 		break;
 	case IA_CSS_CSI2_COMPRESSION_TYPE_2:
 		predictor = MIPI_PREDICTOR_TYPE2 - 1;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 094/141] media: atomisp: Fix fall-through warnings for Clang
@ 2020-11-20 18:36   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Sakari Ailus, Greg Kroah-Hartman
  Cc: devel, Gustavo A. R. Silva, linux-hardening, linux-kernel, linux-media

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
index b4813cd50daa..4a18da6bf0c1 100644
--- a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
+++ b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
@@ -368,6 +368,7 @@ static mipi_predictor_t sh_css_csi2_compression_type_2_mipi_predictor(
 		break;
 	case IA_CSS_CSI2_COMPRESSION_TYPE_2:
 		predictor = MIPI_PREDICTOR_TYPE2 - 1;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 095/141] media: dvb_frontend: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (106 preceding siblings ...)
  (?)
@ 2020-11-20 18:36 ` Gustavo A. R. Silva
  2020-11-22 16:32   ` Mauro Carvalho Chehab
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:36 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: linux-media, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/media/dvb-core/dvb_frontend.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index 06ea30a689d7..fb35697dd93c 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -984,6 +984,7 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
 				 fe->ops.info.symbol_rate_max);
 			return -EINVAL;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 096/141] media: rcar_jpu: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (107 preceding siblings ...)
  (?)
@ 2020-11-20 18:37 ` Gustavo A. R. Silva
  2020-11-22 16:33   ` Mauro Carvalho Chehab
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Mikhail Ulyanov, Mauro Carvalho Chehab
  Cc: linux-media, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/media/platform/rcar_jpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar_jpu.c b/drivers/media/platform/rcar_jpu.c
index 9b99ff368698..87466edf8a5e 100644
--- a/drivers/media/platform/rcar_jpu.c
+++ b/drivers/media/platform/rcar_jpu.c
@@ -648,6 +648,7 @@ static u8 jpu_parse_hdr(void *buffer, unsigned long size, unsigned int *width,
 			if (get_word_be(&jpeg_buffer, &word))
 				return 0;
 			skip(&jpeg_buffer, (long)word - 2);
+			break;
 		case 0:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 097/141] media: saa7134: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (108 preceding siblings ...)
  (?)
@ 2020-11-20 18:37 ` Gustavo A. R. Silva
  2020-11-22 16:32   ` Mauro Carvalho Chehab
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: linux-media, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/saa7134/saa7134-tvaudio.c b/drivers/media/pci/saa7134/saa7134-tvaudio.c
index 5cc4ef21f9d3..5dc97990fa0e 100644
--- a/drivers/media/pci/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/pci/saa7134/saa7134-tvaudio.c
@@ -885,6 +885,7 @@ void saa7134_enable_i2s(struct saa7134_dev *dev)
 	    saa_writeb(SAA7134_I2S_OUTPUT_FORMAT, i2s_format);
 	    saa_writeb(SAA7134_I2S_OUTPUT_LEVEL,  0x0F);
 	    saa_writeb(SAA7134_I2S_AUDIO_OUTPUT,  0x01);
+	    break;
 
 	default:
 	    break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Michal Simek, Adrian Hunter, Ulf Hansson
  Cc: linux-arm-kernel, linux-mmc, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 829ccef87426..1f7e42b6ced5 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 8 Taps are available */
 		tap_max = 8;
+		break;
 	default:
 		break;
 	}
@@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 30 Taps are available */
 		tap_max = 30;
+		break;
 	default:
 		break;
 	}
@@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 8 Taps are available */
 		tap_max = 8;
+		break;
 	default:
 		break;
 	}
@@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 30 Taps are available */
 		tap_max = 30;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Michal Simek, Adrian Hunter, Ulf Hansson
  Cc: Gustavo A. R. Silva, linux-mmc, linux-kernel, linux-arm-kernel,
	linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 829ccef87426..1f7e42b6ced5 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 8 Taps are available */
 		tap_max = 8;
+		break;
 	default:
 		break;
 	}
@@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 30 Taps are available */
 		tap_max = 30;
+		break;
 	default:
 		break;
 	}
@@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 8 Taps are available */
 		tap_max = 8;
+		break;
 	default:
 		break;
 	}
@@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
 	case MMC_TIMING_MMC_HS200:
 		/* For 200MHz clock, 30 Taps are available */
 		tap_max = 30;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 099/141] mt76: mt7615: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Kalle Valo,
	David S. Miller, Jakub Kicinski, Matthias Brugger
  Cc: linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
	linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index f4756bb946c3..9a9685e5ab84 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -127,7 +127,7 @@ mt7615_eeprom_parse_hw_band_cap(struct mt7615_dev *dev)
 		break;
 	case MT_EE_DBDC:
 		dev->dbdc_support = true;
-		/* fall through */
+		fallthrough;
 	default:
 		dev->mt76.cap.has_2ghz = true;
 		dev->mt76.cap.has_5ghz = true;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 099/141] mt76: mt7615: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Kalle Valo,
	David S. Miller, Jakub Kicinski, Matthias Brugger
  Cc: netdev, linux-wireless, linux-kernel, Gustavo A. R. Silva,
	linux-mediatek, linux-hardening, linux-arm-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index f4756bb946c3..9a9685e5ab84 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -127,7 +127,7 @@ mt7615_eeprom_parse_hw_band_cap(struct mt7615_dev *dev)
 		break;
 	case MT_EE_DBDC:
 		dev->dbdc_support = true;
-		/* fall through */
+		fallthrough;
 	default:
 		dev->mt76.cap.has_2ghz = true;
 		dev->mt76.cap.has_5ghz = true;
-- 
2.27.0


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 099/141] mt76: mt7615: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Kalle Valo,
	David S. Miller, Jakub Kicinski, Matthias Brugger
  Cc: netdev, linux-wireless, linux-kernel, Gustavo A. R. Silva,
	linux-mediatek, linux-hardening, linux-arm-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index f4756bb946c3..9a9685e5ab84 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -127,7 +127,7 @@ mt7615_eeprom_parse_hw_band_cap(struct mt7615_dev *dev)
 		break;
 	case MT_EE_DBDC:
 		dev->dbdc_support = true;
-		/* fall through */
+		fallthrough;
 	default:
 		dev->mt76.cap.has_2ghz = true;
 		dev->mt76.cap.has_5ghz = true;
-- 
2.27.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 100/141] mtd: cfi: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements and a return
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/chips/cfi_cmdset_0001.c | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 42001c49833b..b7f5e7977dcd 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2549,6 +2549,7 @@ static int cfi_intelext_suspend(struct mtd_info *mtd)
 			   anyway? The latter for now. */
 			printk(KERN_NOTICE "Flash device refused suspend due to active operation (state %d)\n", chip->state);
 			ret = -EAGAIN;
+			break;
 		case FL_PM_SUSPENDED:
 			break;
 		}
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index a1f3e1031c3d..6f6b0265c22d 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -902,6 +902,7 @@ static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr
 			/* Someone else might have been playing with it. */
 			goto retry;
 		}
+		return 0;
 
 	case FL_READY:
 	case FL_CFI_QUERY:
@@ -2994,6 +2995,7 @@ static int cfi_amdstd_suspend(struct mtd_info *mtd)
 			 * as the whole point is that nobody can do anything
 			 * with the chip now anyway.
 			 */
+			break;
 		case FL_PM_SUSPENDED:
 			break;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c b/drivers/mtd/chips/cfi_cmdset_0020.c
index 270322bca221..d35df526e0a6 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -1332,6 +1332,8 @@ static int cfi_staa_suspend(struct mtd_info *mtd)
 			 * as the whole point is that nobody can do anything
 			 * with the chip now anyway.
 			 */
+			break;
+
 		case FL_PM_SUSPENDED:
 			break;
 
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 100/141] mtd: cfi: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: Gustavo A. R. Silva, linux-mtd, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements and a return
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/chips/cfi_cmdset_0001.c | 1 +
 drivers/mtd/chips/cfi_cmdset_0002.c | 2 ++
 drivers/mtd/chips/cfi_cmdset_0020.c | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c
index 42001c49833b..b7f5e7977dcd 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd/chips/cfi_cmdset_0001.c
@@ -2549,6 +2549,7 @@ static int cfi_intelext_suspend(struct mtd_info *mtd)
 			   anyway? The latter for now. */
 			printk(KERN_NOTICE "Flash device refused suspend due to active operation (state %d)\n", chip->state);
 			ret = -EAGAIN;
+			break;
 		case FL_PM_SUSPENDED:
 			break;
 		}
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index a1f3e1031c3d..6f6b0265c22d 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -902,6 +902,7 @@ static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr
 			/* Someone else might have been playing with it. */
 			goto retry;
 		}
+		return 0;
 
 	case FL_READY:
 	case FL_CFI_QUERY:
@@ -2994,6 +2995,7 @@ static int cfi_amdstd_suspend(struct mtd_info *mtd)
 			 * as the whole point is that nobody can do anything
 			 * with the chip now anyway.
 			 */
+			break;
 		case FL_PM_SUSPENDED:
 			break;
 
diff --git a/drivers/mtd/chips/cfi_cmdset_0020.c b/drivers/mtd/chips/cfi_cmdset_0020.c
index 270322bca221..d35df526e0a6 100644
--- a/drivers/mtd/chips/cfi_cmdset_0020.c
+++ b/drivers/mtd/chips/cfi_cmdset_0020.c
@@ -1332,6 +1332,8 @@ static int cfi_staa_suspend(struct mtd_info *mtd)
 			 * as the whole point is that nobody can do anything
 			 * with the chip now anyway.
 			 */
+			break;
+
 		case FL_PM_SUSPENDED:
 			break;
 
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 101/141] mtd: mtdchar: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/mtdchar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index b40f46a43fc6..a306659ea683 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -993,6 +993,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 			if (!mtd_has_oob(mtd))
 				return -EOPNOTSUPP;
 			mfi->mode = arg;
+			break;
 
 		case MTD_FILE_MODE_NORMAL:
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 101/141] mtd: mtdchar: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: Gustavo A. R. Silva, linux-mtd, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/mtdchar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index b40f46a43fc6..a306659ea683 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -993,6 +993,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 			if (!mtd_has_oob(mtd))
 				return -EOPNOTSUPP;
 			mfi->mode = arg;
+			break;
 
 		case MTD_FILE_MODE_NORMAL:
 			break;
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 102/141] mtd: onenand: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Kyungmin Park, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/onenand/onenand_samsung.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/onenand/onenand_samsung.c b/drivers/mtd/nand/onenand/onenand_samsung.c
index 87b28e397d67..b64895573515 100644
--- a/drivers/mtd/nand/onenand/onenand_samsung.c
+++ b/drivers/mtd/nand/onenand/onenand_samsung.c
@@ -396,6 +396,7 @@ static int s3c_onenand_command(struct mtd_info *mtd, int cmd, loff_t addr,
 	case ONENAND_CMD_READOOB:
 	case ONENAND_CMD_BUFFERRAM:
 		ONENAND_SET_NEXT_BUFFERRAM(this);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 102/141] mtd: onenand: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Kyungmin Park, Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: Gustavo A. R. Silva, linux-mtd, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/onenand/onenand_samsung.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/onenand/onenand_samsung.c b/drivers/mtd/nand/onenand/onenand_samsung.c
index 87b28e397d67..b64895573515 100644
--- a/drivers/mtd/nand/onenand/onenand_samsung.c
+++ b/drivers/mtd/nand/onenand/onenand_samsung.c
@@ -396,6 +396,7 @@ static int s3c_onenand_command(struct mtd_info *mtd, int cmd, loff_t addr,
 	case ONENAND_CMD_READOOB:
 	case ONENAND_CMD_BUFFERRAM:
 		ONENAND_SET_NEXT_BUFFERRAM(this);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 103/141] mtd: rawnand: fsmc: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/raw/fsmc_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index 4191831df182..273626d49769 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -916,6 +916,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
 				 "Using 4-bit SW BCH ECC scheme\n");
 			break;
 		}
+		break;
 
 	case NAND_ECC_ENGINE_TYPE_ON_DIE:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 103/141] mtd: rawnand: fsmc: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: Gustavo A. R. Silva, linux-mtd, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/raw/fsmc_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c
index 4191831df182..273626d49769 100644
--- a/drivers/mtd/nand/raw/fsmc_nand.c
+++ b/drivers/mtd/nand/raw/fsmc_nand.c
@@ -916,6 +916,7 @@ static int fsmc_nand_attach_chip(struct nand_chip *nand)
 				 "Using 4-bit SW BCH ECC scheme\n");
 			break;
 		}
+		break;
 
 	case NAND_ECC_ENGINE_TYPE_ON_DIE:
 		break;
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Maxime Coquelin, Alexandre Torgue
  Cc: linux-mtd, linux-stm32, linux-arm-kernel, linux-kernel,
	linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of fallthrough pseudo-keywords
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 550bda4d1415..002fa521036f 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			bit_position += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
@@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			byte_addr += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Maxime Coquelin, Alexandre Torgue
  Cc: Gustavo A. R. Silva, linux-kernel, linux-mtd, linux-hardening,
	linux-stm32, linux-arm-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of fallthrough pseudo-keywords
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 550bda4d1415..002fa521036f 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			bit_position += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
@@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			byte_addr += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Maxime Coquelin, Alexandre Torgue
  Cc: Gustavo A. R. Silva, linux-kernel, linux-mtd, linux-hardening,
	linux-stm32, linux-arm-kernel

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of fallthrough pseudo-keywords
instead of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 550bda4d1415..002fa521036f 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			bit_position += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
@@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
 		switch (b % 4) {
 		case 2:
 			byte_addr += shifting;
+			fallthrough;
 		case 1:
 			break;
 		default:
-- 
2.27.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 105/141] net: ax25: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (116 preceding siblings ...)
  (?)
@ 2020-11-20 18:37 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Joerg Reuter, Ralf Baechle, David S. Miller, Jakub Kicinski
  Cc: linux-hams, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/ax25/af_ax25.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 269ee89d2c2b..2631efc6e359 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -850,6 +850,7 @@ static int ax25_create(struct net *net, struct socket *sock, int protocol,
 		case AX25_P_ROSE:
 			if (ax25_protocol_is_registered(AX25_P_ROSE))
 				return -ESOCKTNOSUPPORT;
+			break;
 #endif
 		default:
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 106/141] net: bridge: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Roopa Prabhu, Nikolay Aleksandrov, David S. Miller, Jakub Kicinski
  Cc: bridge, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/bridge/br_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 59a318b9f646..8db219d979c5 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -148,6 +148,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
 		break;
 	case BR_PKT_UNICAST:
 		dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Bridge] [PATCH 106/141] net: bridge: Fix fall-through warnings for Clang
@ 2020-11-20 18:37   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:37 UTC (permalink / raw)
  To: Roopa Prabhu, Nikolay Aleksandrov, David S. Miller, Jakub Kicinski
  Cc: netdev, bridge, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/bridge/br_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 59a318b9f646..8db219d979c5 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -148,6 +148,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
 		break;
 	case BR_PKT_UNICAST:
 		dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 107/141] net: core: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (118 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/core/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 82dc6b48e45f..9efb03ce504d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5214,6 +5214,7 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
 			goto another_round;
 		case RX_HANDLER_EXACT:
 			deliver_exact = true;
+			break;
 		case RX_HANDLER_PASS:
 			break;
 		default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 108/141] netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (119 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  2020-11-20 22:49   ` Florian Westphal
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	Jakub Kicinski
  Cc: netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/ipv4/netfilter/ipt_REJECT.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index e16b98ee6266..7dbb10bbd0f5 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -57,6 +57,7 @@ reject_tg(struct sk_buff *skb, const struct xt_action_param *par)
 		break;
 	case IPT_TCP_RESET:
 		nf_send_reset(xt_net(par), skb, hook);
+		break;
 	case IPT_ICMP_ECHOREPLY:
 		/* Doesn't happen. */
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 109/141] net: netrom: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (120 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Ralf Baechle, David S. Miller, Jakub Kicinski
  Cc: linux-hams, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/netrom/nr_route.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index 78da5eab252a..de0456073dc0 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -266,6 +266,7 @@ static int __must_check nr_add_node(ax25_address *nr, const char *mnemonic,
 		fallthrough;
 	case 2:
 		re_sort_routes(nr_node, 0, 1);
+		break;
 	case 1:
 		break;
 	}
@@ -359,6 +360,7 @@ static int nr_del_node(ax25_address *callsign, ax25_address *neighbour, struct n
 					fallthrough;
 				case 1:
 					nr_node->routes[1] = nr_node->routes[2];
+					fallthrough;
 				case 2:
 					break;
 				}
@@ -482,6 +484,7 @@ static int nr_dec_obs(void)
 					fallthrough;
 				case 1:
 					s->routes[1] = s->routes[2];
+					break;
 				case 2:
 					break;
 				}
@@ -529,6 +532,7 @@ void nr_rt_device_down(struct net_device *dev)
 							fallthrough;
 						case 1:
 							t->routes[1] = t->routes[2];
+							break;
 						case 2:
 							break;
 						}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 110/141] net/packet: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (121 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/packet/af_packet.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index cefbd50c1090..217d44ab3325 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1649,6 +1649,7 @@ static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
 	case PACKET_FANOUT_ROLLOVER:
 		if (type_flags & PACKET_FANOUT_FLAG_ROLLOVER)
 			return -EINVAL;
+		break;
 	case PACKET_FANOUT_HASH:
 	case PACKET_FANOUT_LB:
 	case PACKET_FANOUT_CPU:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 111/141] net: plip: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (122 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/plip/plip.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index 4406b353123e..e26cf91bdec2 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -516,6 +516,7 @@ plip_receive(unsigned short nibble_timeout, struct net_device *dev,
 		*data_p |= (c0 << 1) & 0xf0;
 		write_data (dev, 0x00); /* send ACK */
 		*ns_p = PLIP_NB_BEGIN;
+		break;
 	case PLIP_NB_2:
 		break;
 	}
@@ -808,6 +809,7 @@ plip_send_packet(struct net_device *dev, struct net_local *nl,
 				return HS_TIMEOUT;
 			}
 		}
+		break;
 
 	case PLIP_PK_LENGTH_LSB:
 		if (plip_send(nibble_timeout, dev,
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 112/141] net: rose: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (123 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Ralf Baechle, David S. Miller, Jakub Kicinski
  Cc: linux-hams, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/rose/rose_route.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 6e35703ff353..c0e04c261a15 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -347,6 +347,7 @@ static int rose_del_node(struct rose_route_struct *rose_route,
 				case 1:
 					rose_node->neighbour[1] =
 						rose_node->neighbour[2];
+					break;
 				case 2:
 					break;
 				}
@@ -508,6 +509,7 @@ void rose_rt_device_down(struct net_device *dev)
 					fallthrough;
 				case 1:
 					t->neighbour[1] = t->neighbour[2];
+					break;
 				case 2:
 					break;
 				}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 113/141] nl80211: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (124 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Johannes Berg, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/wireless/nl80211.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a77174b99b07..132540a9ac4a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11165,6 +11165,7 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
 	case NL80211_IFTYPE_P2P_DEVICE:
 		if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
 			return -EINVAL;
+		break;
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_ADHOC:
 	case NL80211_IFTYPE_P2P_CLIENT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 114/141] phy: qcom-usb-hs: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (125 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Andy Gross, Bjorn Andersson, Kishon Vijay Abraham I, Vinod Koul
  Cc: linux-arm-msm, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/phy/qualcomm/phy-qcom-usb-hs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-usb-hs.c b/drivers/phy/qualcomm/phy-qcom-usb-hs.c
index 327df1a99f77..5c6c17673396 100644
--- a/drivers/phy/qualcomm/phy-qcom-usb-hs.c
+++ b/drivers/phy/qualcomm/phy-qcom-usb-hs.c
@@ -56,6 +56,7 @@ static int qcom_usb_hs_phy_set_mode(struct phy *phy,
 			fallthrough;
 		case PHY_MODE_USB_DEVICE:
 			val |= ULPI_INT_SESS_VALID;
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 115/141] rds: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (126 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Santosh Shilimkar, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-rdma, rds-devel, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/rds/tcp_connect.c | 1 +
 net/rds/threads.c     | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index 4e64598176b0..5461d77fff4f 100644
--- a/net/rds/tcp_connect.c
+++ b/net/rds/tcp_connect.c
@@ -78,6 +78,7 @@ void rds_tcp_state_change(struct sock *sk)
 	case TCP_CLOSE_WAIT:
 	case TCP_CLOSE:
 		rds_conn_path_drop(cp, false);
+		break;
 	default:
 		break;
 	}
diff --git a/net/rds/threads.c b/net/rds/threads.c
index 32dc50f0a303..1f424cbfcbb4 100644
--- a/net/rds/threads.c
+++ b/net/rds/threads.c
@@ -208,6 +208,7 @@ void rds_send_worker(struct work_struct *work)
 		case -ENOMEM:
 			rds_stats_inc(s_send_delayed_retry);
 			queue_delayed_work(rds_wq, &cp->cp_send_w, 2);
+			break;
 		default:
 			break;
 		}
@@ -232,6 +233,7 @@ void rds_recv_worker(struct work_struct *work)
 		case -ENOMEM:
 			rds_stats_inc(s_recv_delayed_retry);
 			queue_delayed_work(rds_wq, &cp->cp_recv_w, 2);
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 116/141] rt2x00: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (127 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo, David S. Miller,
	Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 3b6100e6c8f6..d4d389e8f1b4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
@@ -941,6 +941,7 @@ void rt2x00queue_unpause_queue(struct data_queue *queue)
 		 * receive frames.
 		 */
 		queue->rt2x00dev->ops->lib->kick_queue(queue);
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 117/141] rtl8xxxu: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (128 preceding siblings ...)
  (?)
@ 2020-11-20 18:38 ` Gustavo A. R. Silva
  2020-11-20 21:39   ` Jes Sorensen
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:38 UTC (permalink / raw)
  To: Jes Sorensen, Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix
multiple warnings by replacing /* fall through */ comments with
the new pseudo-keyword macro fallthrough; instead of letting the
code fall through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 5cd7ef3625c5..afc97958fa4d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -1145,7 +1145,7 @@ void rtl8xxxu_gen1_config_channel(struct ieee80211_hw *hw)
 	switch (hw->conf.chandef.width) {
 	case NL80211_CHAN_WIDTH_20_NOHT:
 		ht = false;
-		/* fall through */
+		fallthrough;
 	case NL80211_CHAN_WIDTH_20:
 		opmode |= BW_OPMODE_20MHZ;
 		rtl8xxxu_write8(priv, REG_BW_OPMODE, opmode);
@@ -1272,7 +1272,7 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw)
 	switch (hw->conf.chandef.width) {
 	case NL80211_CHAN_WIDTH_20_NOHT:
 		ht = false;
-		/* fall through */
+		fallthrough;
 	case NL80211_CHAN_WIDTH_20:
 		rf_mode_bw |= WMAC_TRXPTCL_CTL_BW_20;
 		subchannel = 0;
@@ -1741,11 +1741,11 @@ static int rtl8xxxu_identify_chip(struct rtl8xxxu_priv *priv)
 		case 3:
 			priv->ep_tx_low_queue = 1;
 			priv->ep_tx_count++;
-			/* fall through */
+			fallthrough;
 		case 2:
 			priv->ep_tx_normal_queue = 1;
 			priv->ep_tx_count++;
-			/* fall through */
+			fallthrough;
 		case 1:
 			priv->ep_tx_high_queue = 1;
 			priv->ep_tx_count++;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 118/141] rtw88: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (129 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Yan-Hsuan Chuang, Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/realtek/rtw88/fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 042015bc8055..e2d4bb180afd 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -1473,7 +1473,7 @@ static bool rtw_fw_dump_check_size(struct rtw_dev *rtwdev,
 	case RTW_FW_FIFO_SEL_RX:
 		if ((start_addr + size) > rtwdev->chip->fw_fifo_addr[sel])
 			return false;
-		/*fall through*/
+		fallthrough;
 	default:
 		return true;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 119/141] rxrpc: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (130 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: David Howells, David S. Miller, Jakub Kicinski
  Cc: linux-afs, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/rxrpc/af_rxrpc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0a2f4817ec6c..aa43191dbb09 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -471,6 +471,7 @@ static int rxrpc_connect(struct socket *sock, struct sockaddr *addr,
 	switch (rx->sk.sk_state) {
 	case RXRPC_UNBOUND:
 		rx->sk.sk_state = RXRPC_CLIENT_UNBOUND;
+		break;
 	case RXRPC_CLIENT_UNBOUND:
 	case RXRPC_CLIENT_BOUND:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 120/141] scsi: aacraid: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (131 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Adaptec OEM Raid Solutions, James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/aacraid/commsup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index b99ca1b0c553..0ae0d1fa2b50 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -1448,6 +1448,7 @@ static void aac_handle_aif(struct aac_dev * dev, struct fib * fibptr)
 				break;
 			}
 			scsi_rescan_device(&device->sdev_gendev);
+			break;
 
 		default:
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 121/141] scsi: aha1740: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (132 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/aha1740.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/aha1740.c b/drivers/scsi/aha1740.c
index 5a227c03895f..0dc831026e9e 100644
--- a/drivers/scsi/aha1740.c
+++ b/drivers/scsi/aha1740.c
@@ -152,6 +152,7 @@ static int aha1740_makecode(unchar *sense, unchar *status)
 					retval=DID_ERROR; /* It's an Overrun */
 				/* If not overrun, assume underrun and
 				 * ignore it! */
+				break;
 			case 0x00: /* No info, assume no error, should
 				    * not occur */
 				break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 122/141] scsi: csiostor: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (133 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/csiostor/csio_wr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/csiostor/csio_wr.c b/drivers/scsi/csiostor/csio_wr.c
index 9010cb6045dc..fe0355c964bc 100644
--- a/drivers/scsi/csiostor/csio_wr.c
+++ b/drivers/scsi/csiostor/csio_wr.c
@@ -830,6 +830,7 @@ csio_wr_destroy_queues(struct csio_hw *hw, bool cmd)
 				if (flq_idx != -1)
 					csio_q_flid(hw, flq_idx) = CSIO_MAX_QID;
 			}
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 123/141] scsi: lpfc: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (134 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: James Smart, Dick Kennedy, James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/lpfc/lpfc_bsg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c
index 6f9d648a9b9c..d6394281fad1 100644
--- a/drivers/scsi/lpfc/lpfc_bsg.c
+++ b/drivers/scsi/lpfc/lpfc_bsg.c
@@ -3535,6 +3535,7 @@ static int lpfc_bsg_check_cmd_access(struct lpfc_hba *phba,
 				mb->mbxCommand);
 			return -EPERM;
 		}
+		break;
 	case MBX_WRITE_NV:
 	case MBX_WRITE_VPARMS:
 	case MBX_LOAD_SM:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 124/141] scsi: stex: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (135 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: James E.J. Bottomley, Martin K. Petersen
  Cc: linux-scsi, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/scsi/stex.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index d4f10c0d813c..40473e4f850f 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -685,6 +685,7 @@ stex_queuecommand_lck(struct scsi_cmnd *cmd, void (*done)(struct scsi_cmnd *))
 			done(cmd);
 			return 0;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 125/141] sctp: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (136 preceding siblings ...)
  (?)
@ 2020-11-20 18:39 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner,
	David S. Miller, Jakub Kicinski
  Cc: linux-sctp, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a break statement and replacing a
comment with a goto statement instead of letting the code fall through
to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/sctp/input.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/sctp/input.c b/net/sctp/input.c
index 55d4fc6f371d..5944af035ba0 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -633,7 +633,7 @@ int sctp_v4_err(struct sk_buff *skb, __u32 info)
 		break;
 	case ICMP_REDIRECT:
 		sctp_icmp_redirect(sk, transport, skb);
-		/* Fall through to out_unlock. */
+		goto out_unlock;
 	default:
 		goto out_unlock;
 	}
@@ -1236,6 +1236,7 @@ static struct sctp_association *__sctp_rcv_walk_lookup(struct net *net,
 						net, ch, laddr,
 						sctp_hdr(skb)->source,
 						transportp);
+			break;
 		default:
 			break;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 126/141] slimbus: messaging: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Srinivas Kandagatla
  Cc: alsa-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/slimbus/messaging.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
index d5879142dbef..f2b5d347d227 100644
--- a/drivers/slimbus/messaging.c
+++ b/drivers/slimbus/messaging.c
@@ -258,6 +258,7 @@ int slim_xfer_msg(struct slim_device *sbdev, struct slim_val_inf *msg,
 	case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
 	case SLIM_MSG_MC_CLEAR_INFORMATION:
 		txn->rl += msg->num_bytes;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 126/141] slimbus: messaging: Fix fall-through warnings for Clang
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Srinivas Kandagatla
  Cc: alsa-devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/slimbus/messaging.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
index d5879142dbef..f2b5d347d227 100644
--- a/drivers/slimbus/messaging.c
+++ b/drivers/slimbus/messaging.c
@@ -258,6 +258,7 @@ int slim_xfer_msg(struct slim_device *sbdev, struct slim_val_inf *msg,
 	case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
 	case SLIM_MSG_MC_CLEAR_INFORMATION:
 		txn->rl += msg->num_bytes;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 127/141] staging: qlge: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Manish Chopra, Greg Kroah-Hartman
  Cc: GR-Linux-NIC-Dev, netdev, devel, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/qlge/qlge_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
index 27da386f9d87..c41b1373dcf8 100644
--- a/drivers/staging/qlge/qlge_main.c
+++ b/drivers/staging/qlge/qlge_main.c
@@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
 		break;
 	case IB_MAC_IOCB_RSP_ERR_CRC:
 		stats->rx_crc_err++;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 127/141] staging: qlge: Fix fall-through warnings for Clang
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Manish Chopra, Greg Kroah-Hartman
  Cc: devel, GR-Linux-NIC-Dev, netdev, Gustavo A. R. Silva,
	linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/qlge/qlge_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
index 27da386f9d87..c41b1373dcf8 100644
--- a/drivers/staging/qlge/qlge_main.c
+++ b/drivers/staging/qlge/qlge_main.c
@@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
 		break;
 	case IB_MAC_IOCB_RSP_ERR_CRC:
 		stats->rx_crc_err++;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 128/141] staging: vt6656: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Forest Bond, Greg Kroah-Hartman
  Cc: devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/vt6656/main_usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 8bf851c53f4e..b90d3dab28b1 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -914,6 +914,7 @@ static int vnt_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 
 			vnt_mac_disable_keyentry(priv, key->hw_key_idx);
 		}
+		break;
 
 	default:
 		break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 128/141] staging: vt6656: Fix fall-through warnings for Clang
@ 2020-11-20 18:39   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:39 UTC (permalink / raw)
  To: Forest Bond, Greg Kroah-Hartman
  Cc: devel, Gustavo A. R. Silva, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/staging/vt6656/main_usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 8bf851c53f4e..b90d3dab28b1 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -914,6 +914,7 @@ static int vnt_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 
 			vnt_mac_disable_keyentry(priv, key->hw_key_idx);
 		}
+		break;
 
 	default:
 		break;
-- 
2.27.0

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 129/141] SUNRPC: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (140 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: J. Bruce Fields, Chuck Lever, Trond Myklebust, Anna Schumaker,
	David S. Miller, Jakub Kicinski
  Cc: linux-nfs, netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/sunrpc/rpc_pipe.c | 1 +
 net/sunrpc/xprtsock.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index eadc0ede928c..99fcb0bea1d0 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -478,6 +478,7 @@ rpc_get_inode(struct super_block *sb, umode_t mode)
 		inode->i_fop = &simple_dir_operations;
 		inode->i_op = &simple_dir_inode_operations;
 		inc_nlink(inode);
+		break;
 	default:
 		break;
 	}
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 7090bbee0ec5..a785c15804d6 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1874,6 +1874,7 @@ static int xs_local_setup_socket(struct sock_xprt *transport)
 		xprt->stat.connect_time += (long)jiffies -
 					   xprt->stat.connect_start;
 		xprt_set_connected(xprt);
+		break;
 	case -ENOBUFS:
 		break;
 	case -ENOENT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 130/141] tipc: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (141 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Jon Maloy, Ying Xue, David S. Miller, Jakub Kicinski
  Cc: netdev, tipc-discussion, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/tipc/link.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/tipc/link.c b/net/tipc/link.c
index 06b880da2a8e..839082cf259e 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -615,6 +615,7 @@ int tipc_link_fsm_evt(struct tipc_link *l, int evt)
 			break;
 		case LINK_FAILOVER_BEGIN_EVT:
 			l->state = LINK_FAILINGOVER;
+			break;
 		case LINK_FAILURE_EVT:
 		case LINK_RESET_EVT:
 		case LINK_ESTABLISH_EVT:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 131/141] tpm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (142 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  2020-11-23 22:52   ` Jarkko Sakkinen
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe
  Cc: linux-integrity, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/char/tpm/eventlog/tpm1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
index 2c96977ad080..8aa9057601d6 100644
--- a/drivers/char/tpm/eventlog/tpm1.c
+++ b/drivers/char/tpm/eventlog/tpm1.c
@@ -210,6 +210,7 @@ static int get_event_name(char *dest, struct tcpa_event *event,
 		default:
 			break;
 		}
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 132/141] ubi: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Richard Weinberger, Miquel Raynal, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/ubi/build.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index e85b04e9716b..75b6e98db775 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1353,6 +1353,7 @@ static int bytes_str_to_int(const char *str)
 		result *= 1024;
 		if (endp[1] == 'i' && endp[2] == 'B')
 			endp += 2;
+		fallthrough;
 	case '\0':
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 132/141] ubi: Fix fall-through warnings for Clang
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Richard Weinberger, Miquel Raynal, Vignesh Raghavendra
  Cc: Gustavo A. R. Silva, linux-mtd, linux-kernel, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword instead of letting the
code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/mtd/ubi/build.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index e85b04e9716b..75b6e98db775 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1353,6 +1353,7 @@ static int bytes_str_to_int(const char *str)
 		result *= 1024;
 		if (endp[1] == 'i' && endp[2] == 'B')
 			endp += 2;
+		fallthrough;
 	case '\0':
 		break;
 	default:
-- 
2.27.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 133/141] usb: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (144 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Felipe Balbi, Greg Kroah-Hartman, Olav Kongas, Bin Liu,
	Alan Stern, Oliver Neukum
  Cc: linux-usb, linux-kernel, usb-storage, linux-scsi,
	linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break/return/fallthrough
statements instead of letting the code fall through to the next
case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/usb/gadget/function/f_fs.c         | 2 ++
 drivers/usb/gadget/function/f_loopback.c   | 2 +-
 drivers/usb/gadget/function/f_sourcesink.c | 1 +
 drivers/usb/gadget/udc/dummy_hcd.c         | 2 ++
 drivers/usb/host/fotg210-hcd.c             | 2 +-
 drivers/usb/host/isp116x-hcd.c             | 1 +
 drivers/usb/host/max3421-hcd.c             | 1 +
 drivers/usb/host/oxu210hp-hcd.c            | 1 +
 drivers/usb/misc/yurex.c                   | 1 +
 drivers/usb/musb/tusb6010.c                | 1 +
 drivers/usb/storage/ene_ub6250.c           | 1 +
 drivers/usb/storage/uas.c                  | 1 +
 12 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 046f770a76da..7f9c4e35d3db 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -678,6 +678,8 @@ static __poll_t ffs_ep0_poll(struct file *file, poll_table *wait)
 			mask |= (EPOLLIN | EPOLLOUT);
 			break;
 		}
+		break;
+
 	case FFS_CLOSING:
 		break;
 	case FFS_DEACTIVATED:
diff --git a/drivers/usb/gadget/function/f_loopback.c b/drivers/usb/gadget/function/f_loopback.c
index 1803646b3678..b56ad7c3838b 100644
--- a/drivers/usb/gadget/function/f_loopback.c
+++ b/drivers/usb/gadget/function/f_loopback.c
@@ -274,7 +274,7 @@ static void loopback_complete(struct usb_ep *ep, struct usb_request *req)
 	default:
 		ERROR(cdev, "%s loop complete --> %d, %d/%d\n", ep->name,
 				status, req->actual, req->length);
-		/* FALLTHROUGH */
+		fallthrough;
 
 	/* NOTE:  since this driver doesn't maintain an explicit record
 	 * of requests it submitted (just maintains qlen count), we
diff --git a/drivers/usb/gadget/function/f_sourcesink.c b/drivers/usb/gadget/function/f_sourcesink.c
index ed68a4860b7d..5a201ba7b155 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -559,6 +559,7 @@ static void source_sink_complete(struct usb_ep *ep, struct usb_request *req)
 #if 1
 		DBG(cdev, "%s complete --> %d, %d/%d\n", ep->name,
 				status, req->actual, req->length);
+		break;
 #endif
 	case -EREMOTEIO:		/* short read */
 		break;
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c
index 53a227217f1c..bb0dc67ecdd3 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -553,6 +553,7 @@ static int dummy_enable(struct usb_ep *_ep,
 				/* we'll fake any legal size */
 				break;
 			/* save a return statement */
+			fallthrough;
 		default:
 			goto done;
 		}
@@ -595,6 +596,7 @@ static int dummy_enable(struct usb_ep *_ep,
 			if (max <= 1023)
 				break;
 			/* save a return statement */
+			fallthrough;
 		default:
 			goto done;
 		}
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 1d94fcfac2c2..0451943f0bc4 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -5276,7 +5276,7 @@ static int fotg210_urb_enqueue(struct usb_hcd *hcd, struct urb *urb,
 		 */
 		if (urb->transfer_buffer_length > (16 * 1024))
 			return -EMSGSIZE;
-		/* FALLTHROUGH */
+		fallthrough;
 	/* case PIPE_BULK: */
 	default:
 		if (!qh_urb_transaction(fotg210, urb, &qtd_list, mem_flags))
diff --git a/drivers/usb/host/isp116x-hcd.c b/drivers/usb/host/isp116x-hcd.c
index 3055d9abfec3..8544a2a2c1e6 100644
--- a/drivers/usb/host/isp116x-hcd.c
+++ b/drivers/usb/host/isp116x-hcd.c
@@ -1447,6 +1447,7 @@ static int isp116x_bus_resume(struct usb_hcd *hcd)
 		val &= ~HCCONTROL_HCFS;
 		val |= HCCONTROL_USB_RESUME;
 		isp116x_write_reg32(isp116x, HCCONTROL, val);
+		break;
 	case HCCONTROL_USB_RESUME:
 		break;
 	case HCCONTROL_USB_OPER:
diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 0894f6caccb2..0b5d47e6aab2 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1537,6 +1537,7 @@ max3421_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flags)
 				__func__, urb->interval);
 			return -EINVAL;
 		}
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index 27dbbe1b28b1..aa42df39e6a1 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -1365,6 +1365,7 @@ __acquires(oxu->lock)
 	switch (urb->status) {
 	case -EINPROGRESS:		/* success */
 		urb->status = 0;
+		break;
 	default:			/* fault */
 		break;
 	case -EREMOTEIO:		/* fault or normal */
diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index e3165d79b5f6..73ebfa6e9715 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -137,6 +137,7 @@ static void yurex_interrupt(struct urb *urb)
 		dev_err(&dev->interface->dev,
 			"%s - overflow with length %d, actual length is %d\n",
 			__func__, YUREX_BUF_SIZE, dev->urb->actual_length);
+		return;
 	case -ECONNRESET:
 	case -ENOENT:
 	case -ESHUTDOWN:
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index c26683a2702b..c42937692207 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -467,6 +467,7 @@ static void musb_do_idle(struct timer_list *t)
 		fallthrough;
 	case OTG_STATE_A_IDLE:
 		tusb_musb_set_vbus(musb, 0);
+		break;
 	default:
 		break;
 	}
diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers/usb/storage/ene_ub6250.c
index 98c1aa594e6c..5f7d678502be 100644
--- a/drivers/usb/storage/ene_ub6250.c
+++ b/drivers/usb/storage/ene_ub6250.c
@@ -861,6 +861,7 @@ static int ms_count_freeblock(struct us_data *us, u16 PhyBlock)
 		case MS_LB_NOT_USED:
 		case MS_LB_NOT_USED_ERASED:
 			Count++;
+			break;
 		default:
 			break;
 		}
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index c8a577309e8f..6bd33c57fdcb 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -690,6 +690,7 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd,
 		fallthrough;
 	case DMA_TO_DEVICE:
 		cmdinfo->state |= ALLOC_DATA_OUT_URB | SUBMIT_DATA_OUT_URB;
+		break;
 	case DMA_NONE:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Andres Salomon, Bartlomiej Zolnierkiewicz
  Cc: linux-geode, dri-devel, linux-fbdev, linux-kernel,
	linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/video/fbdev/geode/lxfb_ops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c
index b3a041fce570..32baaf59fcf7 100644
--- a/drivers/video/fbdev/geode/lxfb_ops.c
+++ b/drivers/video/fbdev/geode/lxfb_ops.c
@@ -682,6 +682,7 @@ static void lx_restore_display_ctlr(struct lxfb_par *par)
 		case DC_DV_CTL:
 			/* set all ram to dirty */
 			write_dc(par, i, par->dc[i] | DC_DV_CTL_CLEAR_DV_RAM);
+			break;
 
 		case DC_RSVD_1:
 		case DC_RSVD_2:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Andres Salomon, Bartlomiej Zolnierkiewicz
  Cc: linux-fbdev, linux-kernel, Gustavo A. R. Silva, dri-devel,
	linux-geode, linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/video/fbdev/geode/lxfb_ops.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/geode/lxfb_ops.c b/drivers/video/fbdev/geode/lxfb_ops.c
index b3a041fce570..32baaf59fcf7 100644
--- a/drivers/video/fbdev/geode/lxfb_ops.c
+++ b/drivers/video/fbdev/geode/lxfb_ops.c
@@ -682,6 +682,7 @@ static void lx_restore_display_ctlr(struct lxfb_par *par)
 		case DC_DV_CTL:
 			/* set all ram to dirty */
 			write_dc(par, i, par->dc[i] | DC_DV_CTL_CLEAR_DV_RAM);
+			break;
 
 		case DC_RSVD_1:
 		case DC_RSVD_2:
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 135/141] video: fbdev: pm2fb: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: dri-devel, linux-fbdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/video/fbdev/pm2fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 0642555289e0..27893fa139b0 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -239,6 +239,7 @@ static u32 to3264(u32 timing, int bpp, int is64)
 		fallthrough;
 	case 16:
 		timing >>= 1;
+		fallthrough;
 	case 32:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 135/141] video: fbdev: pm2fb: Fix fall-through warnings for Clang
@ 2020-11-20 18:40   ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: linux-fbdev, Gustavo A. R. Silva, linux-kernel, dri-devel,
	linux-hardening

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a fallthrough pseudo-keyword.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/video/fbdev/pm2fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 0642555289e0..27893fa139b0 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -239,6 +239,7 @@ static u32 to3264(u32 timing, int bpp, int is64)
 		fallthrough;
 	case 16:
 		timing >>= 1;
+		fallthrough;
 	case 32:
 		break;
 	}
-- 
2.27.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 136/141] virtio_net: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (147 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Michael S. Tsirkin, Jason Wang, David S. Miller, Jakub Kicinski
  Cc: virtualization, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a goto statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/virtio_net.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 21b71148c532..fd326dc586aa 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -732,6 +732,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
 			fallthrough;
 		case XDP_ABORTED:
 			trace_xdp_exception(vi->dev, xdp_prog, act);
+			goto err_xdp;
 		case XDP_DROP:
 			goto err_xdp;
 		}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 137/141] wcn36xx: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (148 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: wcn36xx, linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/ath/wcn36xx/smd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index 766400f7b61c..4c8f4a7e7085 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2568,7 +2568,7 @@ static int wcn36xx_smd_hw_scan_ind(struct wcn36xx *wcn, void *buf, size_t len)
 	case WCN36XX_HAL_SCAN_IND_FAILED:
 	case WCN36XX_HAL_SCAN_IND_DEQUEUED:
 		scan_info.aborted = true;
-		/* fall through */
+		fallthrough;
 	case WCN36XX_HAL_SCAN_IND_COMPLETED:
 		mutex_lock(&wcn->scan_lock);
 		wcn->scan_req = NULL;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 138/141] xen/manage: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (149 preceding siblings ...)
  (?)
@ 2020-11-20 18:40 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:40 UTC (permalink / raw)
  To: Boris Ostrovsky, Juergen Gross, Stefano Stabellini
  Cc: xen-devel, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/xen/manage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index cd046684e0d1..374d36de7f5a 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -179,6 +179,7 @@ static int poweroff_nb(struct notifier_block *cb, unsigned long code, void *unus
 	case SYS_HALT:
 	case SYS_POWER_OFF:
 		shutting_down = SHUTDOWN_POWEROFF;
+		break;
 	default:
 		break;
 	}
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 139/141] xfrm: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (150 preceding siblings ...)
  (?)
@ 2020-11-20 18:41 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:41 UTC (permalink / raw)
  To: Steffen Klassert, Herbert Xu, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 net/xfrm/xfrm_interface.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
index 9b8e292a7c6a..8ea705df8e3c 100644
--- a/net/xfrm/xfrm_interface.c
+++ b/net/xfrm/xfrm_interface.c
@@ -433,6 +433,7 @@ static int xfrmi4_err(struct sk_buff *skb, u32 info)
 	case ICMP_DEST_UNREACH:
 		if (icmp_hdr(skb)->code != ICMP_FRAG_NEEDED)
 			return 0;
+		break;
 	case ICMP_REDIRECT:
 		break;
 	default:
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 140/141] zd1201: Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (151 preceding siblings ...)
  (?)
@ 2020-11-20 18:41 ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:41 UTC (permalink / raw)
  To: Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening,
	Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* Fall through */ comment with the new
pseudo-keyword macro fallthrough; instead of letting the code fall
through to the next case.

Notice that Clang doesn't recognize /* Fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/net/wireless/zydas/zd1201.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1201.c b/drivers/net/wireless/zydas/zd1201.c
index 718c4ee865ba..097805b55c59 100644
--- a/drivers/net/wireless/zydas/zd1201.c
+++ b/drivers/net/wireless/zydas/zd1201.c
@@ -966,7 +966,7 @@ static int zd1201_set_mode(struct net_device *dev,
 			 */
 			zd1201_join(zd, "\0-*#\0", 5);
 			/* Put port in pIBSS */
-			/* Fall through */
+			fallthrough;
 		case 8: /* No pseudo-IBSS in wireless extensions (yet) */
 			porttype = ZD1201_PORTTYPE_PSEUDOIBSS;
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [PATCH 141/141] Input: libps2 - Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                   ` (152 preceding siblings ...)
  (?)
@ 2020-11-20 18:41 ` Gustavo A. R. Silva
  2020-11-23  6:16   ` Dmitry Torokhov
  -1 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:41 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: linux-input, linux-kernel, linux-hardening, Gustavo A. R. Silva

In preparation to enable -Wimplicit-fallthrough for Clang, fix a
warning by replacing a /* Fall through */ comment with the new
pseudo-keyword macro fallthrough.

Notice that Clang doesn't recognize /* Fall through */ comments as
implicit fall-through markings.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 drivers/input/serio/libps2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
index 8a16e41f7b7f..250e213cc80c 100644
--- a/drivers/input/serio/libps2.c
+++ b/drivers/input/serio/libps2.c
@@ -405,7 +405,7 @@ bool ps2_handle_ack(struct ps2dev *ps2dev, u8 data)
 			ps2dev->nak = PS2_RET_ERR;
 			break;
 		}
-		/* Fall through */
+		fallthrough;
 
 	/*
 	 * Workaround for mice which don't ACK the Get ID command.
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [EXT] [PATCH 018/141] qed: Fix fall-through warnings for Clang
  2020-11-20 18:26 ` [PATCH 018/141] qed: " Gustavo A. R. Silva
@ 2020-11-20 18:50   ` Igor Russkikh
  2020-11-23 22:46     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Igor Russkikh @ 2020-11-20 18:50 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Ariel Elior, David S. Miller, Jakub Kicinski
  Cc: GR-everest-linux-l2, netdev, linux-kernel, linux-hardening



On 20/11/2020 9:26 pm, Gustavo A. R. Silva wrote:
> External Email
> 
> ----------------------------------------------------------------------
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding a couple of break statements instead of
> just letting the code fall through to the next case.
> 
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KSPP_linux
> _issues_115&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=GtqbaEwqFLiM6BiwNMdKmpXb5o
> up1VLiSIroUNQwbYA&m=6E7IvGvqcEGj8wEOVoN1BySZhGUVECVTBJCmNiRsHUw&s=J1SWrfEL
> erJOzUlJdD_S5afGaZosmVP8lyKsu9DTULw&e= 
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Igor Russkikh <irusskikh@marvell.com>

Thanks,
  Igor

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                     ` (10 preceding siblings ...)
  (?)
@ 2020-11-20 18:53   ` Jakub Kicinski
  -1 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches,
	Kees Cook

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module, amd-gfx,
	linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 18:53   ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 18:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> change[1] is meant to be reverted at some point. So, this patch helps
> to move in that direction.
> 
> Something important to mention is that there is currently a discrepancy
> between GCC and Clang when dealing with switch fall-through to empty case
> statements or to cases that only contain a break/continue/return
> statement[2][3][4].

Are we sure we want to make this change? Was it discussed before?

Are there any bugs Clangs puritanical definition of fallthrough helped
find?

IMVHO compiler warnings are supposed to warn about issues that could
be bugs. Falling through to default: break; can hardly be a bug?!

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 007/141] gpio: Fix fall-through warnings for Clang
  2020-11-20 18:25 ` [PATCH 007/141] gpio: " Gustavo A. R. Silva
@ 2020-11-20 18:56   ` Andy Shevchenko
  2020-11-20 18:58     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-20 18:56 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Alban Bedel, Linus Walleij, Bartosz Golaszewski, Mika Westerberg,
	linux-gpio, linux-kernel, linux-acpi, linux-hardening

On Fri, Nov 20, 2020 at 12:25:16PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding a break and a fallthrough statements
> instead of just letting the code fall through to the next case.

Shouldn't this go via GPIO tree?

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 007/141] gpio: Fix fall-through warnings for Clang
  2020-11-20 18:56   ` Andy Shevchenko
@ 2020-11-20 18:58     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 18:58 UTC (permalink / raw)
  To: Andy Shevchenko, Gustavo A. R. Silva
  Cc: Alban Bedel, Linus Walleij, Bartosz Golaszewski, Mika Westerberg,
	linux-gpio, linux-kernel, linux-acpi, linux-hardening



On 11/20/20 12:56, Andy Shevchenko wrote:
> On Fri, Nov 20, 2020 at 12:25:16PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
>> warnings by explicitly adding a break and a fallthrough statements
>> instead of just letting the code fall through to the next case.
> 
> Shouldn't this go via GPIO tree?

Yeah. Actually, you can ignore this patch, as I already sent two
separate patches for this:

https://lore.kernel.org/lkml/20201119170901.GA22703@embeddedor/
https://lore.kernel.org/lkml/20201119170739.GA22665@embeddedor/

I noticed this immediately after sending this out.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:28   ` Joe Perches
                       ` (11 preceding siblings ...)
  (?)
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, linux-arm-kernel,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, linux-crypto, linux-decnet-user, linux-ext4,
	linux-fbdev, linux-geode, linux-gpio, linux-hams, linux-hwmon,
	linux-i3c, linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, linux-media, linux-mmc, linux-mm, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Kees Cook



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-sctp, linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, target-devel, linux-arm-kernel,
	linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook,
	linux-mm, netdev, linux-decnet-user, linux-mmc, linux-sctp,
	linux-renesas-soc, linux-security-module, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: intel-wired-lan



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: cluster-devel.redhat.com



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:02     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:02 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, linux-kernel
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, linux-arm-kernel, linux-hwmon,
	x86, linux-nfs, GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev,
	linux-decnet-user, linux-mmc, linux-sctp, linux-renesas-soc,
	linux-security-module, linux-usb, netfilter-devel, linux-crypto,
	patches, linux-integrity, target-devel, linux-hardening



On 11/20/20 12:28, Joe Perches wrote:
> On Fri, 2020-11-20 at 12:21 -0600, Gustavo A. R. Silva wrote:
>> Hi all,
>>
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
> 
> This was a bit hard to parse for a second or three.
> 
> Thanks Gustavo.
> 
> How was this change done?

I audited case by case in order to determine the best fit for each
situation. Depending on the surrounding logic, sometimes it makes
more sense a goto or a fallthrough rather than merely a break.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 049/141] pinctrl: Fix fall-through warnings for Clang
  2020-11-20 18:31 ` [PATCH 049/141] pinctrl: " Gustavo A. R. Silva
@ 2020-11-20 19:04   ` Geert Uytterhoeven
  2020-11-23 22:49     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Geert Uytterhoeven @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Linus Walleij, Linux-Renesas, open list:GPIO SUBSYSTEM,
	Linux Kernel Mailing List, linux-hardening

On Fri, Nov 20, 2020 at 7:31 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-pinctrl-for-v5.11.

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

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:53   ` Jakub Kicinski
                       ` (11 preceding siblings ...)
  (?)
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches,
	Kees Cook


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module, amd-gfx,
	linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: intel-wired-lan


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: cluster-devel.redhat.com


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:04     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 19:04 UTC (permalink / raw)
  To: Jakub Kicinski, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening


Hi,

On 11/20/20 12:53, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
>> This series aims to fix almost all remaining fall-through warnings in
>> order to enable -Wimplicit-fallthrough for Clang.
>>
>> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
>> add multiple break/goto/return/fallthrough statements instead of just
>> letting the code fall through to the next case.
>>
>> Notice that in order to enable -Wimplicit-fallthrough for Clang, this
>> change[1] is meant to be reverted at some point. So, this patch helps
>> to move in that direction.
>>
>> Something important to mention is that there is currently a discrepancy
>> between GCC and Clang when dealing with switch fall-through to empty case
>> statements or to cases that only contain a break/continue/return
>> statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

The justification for this is explained in this same changelog text:

Now that the -Wimplicit-fallthrough option has been globally enabled[5],
any compiler should really warn on missing either a fallthrough annotation
or any of the other case-terminating statements (break/continue/return/
goto) when falling through to the next case statement. Making exceptions
to this introduces variation in case handling which may continue to lead
to bugs, misunderstandings, and a general lack of robustness. The point
of enabling options like -Wimplicit-fallthrough is to prevent human error
and aid developers in spotting bugs before their code is even built/
submitted/committed, therefore eliminating classes of bugs. So, in order
to really accomplish this, we should, and can, move in the direction of
addressing any error-prone scenarios and get rid of the unintentional
fallthrough bug-class in the kernel, entirely, even if there is some minor
redundancy. Better to have explicit case-ending statements than continue to
have exceptions where one must guess as to the right result. The compiler
will eliminate any actual redundancy.

Note that there is already a patch in mainline that addresses almost
40,000 of these issues[6].

[1] commit e2079e93f562c ("kbuild: Do not enable -Wimplicit-fallthrough for clang for now")
[2] ClangBuiltLinux#636
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[4] https://godbolt.org/z/xgkvIh
[5] commit a035d552a93b ("Makefile: Globally enable fall-through warning")
[6] commit 4169e889e588 ("include: jhash/signal: Fix fall-through warnings for Clang")

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:53   ` Jakub Kicinski
                       ` (11 preceding siblings ...)
  (?)
@ 2020-11-20 19:30     ` Kees Cook
  -1 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:30     ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 19:30 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > change[1] is meant to be reverted at some point. So, this patch helps
> > to move in that direction.
> > 
> > Something important to mention is that there is currently a discrepancy
> > between GCC and Clang when dealing with switch fall-through to empty case
> > statements or to cases that only contain a break/continue/return
> > statement[2][3][4].
> 
> Are we sure we want to make this change? Was it discussed before?
> 
> Are there any bugs Clangs puritanical definition of fallthrough helped
> find?
> 
> IMVHO compiler warnings are supposed to warn about issues that could
> be bugs. Falling through to default: break; can hardly be a bug?!

It's certainly a place where the intent is not always clear. I think
this makes all the cases unambiguous, and doesn't impact the machine
code, since the compiler will happily optimize away any behavioral
redundancy.


-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 19:30     ` Kees Cook
                         ` (10 preceding siblings ...)
  (?)
@ 2020-11-20 19:51       ` Jakub Kicinski
  -1 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 19:51       ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-20 19:51 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > This series aims to fix almost all remaining fall-through warnings in
> > > order to enable -Wimplicit-fallthrough for Clang.
> > > 
> > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > add multiple break/goto/return/fallthrough statements instead of just
> > > letting the code fall through to the next case.
> > > 
> > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > change[1] is meant to be reverted at some point. So, this patch helps
> > > to move in that direction.
> > > 
> > > Something important to mention is that there is currently a discrepancy
> > > between GCC and Clang when dealing with switch fall-through to empty case
> > > statements or to cases that only contain a break/continue/return
> > > statement[2][3][4].  
> > 
> > Are we sure we want to make this change? Was it discussed before?
> > 
> > Are there any bugs Clangs puritanical definition of fallthrough helped
> > find?
> > 
> > IMVHO compiler warnings are supposed to warn about issues that could
> > be bugs. Falling through to default: break; can hardly be a bug?!  
> 
> It's certainly a place where the intent is not always clear. I think
> this makes all the cases unambiguous, and doesn't impact the machine
> code, since the compiler will happily optimize away any behavioral
> redundancy.

If none of the 140 patches here fix a real bug, and there is no change
to machine code then it sounds to me like a W=2 kind of a warning.

I think clang is just being annoying here, but if I'm the only one who
feels this way chances are I'm wrong :)

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 19:51       ` Jakub Kicinski
                           ` (11 preceding siblings ...)
  (?)
@ 2020-11-20 20:48         ` Kees Cook
  -1 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 20:48         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-20 20:48 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

I'd like to avoid splitting common -W options between default and W=2
just based on the compiler. Getting -Wimplicit-fallthrough enabled found
plenty of bugs, so making sure it works correctly for both compilers
feels justified to me. (This is just a subset of the same C language
short-coming.)

> I think clang is just being annoying here, but if I'm the only one who
> feels this way chances are I'm wrong :)

It's being pretty pedantic, but I don't think it's unreasonable to
explicitly state how every case ends. GCC's silence for the case of
"fall through to a break" doesn't really seem justified.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 058/141] xen-blkfront: Fix fall-through warnings for Clang
  2020-11-20 18:32 ` [PATCH 058/141] xen-blkfront: " Gustavo A. R. Silva
@ 2020-11-20 21:36   ` boris.ostrovsky
  2020-11-23 22:53     ` Gustavo A. R. Silva
  2020-11-23 10:28   ` Roger Pau Monné
  1 sibling, 1 reply; 1306+ messages in thread
From: boris.ostrovsky @ 2020-11-20 21:36 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Konrad Rzeszutek Wilk, Roger Pau Monné,
	Juergen Gross, Stefano Stabellini, Jens Axboe
  Cc: xen-devel, linux-block, linux-kernel, linux-hardening


On 11/20/20 1:32 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/block/xen-blkfront.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 48629d3433b4..34b028be78ab 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2462,6 +2462,7 @@ static void blkback_changed(struct xenbus_device *dev,
>  			break;
>  		if (talk_to_blkback(dev, info))
>  			break;
> +		break;
>  	case XenbusStateInitialising:
>  	case XenbusStateInitialised:
>  	case XenbusStateReconfiguring:


Reviewed-by Boris Ostrovsky <boris.ostrovsky@oracle.com>


(for patch 138 as well)


Although I thought using 'fallthrough' attribute was the more common approach.


-boris


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 117/141] rtl8xxxu: Fix fall-through warnings for Clang
  2020-11-20 18:38 ` [PATCH 117/141] rtl8xxxu: " Gustavo A. R. Silva
@ 2020-11-20 21:39   ` Jes Sorensen
  2020-11-24 16:09     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jes Sorensen @ 2020-11-20 21:39 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Kalle Valo, David S. Miller, Jakub Kicinski
  Cc: linux-wireless, netdev, linux-kernel, linux-hardening

On 11/20/20 1:38 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix
> multiple warnings by replacing /* fall through */ comments with
> the new pseudo-keyword macro fallthrough; instead of letting the
> code fall through to the next case.
> 
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

While I wasn't CC'ed on the cover-letter I see Jakub also raised issues
about this unnecessary patch noise.

Quite frankly, this seems to be patch churn for the sake of patch churn.
If clang is broken, fix clang instead.

NACK


Jes

> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 5cd7ef3625c5..afc97958fa4d 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -1145,7 +1145,7 @@ void rtl8xxxu_gen1_config_channel(struct ieee80211_hw *hw)
>  	switch (hw->conf.chandef.width) {
>  	case NL80211_CHAN_WIDTH_20_NOHT:
>  		ht = false;
> -		/* fall through */
> +		fallthrough;
>  	case NL80211_CHAN_WIDTH_20:
>  		opmode |= BW_OPMODE_20MHZ;
>  		rtl8xxxu_write8(priv, REG_BW_OPMODE, opmode);
> @@ -1272,7 +1272,7 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw)
>  	switch (hw->conf.chandef.width) {
>  	case NL80211_CHAN_WIDTH_20_NOHT:
>  		ht = false;
> -		/* fall through */
> +		fallthrough;
>  	case NL80211_CHAN_WIDTH_20:
>  		rf_mode_bw |= WMAC_TRXPTCL_CTL_BW_20;
>  		subchannel = 0;
> @@ -1741,11 +1741,11 @@ static int rtl8xxxu_identify_chip(struct rtl8xxxu_priv *priv)
>  		case 3:
>  			priv->ep_tx_low_queue = 1;
>  			priv->ep_tx_count++;
> -			/* fall through */
> +			fallthrough;
>  		case 2:
>  			priv->ep_tx_normal_queue = 1;
>  			priv->ep_tx_count++;
> -			/* fall through */
> +			fallthrough;
>  		case 1:
>  			priv->ep_tx_high_queue = 1;
>  			priv->ep_tx_count++;
> 


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                     ` (12 preceding siblings ...)
  (?)
@ 2020-11-20 22:21   ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches, Kees Cook

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches, Kees Cook

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module, amd-gfx,
	linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	Ext4 Developers List, Linux Media Mailing List, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	drbd-dev, linux-hams, ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: intel-wired-lan

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-20 22:21   ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-20 22:21 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Kees Cook, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

Hi Gustavo,

On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> Hi all,
>
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.

Thanks for this.

Since this warning is reliable in both/all compilers and we are
eventually getting rid of all the cases, what about going even further
and making it an error right after?

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
  2020-11-20 18:24   ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 22:42     ` Alex Deucher
  -1 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:42 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Alex Deucher, Christian König, David Airlie, Daniel Vetter,
	linux-hardening, Maling list - DRI developers, amd-gfx list,
	LKML

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 3579565e0eab..98ca6b976b6e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 0d8e203b10ef..e61121629b93 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index 3ebbddb63705..584b99b80c29 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
>                                 WREG32(reg, tmp);
>                         }
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 9bcd0eebc6d7..d56b474b3a21 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
>         case CHIP_POLARIS12:
>         case CHIP_VEGAM:
>                 vi_common_set_clockgating_state_by_smu(adev, state);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-20 22:42     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:42 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Alex Deucher, Christian König

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 3579565e0eab..98ca6b976b6e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 0d8e203b10ef..e61121629b93 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index 3ebbddb63705..584b99b80c29 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
>                                 WREG32(reg, tmp);
>                         }
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 9bcd0eebc6d7..d56b474b3a21 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
>         case CHIP_POLARIS12:
>         case CHIP_VEGAM:
>                 vi_common_set_clockgating_state_by_smu(adev, state);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-20 22:42     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:42 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Daniel Vetter, Alex Deucher,
	Christian König

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 1 +
>  drivers/gpu/drm/amd/amdgpu/vi.c        | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 3579565e0eab..98ca6b976b6e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -8398,6 +8398,7 @@ static int gfx_v10_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 0d8e203b10ef..e61121629b93 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -5683,6 +5683,7 @@ static int gfx_v9_0_set_priv_inst_fault_state(struct amdgpu_device *adev,
>                 WREG32_FIELD15(GC, 0, CP_INT_CNTL_RING0,
>                                PRIV_INSTR_INT_ENABLE,
>                                state == AMDGPU_IRQ_STATE_ENABLE ? 1 : 0);
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> index 3ebbddb63705..584b99b80c29 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> @@ -502,6 +502,7 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct amdgpu_device *adev,
>                                 WREG32(reg, tmp);
>                         }
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 9bcd0eebc6d7..d56b474b3a21 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1645,6 +1645,7 @@ static int vi_common_set_clockgating_state(void *handle,
>         case CHIP_POLARIS12:
>         case CHIP_VEGAM:
>                 vi_common_set_clockgating_state_by_smu(adev, state);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
  2020-11-20 18:24   ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 22:43     ` Alex Deucher
  -1 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:43 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Alex Deucher, Christian König, David Airlie, Daniel Vetter,
	linux-hardening, Maling list - DRI developers, amd-gfx list,
	LKML

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
> as replacement for /* fall through */ comments.
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
>  drivers/gpu/drm/radeon/r300.c   | 1 +
>  drivers/gpu/drm/radeon/si_dpm.c | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 886e9959496f..3d0a2e81b2de 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
>                         break;
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 73f67bf222e1..213dc49b6322 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
>                 /* valid register only on RV530 */
>                 if (p->rdev->family == CHIP_RV530)
>                         break;
> +               fallthrough;
>                 /* fallthrough do not move */
>         default:
>                 goto fail;
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index d1c73e9db889..d19c08e0ad5a 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
>                         break;
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
@ 2020-11-20 22:43     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:43 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Alex Deucher, Christian König

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
> as replacement for /* fall through */ comments.
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
>  drivers/gpu/drm/radeon/r300.c   | 1 +
>  drivers/gpu/drm/radeon/si_dpm.c | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 886e9959496f..3d0a2e81b2de 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
>                         break;
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 73f67bf222e1..213dc49b6322 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
>                 /* valid register only on RV530 */
>                 if (p->rdev->family == CHIP_RV530)
>                         break;
> +               fallthrough;
>                 /* fallthrough do not move */
>         default:
>                 goto fail;
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index d1c73e9db889..d19c08e0ad5a 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
>                         break;
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 005/141] drm/radeon: Fix fall-through warnings for Clang
@ 2020-11-20 22:43     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:43 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Daniel Vetter, Alex Deucher,
	Christian König

On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple fallthrough pseudo-keyword macros,
> as replacement for /* fall through */ comments.
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
>  drivers/gpu/drm/radeon/r300.c   | 1 +
>  drivers/gpu/drm/radeon/si_dpm.c | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 886e9959496f..3d0a2e81b2de 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -4860,8 +4860,8 @@ static void ci_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         pi->force_pcie_gen = ci_get_current_pcie_speed(rdev);
>                         break;
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 73f67bf222e1..213dc49b6322 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -1162,6 +1162,7 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
>                 /* valid register only on RV530 */
>                 if (p->rdev->family == CHIP_RV530)
>                         break;
> +               fallthrough;
>                 /* fallthrough do not move */
>         default:
>                 goto fail;
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index d1c73e9db889..d19c08e0ad5a 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -5748,8 +5748,8 @@ static void si_request_link_speed_change_before_state_change(struct radeon_devic
>                 case RADEON_PCIE_GEN2:
>                         if (radeon_acpi_pcie_performance_request(rdev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(rdev);
>                         break;
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
  2020-11-20 18:28   ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 22:45     ` Alex Deucher
  -1 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:45 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Harry Wentland, Leo Li, Alex Deucher, Christian König,
	David Airlie, Daniel Vetter, linux-hardening,
	Maling list - DRI developers, amd-gfx list, LKML

On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
>  3 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index ad394aefa5d9..23a373ca94b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 29d64e7e304f..fd1e64fa8744 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
>                         break;
>                 case 4:
>                         result = get_soc_bb_info_v4_4(bp, soc_bb_info);
> +                       break;
>                 default:
>                         break;
>                 }
> @@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index fec87a2e210c..b9254a87ee73 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
>
>                                 return false;
>                         }
> +                       break;
>                 default:
>                         break;
>                 }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-20 22:45     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:45 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, Leo Li, LKML, Maling list - DRI developers,
	David Airlie, linux-hardening, Alex Deucher,
	Christian König

On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
>  3 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index ad394aefa5d9..23a373ca94b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 29d64e7e304f..fd1e64fa8744 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
>                         break;
>                 case 4:
>                         result = get_soc_bb_info_v4_4(bp, soc_bb_info);
> +                       break;
>                 default:
>                         break;
>                 }
> @@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index fec87a2e210c..b9254a87ee73 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
>
>                                 return false;
>                         }
> +                       break;
>                 default:
>                         break;
>                 }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-20 22:45     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:45 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, Leo Li, LKML, Maling list - DRI developers,
	David Airlie, linux-hardening, Daniel Vetter, Alex Deucher,
	Harry Wentland, Christian König

On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 1 +
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c      | 1 +
>  3 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index ad394aefa5d9..23a373ca94b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -1198,6 +1198,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 29d64e7e304f..fd1e64fa8744 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -903,6 +903,7 @@ static enum bp_result bios_parser_get_soc_bb_info(
>                         break;
>                 case 4:
>                         result = get_soc_bb_info_v4_4(bp, soc_bb_info);
> +                       break;
>                 default:
>                         break;
>                 }
> @@ -1019,6 +1020,7 @@ static enum bp_result bios_parser_get_embedded_panel_info(
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index fec87a2e210c..b9254a87ee73 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1052,6 +1052,7 @@ static bool dc_link_detect_helper(struct dc_link *link,
>
>                                 return false;
>                         }
> +                       break;
>                 default:
>                         break;
>                 }
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
  2020-11-20 18:35   ` Gustavo A. R. Silva
  (?)
@ 2020-11-20 22:46     ` Alex Deucher
  -1 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:46 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Evan Quan, Alex Deucher, Christian König, David Airlie,
	Daniel Vetter, linux-hardening, Maling list - DRI developers,
	amd-gfx list, LKML

On Fri, Nov 20, 2020 at 1:35 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a break statement instead of letting
> the code fall through to the next case, and a fallthrough pseudo-keyword
> as a replacement for a /* fall through */ comment,
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> index b5986d19dc08..afa1711c9620 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> @@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
>                 case AMDGPU_PCIE_GEN2:
>                         if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
>                         break;
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> index c3d2e6dcf62a..7d7d698c7976 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> @@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
>                 break;
>         case SMU_BIF_TABLE:
>                 polaris10_update_bif_smc_table(hwmgr);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
@ 2020-11-20 22:46     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:46 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Alex Deucher, Evan Quan, Christian König

On Fri, Nov 20, 2020 at 1:35 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a break statement instead of letting
> the code fall through to the next case, and a fallthrough pseudo-keyword
> as a replacement for a /* fall through */ comment,
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> index b5986d19dc08..afa1711c9620 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> @@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
>                 case AMDGPU_PCIE_GEN2:
>                         if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
>                         break;
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> index c3d2e6dcf62a..7d7d698c7976 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> @@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
>                 break;
>         case SMU_BIF_TABLE:
>                 polaris10_update_bif_smc_table(hwmgr);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 078/141] drm/amd/pm: Fix fall-through warnings for Clang
@ 2020-11-20 22:46     ` Alex Deucher
  0 siblings, 0 replies; 1306+ messages in thread
From: Alex Deucher @ 2020-11-20 22:46 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Daniel Vetter, Alex Deucher, Evan Quan,
	Christian König

On Fri, Nov 20, 2020 at 1:35 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a break statement instead of letting
> the code fall through to the next case, and a fallthrough pseudo-keyword
> as a replacement for a /* fall through */ comment,
>
> Notice that Clang doesn't recognize /* fall through */ comments as
> implicit fall-through markings.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/pm/powerplay/si_dpm.c                  | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> index b5986d19dc08..afa1711c9620 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
> @@ -6200,8 +6200,8 @@ static void si_request_link_speed_change_before_state_change(struct amdgpu_devic
>                 case AMDGPU_PCIE_GEN2:
>                         if (amdgpu_acpi_pcie_performance_request(adev, PCIE_PERF_REQ_PECI_GEN2, false) == 0)
>                                 break;
> +                       fallthrough;
>  #endif
> -                       /* fall through */
>                 default:
>                         si_pi->force_pcie_gen = si_get_current_pcie_speed(adev);
>                         break;
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> index c3d2e6dcf62a..7d7d698c7976 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/polaris10_smumgr.c
> @@ -2272,6 +2272,7 @@ static int polaris10_update_smc_table(struct pp_hwmgr *hwmgr, uint32_t type)
>                 break;
>         case SMU_BIF_TABLE:
>                 polaris10_update_bif_smc_table(hwmgr);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 015/141] netfilter: Fix fall-through warnings for Clang
  2020-11-20 18:26 ` [PATCH 015/141] netfilter: " Gustavo A. R. Silva
@ 2020-11-20 22:47   ` Florian Westphal
  2020-11-23 22:45     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Florian Westphal @ 2020-11-20 22:47 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, Jakub Kicinski, netfilter-devel, coreteam,
	netdev, linux-kernel, linux-hardening

Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.

Acked-by: Florian Westphal <fw@strlen.de>

Feel free to carry this in next iteration of series, if any.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 108/141] netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  2020-11-20 18:38 ` [PATCH 108/141] netfilter: ipt_REJECT: " Gustavo A. R. Silva
@ 2020-11-20 22:49   ` Florian Westphal
  2020-11-24 14:37     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Florian Westphal @ 2020-11-20 22:49 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
	David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
	Jakub Kicinski, netfilter-devel, coreteam, netdev, linux-kernel,
	linux-hardening

Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.

Acked-by: Florian Westphal <fw@strlen.de>

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-20 18:23 ` [PATCH 001/141] afs: " Gustavo A. R. Silva
@ 2020-11-20 23:18   ` Joe Perches
  2020-11-20 23:28     ` Gustavo A. R. Silva
  2020-11-23 16:10   ` David Howells
  1 sibling, 1 reply; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 23:18 UTC (permalink / raw)
  To: Gustavo A. R. Silva, David Howells
  Cc: linux-afs, linux-kernel, linux-hardening

On Fri, 2020-11-20 at 12:23 -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple fallthrough pseudo-keywords
> in places where the code is intended to fall through to the next
> case.

This is the first of the actual patches I've seen.
I think adding fallthough for these patches isn't the best option.

> diff --git a/fs/afs/cmservice.c b/fs/afs/cmservice.c
[]
> @@ -322,6 +322,8 @@ static int afs_deliver_cb_callback(struct afs_call *call)
>  			return ret;
>  
> 
>  		call->unmarshall++;
> +
> +		fallthrough;

My preference would be to change these to break and not fallthrough;

>  	case 5:
>  		break;
>  	}

etc...


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-20 23:18   ` Joe Perches
@ 2020-11-20 23:28     ` Gustavo A. R. Silva
  2020-11-20 23:41       ` Joe Perches
  0 siblings, 1 reply; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-20 23:28 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, David Howells
  Cc: linux-afs, linux-kernel, linux-hardening, Kees Cook



On 11/20/20 17:18, Joe Perches wrote:

> My preference would be to change these to break and not fallthrough;

And my preference is fallthrough.

Joe, please, let the maintainer share their opinion on this first.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-20 23:28     ` Gustavo A. R. Silva
@ 2020-11-20 23:41       ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-20 23:41 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Gustavo A. R. Silva, David Howells
  Cc: linux-afs, linux-kernel, linux-hardening, Kees Cook

On Fri, 2020-11-20 at 17:28 -0600, Gustavo A. R. Silva wrote:
> On 11/20/20 17:18, Joe Perches wrote:
> 
> > My preference would be to change these to break and not fallthrough;
> 
> And my preference is fallthrough.

If so, that's an unusual choice here as it seems most or all of
the other patches you submitted use break in the same situation
where the next case is a single line break;

see: patches 2, 3, 4, 8, 9, etc...

> Joe, please, let the maintainer share their opinion on this first.

Why?
My preferences are my preferences and I don't mind announcing them.


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 068/141] ALSA: sb: Fix fall-through warnings for Clang
  2020-11-20 18:34   ` Gustavo A. R. Silva
@ 2020-11-21  8:29     ` Takashi Iwai
  -1 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:29 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel, linux-hardening

On Fri, 20 Nov 2020 19:34:12 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 068/141] ALSA: sb: Fix fall-through warnings for Clang
@ 2020-11-21  8:29     ` Takashi Iwai
  0 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:29 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, linux-hardening, Takashi Iwai

On Fri, 20 Nov 2020 19:34:12 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
  2020-11-20 18:33   ` Gustavo A. R. Silva
@ 2020-11-21  8:30     ` Takashi Iwai
  -1 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:30 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel, linux-hardening

On Fri, 20 Nov 2020 19:33:52 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
@ 2020-11-21  8:30     ` Takashi Iwai
  0 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:30 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, linux-hardening, Takashi Iwai

On Fri, 20 Nov 2020 19:33:52 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 067/141] ALSA: pcsp: Fix fall-through warnings for Clang
  2020-11-20 18:34   ` Gustavo A. R. Silva
@ 2020-11-21  8:30     ` Takashi Iwai
  -1 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:30 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel, linux-hardening

On Fri, 20 Nov 2020 19:34:01 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 067/141] ALSA: pcsp: Fix fall-through warnings for Clang
@ 2020-11-21  8:30     ` Takashi Iwai
  0 siblings, 0 replies; 1306+ messages in thread
From: Takashi Iwai @ 2020-11-21  8:30 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, linux-hardening, Takashi Iwai

On Fri, 20 Nov 2020 19:34:01 +0100,
Gustavo A. R. Silva wrote:
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied.


Takashi

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 060/141] habanalabs: Fix fall-through warnings for Clang
  2020-11-20 18:33 ` [PATCH 060/141] habanalabs: " Gustavo A. R. Silva
@ 2020-11-21 12:34   ` Oded Gabbay
  2020-11-23 22:54     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Oded Gabbay @ 2020-11-21 12:34 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Arnd Bergmann, Greg Kroah-Hartman,
	Linux-Kernel@Vger. Kernel. Org, linux-hardening

On Fri, Nov 20, 2020 at 8:33 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a fallthrough pseudo-keyword instead of letting the
> code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/misc/habanalabs/gaudi/gaudi.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c b/drivers/misc/habanalabs/gaudi/gaudi.c
> index 2519a34e25b7..eab4c0dc65c5 100644
> --- a/drivers/misc/habanalabs/gaudi/gaudi.c
> +++ b/drivers/misc/habanalabs/gaudi/gaudi.c
> @@ -5436,6 +5436,7 @@ static void gaudi_handle_ecc_event(struct hl_device *hdev, u16 event_type,
>                 params.num_memories = 33;
>                 params.derr = true;
>                 params.disable_clock_gating = true;
> +               fallthrough;
>         default:
>                 return;
>         }
> --
> 2.27.0
>
Hi Gustavo,
So this is actually an error in the code, there shouldn't be a
fallthrough there.
So NAK for this patch, I'll have to send a fix for that.
Thanks for catching this :)

Oded

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 072/141] can: peak_usb: Fix fall-through warnings for Clang
  2020-11-20 18:34 ` [PATCH 072/141] can: peak_usb: " Gustavo A. R. Silva
@ 2020-11-21 13:17   ` Marc Kleine-Budde
  2020-11-21 19:50     ` Joe Perches
  0 siblings, 1 reply; 1306+ messages in thread
From: Marc Kleine-Budde @ 2020-11-21 13:17 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Wolfgang Grandegger, David S. Miller,
	Jakub Kicinski
  Cc: linux-can, netdev, linux-kernel, linux-hardening


[-- Attachment #1.1: Type: text/plain, Size: 2372 bytes --]

On 11/20/20 7:34 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index c2764799f9ef..fd65a155be3b 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -299,6 +299,8 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
>  		if (net_ratelimit())
>  			netdev_err(netdev, "Tx urb aborted (%d)\n",
>  				   urb->status);
> +		break;
> +
>  	case -EPROTO:
>  	case -ENOENT:
>  	case -ECONNRESET:
> 

What about moving the default to the end if the case, which is more common anyways:

diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 204ccb27d6d9..e8977dd10902 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -295,16 +295,16 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
                netif_trans_update(netdev);
                break;
 
-       default:
-               if (net_ratelimit())
-                       netdev_err(netdev, "Tx urb aborted (%d)\n",
-                                  urb->status);
        case -EPROTO:
        case -ENOENT:
        case -ECONNRESET:
        case -ESHUTDOWN:
-
                break;
+
+       default:
+               if (net_ratelimit())
+                       netdev_err(netdev, "Tx urb aborted (%d)\n",
+                                  urb->status);
        }
 
        /* should always release echo skb and corresponding context */


Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 090/141] iio: adc: cpcap: Fix fall-through warnings for Clang
  2020-11-20 18:36 ` [PATCH 090/141] iio: adc: cpcap: " Gustavo A. R. Silva
@ 2020-11-21 15:05   ` Jonathan Cameron
  2020-11-23 22:59     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jonathan Cameron @ 2020-11-21 15:05 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Lars-Peter Clausen, Peter Meerwald-Stadler, linux-iio,
	linux-kernel, linux-hardening

On Fri, 20 Nov 2020 12:36:26 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> wrote:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Hi Gustavo,

I'm assuming there is no 'huge' rush for these an intent is that they will
filter through the various subsystems.  Hence I've queued it up for the
next merge window.

Applied to the togreg branch of iio.git

Thanks,

Jonathan

> ---
>  drivers/iio/adc/cpcap-adc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/adc/cpcap-adc.c b/drivers/iio/adc/cpcap-adc.c
> index 64c3cc382311..f19c9aa93f17 100644
> --- a/drivers/iio/adc/cpcap-adc.c
> +++ b/drivers/iio/adc/cpcap-adc.c
> @@ -557,6 +557,7 @@ static void cpcap_adc_setup_bank(struct cpcap_adc *ddata,
>  		break;
>  	case CPCAP_ADC_BATTP_PI16 ... CPCAP_ADC_BATTI_PI17:
>  		value1 |= CPCAP_BIT_RAND1;
> +		break;
>  	default:
>  		break;
>  	}


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 057/141] watchdog: Fix fall-through warnings for Clang
  2020-11-20 18:32 ` [PATCH 057/141] watchdog: " Gustavo A. R. Silva
@ 2020-11-21 18:49   ` Guenter Roeck
  2020-11-23 22:50     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Guenter Roeck @ 2020-11-21 18:49 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Wim Van Sebroeck, linux-watchdog, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:32:51PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a fallthrough pseudo-keyword instead of letting the
> code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/watchdog/machzwd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/watchdog/machzwd.c b/drivers/watchdog/machzwd.c
> index 743377c5b173..73f2221f6222 100644
> --- a/drivers/watchdog/machzwd.c
> +++ b/drivers/watchdog/machzwd.c
> @@ -174,6 +174,7 @@ static inline void zf_set_timer(unsigned short new, unsigned char n)
>  		fallthrough;
>  	case WD2:
>  		zf_writeb(COUNTER_2, new > 0xff ? 0xff : new);
> +		fallthrough;

fallthrough to return ? Oh well, this is an old style driver anyway,
so I guess who cares.

Acked-by: Guenter Roeck <linux@roeck-us.net>

Guenter

>  	default:
>  		return;
>  	}
> -- 
> 2.27.0
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 086/141] hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  2020-11-20 18:36 ` [PATCH 086/141] hwmon: (corsair-cpro) " Gustavo A. R. Silva
@ 2020-11-21 18:50   ` Guenter Roeck
  2020-11-21 20:00     ` Joe Perches
  2020-11-24 14:35     ` Gustavo A. R. Silva
  0 siblings, 2 replies; 1306+ messages in thread
From: Guenter Roeck @ 2020-11-21 18:50 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Marius Zachmann, Jean Delvare, linux-hwmon, linux-kernel,
	linux-hardening

On Fri, Nov 20, 2020 at 12:36:04PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Acked-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  drivers/hwmon/corsair-cpro.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
> index 591929ec217a..fa6aa4fc8b52 100644
> --- a/drivers/hwmon/corsair-cpro.c
> +++ b/drivers/hwmon/corsair-cpro.c
> @@ -310,6 +310,7 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
>  		default:
>  			break;
>  		}
> +		break;
>  	default:
>  		break;
>  	}
> -- 
> 2.27.0
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 087/141] hwmon: (max6621) Fix fall-through warnings for Clang
  2020-11-20 18:36 ` [PATCH 087/141] hwmon: (max6621) " Gustavo A. R. Silva
@ 2020-11-21 18:50   ` Guenter Roeck
  0 siblings, 0 replies; 1306+ messages in thread
From: Guenter Roeck @ 2020-11-21 18:50 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jean Delvare, linux-hwmon, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:36:09PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Acked-by: Guenter Roeck <linux@roeck-us.net>

> ---
>  drivers/hwmon/max6621.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/max6621.c b/drivers/hwmon/max6621.c
> index 367855d5edae..7821132e17fa 100644
> --- a/drivers/hwmon/max6621.c
> +++ b/drivers/hwmon/max6621.c
> @@ -156,7 +156,7 @@ max6621_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
>  		default:
>  			break;
>  		}
> -
> +		break;
>  	default:
>  		break;
>  	}
> -- 
> 2.27.0
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 072/141] can: peak_usb: Fix fall-through warnings for Clang
  2020-11-21 13:17   ` Marc Kleine-Budde
@ 2020-11-21 19:50     ` Joe Perches
  2020-11-21 23:04       ` Marc Kleine-Budde
  0 siblings, 1 reply; 1306+ messages in thread
From: Joe Perches @ 2020-11-21 19:50 UTC (permalink / raw)
  To: Marc Kleine-Budde, Gustavo A. R. Silva, Wolfgang Grandegger,
	David S. Miller, Jakub Kicinski
  Cc: linux-can, netdev, linux-kernel, linux-hardening

On Sat, 2020-11-21 at 14:17 +0100, Marc Kleine-Budde wrote:
> On 11/20/20 7:34 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
[]
> > diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
[]
> > @@ -299,6 +299,8 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
> >  		if (net_ratelimit())
> >  			netdev_err(netdev, "Tx urb aborted (%d)\n",
> >  				   urb->status);
> > +		break;
> > +
> >  	case -EPROTO:
> >  	case -ENOENT:
> >  	case -ECONNRESET:
> > 
> 
> What about moving the default to the end if the case, which is more common anyways:
> 
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
[]
> @@ -295,16 +295,16 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
>                 netif_trans_update(netdev);
>                 break;
>  
> 
> -       default:
> -               if (net_ratelimit())
> -                       netdev_err(netdev, "Tx urb aborted (%d)\n",
> -                                  urb->status);
>         case -EPROTO:
>         case -ENOENT:
>         case -ECONNRESET:
>         case -ESHUTDOWN:
> -
>                 break;
> +
> +       default:
> +               if (net_ratelimit())
> +                       netdev_err(netdev, "Tx urb aborted (%d)\n",
> +                                  urb->status);

That's fine and is more generally used style but this
default: case should IMO also end with a break;

+		break;

>         }



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 086/141] hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  2020-11-21 18:50   ` Guenter Roeck
@ 2020-11-21 20:00     ` Joe Perches
  2020-11-22  0:58       ` Guenter Roeck
  2020-11-24 14:35     ` Gustavo A. R. Silva
  1 sibling, 1 reply; 1306+ messages in thread
From: Joe Perches @ 2020-11-21 20:00 UTC (permalink / raw)
  To: Guenter Roeck, Gustavo A. R. Silva
  Cc: Marius Zachmann, Jean Delvare, linux-hwmon, linux-kernel,
	linux-hardening

On Sat, 2020-11-21 at 10:50 -0800, Guenter Roeck wrote:
> On Fri, Nov 20, 2020 at 12:36:04PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>
[]
> > diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
[]
> > @@ -310,6 +310,7 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
> >  		default:
> >  			break;
> >  		}
> > +		break;

The
		default:
			break;

bit above (but not below as it's a switch on an enum) could also be deleted no?

> >  	default:
> >  		break;
> >  	}

---
 drivers/hwmon/corsair-cpro.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
index 591929ec217a..580173fca0f6 100644
--- a/drivers/hwmon/corsair-cpro.c
+++ b/drivers/hwmon/corsair-cpro.c
@@ -299,17 +299,14 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
 		switch (attr) {
 		case hwmon_pwm_input:
 			return set_pwm(ccp, channel, val);
-		default:
-			break;
 		}
 		break;
 	case hwmon_fan:
 		switch (attr) {
 		case hwmon_fan_target:
 			return set_target(ccp, channel, val);
-		default:
-			break;
 		}
+		break;
 	default:
 		break;
 	}



^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 072/141] can: peak_usb: Fix fall-through warnings for Clang
  2020-11-21 19:50     ` Joe Perches
@ 2020-11-21 23:04       ` Marc Kleine-Budde
  2020-11-22  2:46         ` Joe Perches
  0 siblings, 1 reply; 1306+ messages in thread
From: Marc Kleine-Budde @ 2020-11-21 23:04 UTC (permalink / raw)
  To: Joe Perches, Gustavo A. R. Silva, Wolfgang Grandegger,
	David S. Miller, Jakub Kicinski
  Cc: linux-can, netdev, linux-kernel, linux-hardening


[-- Attachment #1.1: Type: text/plain, Size: 1580 bytes --]

On 11/21/20 8:50 PM, Joe Perches wrote:
>> What about moving the default to the end if the case, which is more common anyways:
>>
>> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> []
>> @@ -295,16 +295,16 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
>>                 netif_trans_update(netdev);
>>                 break;
>>  
>>
>> -       default:
>> -               if (net_ratelimit())
>> -                       netdev_err(netdev, "Tx urb aborted (%d)\n",
>> -                                  urb->status);
>>         case -EPROTO:
>>         case -ENOENT:
>>         case -ECONNRESET:
>>         case -ESHUTDOWN:
>> -
>>                 break;
>> +
>> +       default:
>> +               if (net_ratelimit())
>> +                       netdev_err(netdev, "Tx urb aborted (%d)\n",
>> +                                  urb->status);
> 
> That's fine and is more generally used style but this
> default: case should IMO also end with a break;
> 
> +		break;

I don't mind.

process/coding-style.rst is not totally clear about the break after the default,
if this is the lase one the switch statement.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 086/141] hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  2020-11-21 20:00     ` Joe Perches
@ 2020-11-22  0:58       ` Guenter Roeck
  0 siblings, 0 replies; 1306+ messages in thread
From: Guenter Roeck @ 2020-11-22  0:58 UTC (permalink / raw)
  To: Joe Perches
  Cc: Gustavo A. R. Silva, Marius Zachmann, Jean Delvare, linux-hwmon,
	linux-kernel, linux-hardening

On Sat, Nov 21, 2020 at 12:00:30PM -0800, Joe Perches wrote:
> On Sat, 2020-11-21 at 10:50 -0800, Guenter Roeck wrote:
> > On Fri, Nov 20, 2020 at 12:36:04PM -0600, Gustavo A. R. Silva wrote:
> > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > > by explicitly adding a break statement instead of letting the code fall
> > > through to the next case.
> > > 
> > > Link: https://github.com/KSPP/linux/issues/115
> > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > 
> > Acked-by: Guenter Roeck <linux@roeck-us.net>
> []
> > > diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
> []
> > > @@ -310,6 +310,7 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
> > >  		default:
> > >  			break;
> > >  		}
> > > +		break;
> 
> The
> 		default:
> 			break;
> 
> bit above (but not below as it's a switch on an enum) could also be deleted no?
> 

I prefer to keep it the way it is to indicate that the default case was not
forgotten (unless that is against coding style).

Guenter

> > >  	default:
> > >  		break;
> > >  	}
> 
> ---
>  drivers/hwmon/corsair-cpro.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/corsair-cpro.c b/drivers/hwmon/corsair-cpro.c
> index 591929ec217a..580173fca0f6 100644
> --- a/drivers/hwmon/corsair-cpro.c
> +++ b/drivers/hwmon/corsair-cpro.c
> @@ -299,17 +299,14 @@ static int ccp_write(struct device *dev, enum hwmon_sensor_types type,
>  		switch (attr) {
>  		case hwmon_pwm_input:
>  			return set_pwm(ccp, channel, val);
> -		default:
> -			break;
>  		}
>  		break;
>  	case hwmon_fan:
>  		switch (attr) {
>  		case hwmon_fan_target:
>  			return set_target(ccp, channel, val);
> -		default:
> -			break;
>  		}
> +		break;
>  	default:
>  		break;
>  	}
> 
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 072/141] can: peak_usb: Fix fall-through warnings for Clang
  2020-11-21 23:04       ` Marc Kleine-Budde
@ 2020-11-22  2:46         ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22  2:46 UTC (permalink / raw)
  To: Marc Kleine-Budde, Gustavo A. R. Silva, Wolfgang Grandegger,
	David S. Miller, Jakub Kicinski
  Cc: linux-can, netdev, linux-kernel, linux-hardening

On Sun, 2020-11-22 at 00:04 +0100, Marc Kleine-Budde wrote:
> On 11/21/20 8:50 PM, Joe Perches wrote:
> > > What about moving the default to the end if the case, which is more common anyways:
> > > 
> > > diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> > []
> > > @@ -295,16 +295,16 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
> > >                 netif_trans_update(netdev);
> > >                 break;
> > >  
> > > 
> > > -       default:
> > > -               if (net_ratelimit())
> > > -                       netdev_err(netdev, "Tx urb aborted (%d)\n",
> > > -                                  urb->status);
> > >         case -EPROTO:
> > >         case -ENOENT:
> > >         case -ECONNRESET:
> > >         case -ESHUTDOWN:
> > > -
> > >                 break;
> > > +
> > > +       default:
> > > +               if (net_ratelimit())
> > > +                       netdev_err(netdev, "Tx urb aborted (%d)\n",
> > > +                                  urb->status);
> > 
> > That's fine and is more generally used style but this
> > default: case should IMO also end with a break;
> > 
> > +		break;
> 
> I don't mind.
> 
> process/coding-style.rst is not totally clear about the break after the default,
> if this is the lase one the switch statement.

deprecated.rst has:

All switch/case blocks must end in one of:

* break;
* fallthrough;
* continue;
* goto <label>;
* return [expression];

I suppose that could be moved into coding-style along with
maybe a change to "all switch/case/default blocks"


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 075/141] crypto: ccree - Fix fall-through warnings for Clang
  2020-11-20 18:34 ` [PATCH 075/141] crypto: ccree - " Gustavo A. R. Silva
@ 2020-11-22  7:54   ` Gilad Ben-Yossef
  2020-11-23 22:57     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Gilad Ben-Yossef @ 2020-11-22  7:54 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Herbert Xu, David S. Miller, Linux Crypto Mailing List,
	Linux kernel mailing list, linux-hardening

On Fri, Nov 20, 2020 at 8:34 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/crypto/ccree/cc_cipher.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
> index dafa6577a845..cdfee501fbd9 100644
> --- a/drivers/crypto/ccree/cc_cipher.c
> +++ b/drivers/crypto/ccree/cc_cipher.c
> @@ -97,6 +97,7 @@ static int validate_keys_sizes(struct cc_cipher_ctx *ctx_p, u32 size)
>         case S_DIN_to_SM4:
>                 if (size == SM4_KEY_SIZE)
>                         return 0;
> +               break;
>         default:
>                 break;
>         }
> @@ -139,9 +140,11 @@ static int validate_data_size(struct cc_cipher_ctx *ctx_p,
>                 case DRV_CIPHER_CBC:
>                         if (IS_ALIGNED(size, SM4_BLOCK_SIZE))
>                                 return 0;
> +                       break;
>                 default:
>                         break;
>                 }
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>

Acked-by: Gilad Ben-Yossef <gilad@benyossef.com>

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 044/141] net/mlx4: Fix fall-through warnings for Clang
  2020-11-20 18:31 ` [PATCH 044/141] net/mlx4: " Gustavo A. R. Silva
@ 2020-11-22  8:36   ` Tariq Toukan
  2020-11-23 22:49     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Tariq Toukan @ 2020-11-22  8:36 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Tariq Toukan, David S. Miller, Jakub Kicinski
  Cc: netdev, linux-rdma, linux-kernel, linux-hardening



On 11/20/2020 8:31 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of just letting the code
> fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>   drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> index 1187ef1375e2..e6b8b8dc7894 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> @@ -2660,6 +2660,7 @@ int mlx4_FREE_RES_wrapper(struct mlx4_dev *dev, int slave,
>   	case RES_XRCD:
>   		err = xrcdn_free_res(dev, slave, vhcr->op_modifier, alop,
>   				     vhcr->in_param, &vhcr->out_param);
> +		break;
>   
>   	default:
>   		break;
> 

Reviewed-by: Tariq Toukan <tariqt@nvidia.com>

Thanks for your patch.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 061/141] tee: Fix fall-through warnings for Clang
  2020-11-20 18:33 ` [PATCH 061/141] tee: " Gustavo A. R. Silva
@ 2020-11-22  9:26   ` Jens Wiklander
  2020-11-23 22:55     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jens Wiklander @ 2020-11-22  9:26 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: op-tee, Linux Kernel Mailing List, linux-hardening

On Fri, Nov 20, 2020 at 7:33 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/tee/tee_core.c | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

Thanks,
Jens

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 008/141] IB/hfi1: Fix fall-through warnings for Clang
  2020-11-20 18:25 ` [PATCH 008/141] IB/hfi1: " Gustavo A. R. Silva
@ 2020-11-22 14:30   ` Mike Marciniszyn
  2020-11-23 22:44     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Mike Marciniszyn @ 2020-11-22 14:30 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Dennis Dalessandro, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening


On 11/20/2020 1:25 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of just
> letting the code fall through to the next case.
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Looks good and tested with TID rdma to cover the interlock case.

Mike

Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 19:51       ` Jakub Kicinski
                           ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 16:17         ` Kees Cook
  -1 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/

-- 
Kees Cook



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 16:17         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-22 16:17 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > This series aims to fix almost all remaining fall-through warnings in
> > > > order to enable -Wimplicit-fallthrough for Clang.
> > > > 
> > > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > > > add multiple break/goto/return/fallthrough statements instead of just
> > > > letting the code fall through to the next case.
> > > > 
> > > > Notice that in order to enable -Wimplicit-fallthrough for Clang, this
> > > > change[1] is meant to be reverted at some point. So, this patch helps
> > > > to move in that direction.
> > > > 
> > > > Something important to mention is that there is currently a discrepancy
> > > > between GCC and Clang when dealing with switch fall-through to empty case
> > > > statements or to cases that only contain a break/continue/return
> > > > statement[2][3][4].  
> > > 
> > > Are we sure we want to make this change? Was it discussed before?
> > > 
> > > Are there any bugs Clangs puritanical definition of fallthrough helped
> > > find?
> > > 
> > > IMVHO compiler warnings are supposed to warn about issues that could
> > > be bugs. Falling through to default: break; can hardly be a bug?!  
> > 
> > It's certainly a place where the intent is not always clear. I think
> > this makes all the cases unambiguous, and doesn't impact the machine
> > code, since the compiler will happily optimize away any behavioral
> > redundancy.
> 
> If none of the 140 patches here fix a real bug, and there is no change
> to machine code then it sounds to me like a W=2 kind of a warning.

FWIW, this series has found at least one bug so far:
https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 013/141] media: dvb-frontends: Fix fall-through warnings for Clang
  2020-11-20 18:26 ` [PATCH 013/141] media: dvb-frontends: " Gustavo A. R. Silva
@ 2020-11-22 16:31   ` Mauro Carvalho Chehab
  2020-11-23 22:44     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Jemma Denson, Patrick Boettcher, Malcolm Priestley, linux-media,
	linux-kernel, linux-hardening

Em Fri, 20 Nov 2020 12:26:09 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break and a return statements
> instead of just letting the code fall through to the next case.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/media/dvb-frontends/cx24120.c   | 1 +
>  drivers/media/dvb-frontends/dib0090.c   | 2 ++
>  drivers/media/dvb-frontends/drxk_hard.c | 1 +
>  drivers/media/dvb-frontends/m88rs2000.c | 1 +
>  4 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/dvb-frontends/cx24120.c b/drivers/media/dvb-frontends/cx24120.c
> index 2464b63fe0cf..d8acd582c711 100644
> --- a/drivers/media/dvb-frontends/cx24120.c
> +++ b/drivers/media/dvb-frontends/cx24120.c
> @@ -363,6 +363,7 @@ static void cx24120_check_cmd(struct cx24120_state *state, u8 id)
>  	case CMD_DISEQC_BURST:
>  		cx24120_msg_mpeg_output_global_config(state, 0);
>  		/* Old driver would do a msleep(100) here */
> +		return;
>  	default:
>  		return;
>  	}
> diff --git a/drivers/media/dvb-frontends/dib0090.c b/drivers/media/dvb-frontends/dib0090.c
> index 08a85831e917..903da33642df 100644
> --- a/drivers/media/dvb-frontends/dib0090.c
> +++ b/drivers/media/dvb-frontends/dib0090.c
> @@ -1765,6 +1765,8 @@ static int dib0090_dc_offset_calibration(struct dib0090_state *state, enum front
>  		dib0090_write_reg(state, 0x1f, 0x7);
>  		*tune_state = CT_TUNER_START;	/* reset done -> real tuning can now begin */
>  		state->calibrate &= ~DC_CAL;
> +		break;
> +
>  	default:
>  		break;
>  	}
> diff --git a/drivers/media/dvb-frontends/drxk_hard.c b/drivers/media/dvb-frontends/drxk_hard.c
> index a57470bf71bf..d7fc2595f15b 100644
> --- a/drivers/media/dvb-frontends/drxk_hard.c
> +++ b/drivers/media/dvb-frontends/drxk_hard.c
> @@ -3294,6 +3294,7 @@ static int dvbt_sc_command(struct drxk_state *state,
>  	case OFDM_SC_RA_RAM_CMD_USER_IO:
>  	case OFDM_SC_RA_RAM_CMD_GET_OP_PARAM:
>  		status = read16(state, OFDM_SC_RA_RAM_PARAM0__A, &(param0));
> +		break;
>  		/* All commands yielding 0 results */
>  	case OFDM_SC_RA_RAM_CMD_SET_ECHO_TIMING:
>  	case OFDM_SC_RA_RAM_CMD_SET_TIMER:
> diff --git a/drivers/media/dvb-frontends/m88rs2000.c b/drivers/media/dvb-frontends/m88rs2000.c
> index 39cbb3ea1c9d..b294ba87e934 100644
> --- a/drivers/media/dvb-frontends/m88rs2000.c
> +++ b/drivers/media/dvb-frontends/m88rs2000.c
> @@ -390,6 +390,7 @@ static int m88rs2000_tab_set(struct m88rs2000_state *state,
>  		case 0xff:
>  			if (tab[i].reg == 0xaa && tab[i].val == 0xff)
>  				return 0;
> +			break;
>  		case 0x00:
>  			break;
>  		default:



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 014/141] media: usb: dvb-usb-v2: Fix fall-through warnings for Clang
  2020-11-20 18:26 ` [PATCH 014/141] media: usb: dvb-usb-v2: " Gustavo A. R. Silva
@ 2020-11-22 16:31   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Antti Palosaari, Malcolm Priestley, linux-media, linux-kernel,
	linux-hardening

Em Fri, 20 Nov 2020 12:26:16 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding a couple of break statements instead of
> just letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/media/usb/dvb-usb-v2/af9015.c  | 1 +
>  drivers/media/usb/dvb-usb-v2/lmedm04.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c b/drivers/media/usb/dvb-usb-v2/af9015.c
> index c70b3cef3176..d33514acc2b5 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9015.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9015.c
> @@ -51,6 +51,7 @@ static int af9015_ctrl_msg(struct dvb_usb_device *d, struct req_t *req)
>  		if (((req->addr & 0xff00) == 0xff00) ||
>  		    ((req->addr & 0xff00) == 0xae00))
>  			state->buf[0] = WRITE_VIRTUAL_MEMORY;
> +		break;
>  	case WRITE_VIRTUAL_MEMORY:
>  	case COPY_FIRMWARE:
>  	case DOWNLOAD_FIRMWARE:
> diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> index 5a7a9522d46d..67c37fb267e3 100644
> --- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
> +++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
> @@ -336,6 +336,7 @@ static void lme2510_int_response(struct urb *lme_urb)
>  				st->signal_level = ibuf[5];
>  				st->signal_sn = ibuf[4];
>  				st->time_key = ibuf[7];
> +				break;
>  			default:
>  				break;
>  			}



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 094/141] media: atomisp: Fix fall-through warnings for Clang
  2020-11-20 18:36   ` Gustavo A. R. Silva
@ 2020-11-22 16:32     ` Mauro Carvalho Chehab
  -1 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:32 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Sakari Ailus, Greg Kroah-Hartman, linux-media, devel,
	linux-kernel, linux-hardening

Em Fri, 20 Nov 2020 12:36:50 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> index b4813cd50daa..4a18da6bf0c1 100644
> --- a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> +++ b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> @@ -368,6 +368,7 @@ static mipi_predictor_t sh_css_csi2_compression_type_2_mipi_predictor(
>  		break;
>  	case IA_CSS_CSI2_COMPRESSION_TYPE_2:
>  		predictor = MIPI_PREDICTOR_TYPE2 - 1;
> +		break;
>  	default:
>  		break;
>  	}



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 094/141] media: atomisp: Fix fall-through warnings for Clang
@ 2020-11-22 16:32     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:32 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: devel, Greg Kroah-Hartman, linux-kernel, linux-hardening,
	Sakari Ailus, linux-media

Em Fri, 20 Nov 2020 12:36:50 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> index b4813cd50daa..4a18da6bf0c1 100644
> --- a/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> +++ b/drivers/staging/media/atomisp/pci/runtime/isys/src/rx.c
> @@ -368,6 +368,7 @@ static mipi_predictor_t sh_css_csi2_compression_type_2_mipi_predictor(
>  		break;
>  	case IA_CSS_CSI2_COMPRESSION_TYPE_2:
>  		predictor = MIPI_PREDICTOR_TYPE2 - 1;
> +		break;
>  	default:
>  		break;
>  	}



Thanks,
Mauro
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 095/141] media: dvb_frontend: Fix fall-through warnings for Clang
  2020-11-20 18:36 ` [PATCH 095/141] media: dvb_frontend: " Gustavo A. R. Silva
@ 2020-11-22 16:32   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:32 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: linux-media, linux-kernel, linux-hardening

Em Fri, 20 Nov 2020 12:36:57 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/media/dvb-core/dvb_frontend.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
> index 06ea30a689d7..fb35697dd93c 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -984,6 +984,7 @@ static int dvb_frontend_check_parameters(struct dvb_frontend *fe)
>  				 fe->ops.info.symbol_rate_max);
>  			return -EINVAL;
>  		}
> +		break;
>  	default:
>  		break;
>  	}



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 097/141] media: saa7134: Fix fall-through warnings for Clang
  2020-11-20 18:37 ` [PATCH 097/141] media: saa7134: " Gustavo A. R. Silva
@ 2020-11-22 16:32   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:32 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: linux-media, linux-kernel, linux-hardening

Em Fri, 20 Nov 2020 12:37:08 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/pci/saa7134/saa7134-tvaudio.c b/drivers/media/pci/saa7134/saa7134-tvaudio.c
> index 5cc4ef21f9d3..5dc97990fa0e 100644
> --- a/drivers/media/pci/saa7134/saa7134-tvaudio.c
> +++ b/drivers/media/pci/saa7134/saa7134-tvaudio.c
> @@ -885,6 +885,7 @@ void saa7134_enable_i2s(struct saa7134_dev *dev)
>  	    saa_writeb(SAA7134_I2S_OUTPUT_FORMAT, i2s_format);
>  	    saa_writeb(SAA7134_I2S_OUTPUT_LEVEL,  0x0F);
>  	    saa_writeb(SAA7134_I2S_AUDIO_OUTPUT,  0x01);
> +	    break;
>  
>  	default:
>  	    break;



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 096/141] media: rcar_jpu: Fix fall-through warnings for Clang
  2020-11-20 18:37 ` [PATCH 096/141] media: rcar_jpu: " Gustavo A. R. Silva
@ 2020-11-22 16:33   ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 1306+ messages in thread
From: Mauro Carvalho Chehab @ 2020-11-22 16:33 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Mikhail Ulyanov, linux-media, linux-kernel, linux-hardening

Em Fri, 20 Nov 2020 12:37:02 -0600
"Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

> ---
>  drivers/media/platform/rcar_jpu.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/rcar_jpu.c b/drivers/media/platform/rcar_jpu.c
> index 9b99ff368698..87466edf8a5e 100644
> --- a/drivers/media/platform/rcar_jpu.c
> +++ b/drivers/media/platform/rcar_jpu.c
> @@ -648,6 +648,7 @@ static u8 jpu_parse_hdr(void *buffer, unsigned long size, unsigned int *width,
>  			if (get_word_be(&jpeg_buffer, &word))
>  				return 0;
>  			skip(&jpeg_buffer, (long)word - 2);
> +			break;
>  		case 0:
>  			break;
>  		default:



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 16:17         ` Kees Cook
                             ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 18:21           ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:21           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 18:21 UTC (permalink / raw)
  To: Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:  
> > > > > This series aims to fix almost all remaining fall-through
> > > > > warnings in order to enable -Wimplicit-fallthrough for Clang.
> > > > > 
> > > > > In preparation to enable -Wimplicit-fallthrough for Clang,
> > > > > explicitly add multiple break/goto/return/fallthrough
> > > > > statements instead of just letting the code fall through to
> > > > > the next case.
> > > > > 
> > > > > Notice that in order to enable -Wimplicit-fallthrough for
> > > > > Clang, this change[1] is meant to be reverted at some point.
> > > > > So, this patch helps to move in that direction.
> > > > > 
> > > > > Something important to mention is that there is currently a
> > > > > discrepancy between GCC and Clang when dealing with switch
> > > > > fall-through to empty case statements or to cases that only
> > > > > contain a break/continue/return statement[2][3][4].  
> > > > 
> > > > Are we sure we want to make this change? Was it discussed
> > > > before?
> > > > 
> > > > Are there any bugs Clangs puritanical definition of fallthrough
> > > > helped find?
> > > > 
> > > > IMVHO compiler warnings are supposed to warn about issues that
> > > > could be bugs. Falling through to default: break; can hardly be
> > > > a bug?!  
> > > 
> > > It's certainly a place where the intent is not always clear. I
> > > think this makes all the cases unambiguous, and doesn't impact
> > > the machine code, since the compiler will happily optimize away
> > > any behavioral redundancy.
> > 
> > If none of the 140 patches here fix a real bug, and there is no
> > change to machine code then it sounds to me like a W=2 kind of a
> > warning.
> 
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/


Well, it's a problem in an error leg, sure, but it's not a really
compelling reason for a 141 patch series, is it?  All that fixing this
error will do is get the driver to print "oh dear there's a problem"
under four more conditions than it previously did.

We've been at this for three years now with nearly a thousand patches,
firstly marking all the fall throughs with /* fall through */ and later
changing it to fallthrough.  At some point we do have to ask if the
effort is commensurate with the protection afforded.  Please tell me
our reward for all this effort isn't a single missing error print.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 18:21           ` James Bottomley
                               ` (12 preceding siblings ...)
  (?)
@ 2020-11-22 18:25             ` Joe Perches
  -1 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.



_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 18:25             ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 18:25 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.

There were quite literally dozens of logical defects found
by the fallthrough additions.  Very few were logging only.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 18:25             ` Joe Perches
                                 ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 19:12               ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:12               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:12 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
> 
> There were quite literally dozens of logical defects found
> by the fallthrough additions.  Very few were logging only.

So can you give us the best examples (or indeed all of them if someone
is keeping score)?  hopefully this isn't a US election situation ...

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 19:12               ` James Bottomley
                                   ` (12 preceding siblings ...)
  (?)
@ 2020-11-22 19:22                 ` Joe Perches
  -1 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:22                 ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-22 19:22 UTC (permalink / raw)
  To: James Bottomley, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> > 
> > There were quite literally dozens of logical defects found
> > by the fallthrough additions.  Very few were logging only.
> 
> So can you give us the best examples (or indeed all of them if someone
> is keeping score)?  hopefully this isn't a US election situation ...

Gustavo?  Are you running for congress now?

https://lwn.net/Articles/794944/



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 19:22                 ` Joe Perches
                                     ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 19:53                   ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, target-devel, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	linux-mmc, Gustavo A. R. Silva, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches,
	linux-integrity, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 19:53                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 19:53 UTC (permalink / raw)
  To: Joe Perches, Kees Cook, Jakub Kicinski
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a single
> > > > missing error print.
> > > 
> > > There were quite literally dozens of logical defects found
> > > by the fallthrough additions.  Very few were logging only.
> > 
> > So can you give us the best examples (or indeed all of them if
> > someone is keeping score)?  hopefully this isn't a US election
> > situation ...
> 
> Gustavo?  Are you running for congress now?
> 
> https://lwn.net/Articles/794944/

That's 21 reported fixes of which about 50% seem to produce no change
in code behaviour at all, a quarter seem to have no user visible effect
with the remaining quarter producing unexpected errors on obscure
configuration parameters, which is why no-one really noticed them
before.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* RE: [EXT] [PATCH 035/141] IB/qedr: Fix fall-through warnings for Clang
  2020-11-20 18:28 ` [PATCH 035/141] IB/qedr: " Gustavo A. R. Silva
@ 2020-11-22 20:12   ` Michal Kalderon
  2020-11-23 22:48     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Michal Kalderon @ 2020-11-22 20:12 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Ariel Elior, Doug Ledford, Jason Gunthorpe
  Cc: linux-rdma, linux-kernel, linux-hardening

> From: Gustavo A. R. Silva <gustavoars@kernel.org>
> Sent: Friday, November 20, 2020 8:29 PM
> 
> ----------------------------------------------------------------------
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by
> explicitly adding a break statement instead of just letting the code fall
> through to the next case.
> 
> Link: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_KSPP_linux_issues_115&d=DwIBAg&c=nKjWec2b6R0mOyP
> az7xtfQ&r=5_8rRZTDuAS-6X-cGRU9Fo4yjCnkS1t7T3-
> gjL4FQng&m=ZJjyam8OGRTmM8iCzOSDOL7dMn31Pmw3aA-
> QOVDY8eg&s=4rQYW1K3xAzeRV7SRkrvaivRWz2WwEuuk0ZnjnDTA1w&e=
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/infiniband/hw/qedr/main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/infiniband/hw/qedr/main.c
> b/drivers/infiniband/hw/qedr/main.c
> index 967641662b24..10707b451ab8 100644
> --- a/drivers/infiniband/hw/qedr/main.c
> +++ b/drivers/infiniband/hw/qedr/main.c
> @@ -796,6 +796,7 @@ static void qedr_affiliated_event(void *context, u8
> e_code, void *fw_handle)
>  		}
>  		xa_unlock_irqrestore(&dev->srqs, flags);
>  		DP_NOTICE(dev, "SRQ event %d on handle %p\n", e_code,
> srq);
> +		break;
>  	default:
>  		break;
>  	}
> --
> 2.27.0

Thanks, 

Acked-by: Michal Kalderon <michal.kalderon@marvell.com>



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 18:21           ` James Bottomley
                               ` (12 preceding siblings ...)
  (?)
@ 2020-11-22 20:35             ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 20:35             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-22 20:35 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.
>
> We've been at this for three years now with nearly a thousand patches,
> firstly marking all the fall throughs with /* fall through */ and later
> changing it to fallthrough.  At some point we do have to ask if the
> effort is commensurate with the protection afforded.  Please tell me
> our reward for all this effort isn't a single missing error print.

It isn't that much effort, isn't it? Plus we need to take into account
the future mistakes that it might prevent, too. So even if there were
zero problems found so far, it is still a positive change.

I would agree if these changes were high risk, though; but they are
almost trivial.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 079/141] drm: Fix fall-through warnings for Clang
  2020-11-20 18:35   ` Gustavo A. R. Silva
@ 2020-11-22 22:03     ` Sam Ravnborg
  -1 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, linux-kernel, dri-devel,
	linux-hardening

Hi Gustavo,
On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

thanks, applied to drm-misc-next.

	Sam

> ---
>  drivers/gpu/drm/drm_bufs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 7a01d0918861..aeb1327e3077 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -77,6 +77,7 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
>  			if ((entry->map->offset & 0xffffffff) ==
>  			    (map->offset & 0xffffffff))
>  				return entry;
> +			break;
>  		default: /* Make gcc happy */
>  			;
>  		}
> -- 
> 2.27.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 079/141] drm: Fix fall-through warnings for Clang
@ 2020-11-22 22:03     ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Thomas Zimmermann, David Airlie, linux-kernel, dri-devel,
	linux-hardening

Hi Gustavo,
On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

thanks, applied to drm-misc-next.

	Sam

> ---
>  drivers/gpu/drm/drm_bufs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 7a01d0918861..aeb1327e3077 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -77,6 +77,7 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
>  			if ((entry->map->offset & 0xffffffff) ==
>  			    (map->offset & 0xffffffff))
>  				return entry;
> +			break;
>  		default: /* Make gcc happy */
>  			;
>  		}
> -- 
> 2.27.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
  2020-11-20 18:35   ` Gustavo A. R. Silva
@ 2020-11-22 22:03     ` Sam Ravnborg
  -1 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: David Airlie, Daniel Vetter, linux-kernel, dri-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, also applied to drm-misc-next.

	Sam

> ---
>  drivers/gpu/drm/via/via_irq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
> index 24cc445169e2..a3e0fb5b8671 100644
> --- a/drivers/gpu/drm/via/via_irq.c
> +++ b/drivers/gpu/drm/via/via_irq.c
> @@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, struct drm_file *file_priv)
>  		irqwait->request.sequence +=
>  			atomic_read(&cur_irq->irq_received);
>  		irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
> +		break;
>  	case VIA_IRQ_ABSOLUTE:
>  		break;
>  	default:
> -- 
> 2.27.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
@ 2020-11-22 22:03     ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: David Airlie, dri-devel, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, also applied to drm-misc-next.

	Sam

> ---
>  drivers/gpu/drm/via/via_irq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
> index 24cc445169e2..a3e0fb5b8671 100644
> --- a/drivers/gpu/drm/via/via_irq.c
> +++ b/drivers/gpu/drm/via/via_irq.c
> @@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, struct drm_file *file_priv)
>  		irqwait->request.sequence +=
>  			atomic_read(&cur_irq->irq_received);
>  		irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
> +		break;
>  	case VIA_IRQ_ABSOLUTE:
>  		break;
>  	default:
> -- 
> 2.27.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  2020-11-20 18:40   ` Gustavo A. R. Silva
@ 2020-11-22 22:05     ` Sam Ravnborg
  -1 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:05 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Andres Salomon, Bartlomiej Zolnierkiewicz, linux-fbdev,
	linux-kernel, dri-devel, linux-geode, linux-hardening

Hi Gustavo,
On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied this and the following patch to drm-misc-next.
Looks forward to have this warning enabled.

One can only wonder how many hours will be saved by lettting the
compiler tell you a break is missing. This is the kind of bugs you can
stare you blind at.

	Sam

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
@ 2020-11-22 22:05     ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:05 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-fbdev, Bartlomiej Zolnierkiewicz, linux-geode, dri-devel,
	linux-kernel, linux-hardening, Andres Salomon

Hi Gustavo,
On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks, applied this and the following patch to drm-misc-next.
Looks forward to have this warning enabled.

One can only wonder how many hours will be saved by lettting the
compiler tell you a break is missing. This is the kind of bugs you can
stare you blind at.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 18:21           ` James Bottomley
                               ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 22:10             ` Sam Ravnborg
  -1 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, alsa-devel, linux-atm-general,
	reiserfs-devel, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization, target-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-mmc,
	linux-fbdev, dri-devel, virtualization, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, linux-usb, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity, linux-nfs,
	x86, linux-hardening

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-mmc,
	linux-fbdev, dri-devel, virtualization, linux-mm, linux-ide,
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, linux-watchdog, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	oss-drivers, linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity, linux-usb,
	x86, linux-hardening

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-mmc,
	linux-fbdev, dri-devel, virtualization, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, linux-usb, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity, linux-nfs,
	x86, linux-hardening

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-mmc,
	linux-fbdev, dri-devel, virtualization, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, linux-usb, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity, linux-nfs,
	x86, linux-hardening

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: intel-wired-lan

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:10             ` Sam Ravnborg
  0 siblings, 0 replies; 1306+ messages in thread
From: Sam Ravnborg @ 2020-11-22 22:10 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-fbdev,
	dri-devel, virtualization, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	Gustavo A. R. Silva, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, netfilter-devel, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-watchdog,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, target-devel, tipc-discussion,
	linux-crypto, patches, Joe Perches, linux-integrity,
	linux-hardening, linux-nfs, x86, linux-usb

Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

	Sam

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 20:35             ` Miguel Ojeda
                                 ` (11 preceding siblings ...)
  (?)
@ 2020-11-22 22:36               ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, Joe Perches, linux-integrity, wcn36xx, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:36               ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 22:36 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it?  All that fixing
> > this error will do is get the driver to print "oh dear there's a
> > problem" under four more conditions than it previously did.
> > 
> > We've been at this for three years now with nearly a thousand
> > patches, firstly marking all the fall throughs with /* fall through
> > */ and later changing it to fallthrough.  At some point we do have
> > to ask if the effort is commensurate with the protection
> > afforded.  Please tell me our reward for all this effort isn't a
> > single missing error print.
> 
> It isn't that much effort, isn't it?

Well, it seems to be three years of someone's time plus the maintainer
review time and series disruption of nearly a thousand patches.  Let's
be conservative and assume the producer worked about 30% on the series
and it takes about 5-10 minutes per patch to review, merge and for
others to rework existing series.  So let's say it's cost a person year
of a relatively junior engineer producing the patches and say 100h of
review and application time.  The latter is likely the big ticket item
because it's what we have in least supply in the kernel (even though
it's 20x vs the producer time).

>  Plus we need to take into account the future mistakes that it might
> prevent, too. So even if there were zero problems found so far, it is
> still a positive change.

Well, the question I was asking is if it's worth the cost which I've
tried to outline above.

> I would agree if these changes were high risk, though; but they are
> almost trivial.

It's not about the risk of the changes it's about the cost of
implementing them.  Even if you discount the producer time (which
someone gets to pay for, and if I were the engineering manager, I'd be
unhappy about), the review/merge/rework time is pretty significant in
exchange for six minor bug fixes.  Fine, when a new compiler warning
comes along it's certainly reasonable to see if we can benefit from it
and the fact that the compiler people think it's worthwhile is enough
evidence to assume this initially.  But at some point you have to ask
whether that assumption is supported by the evidence we've accumulated
over the time we've been using it.  And if the evidence doesn't support
it perhaps it is time to stop the experiment.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 20:35             ` Miguel Ojeda
                                 ` (9 preceding siblings ...)
  (?)
@ 2020-11-22 22:54               ` Finn Thain
  -1 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, Nathan Chancellor, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: intel-wired-lan


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: cluster-devel.redhat.com


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 22:54               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-22 22:54 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Sun, 22 Nov 2020, Miguel Ojeda wrote:

> 
> It isn't that much effort, isn't it? Plus we need to take into account 
> the future mistakes that it might prevent, too.

We should also take into account optimisim about future improvements in 
tooling.

> So even if there were zero problems found so far, it is still a positive 
> change.
> 

It is if you want to spin it that way.

> I would agree if these changes were high risk, though; but they are 
> almost trivial.
> 

This is trivial:

 case 1:
	this();
+	fallthrough;
 case 2:
 	that();

But what we inevitably get is changes like this:

 case 3:
        this();
+       break;
 case 4:
        hmmm();

Why? Mainly to silence the compiler. Also because the patch author argued 
successfully that they had found a theoretical bug, often in mature code.

But is anyone keeping score of the regressions? If unreported bugs count, 
what about unreported regressions?

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 22:54               ` Finn Thain
                                   ` (10 preceding siblings ...)
  (?)
@ 2020-11-22 23:04                 ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, Joe Perches, linux-integrity, wcn36xx, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-22 23:04                 ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-22 23:04 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?

Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-through
series named in a fixes tag and these three popped out:

9cf51446e686 bpf, powerpc: Fix misuse of fallthrough in bpf_jit_comp()
6a9dc5fd6170 lib: Revert use of fallthrough pseudo-keyword in lib/
91dbd73a1739 mips/oprofile: Fix fallthrough placement

I don't think any of these is fixing a significant problem, but they
did cause someone time and trouble to investigate.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 037/141] Input: pcspkr - Fix fall-through warnings for Clang
  2020-11-20 18:30 ` [PATCH 037/141] Input: pcspkr - " Gustavo A. R. Silva
@ 2020-11-23  6:15   ` Dmitry Torokhov
  2020-11-23 22:48     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Dmitry Torokhov @ 2020-11-23  6:15 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: linux-input, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:30:02PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of just letting the code
> fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied, thank you.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 141/141] Input: libps2 - Fix fall-through warnings for Clang
  2020-11-20 18:41 ` [PATCH 141/141] Input: libps2 - " Gustavo A. R. Silva
@ 2020-11-23  6:16   ` Dmitry Torokhov
  2020-11-24 14:44     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Dmitry Torokhov @ 2020-11-23  6:16 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: linux-input, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:41:12PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a
> warning by replacing a /* Fall through */ comment with the new
> pseudo-keyword macro fallthrough.
> 
> Notice that Clang doesn't recognize /* Fall through */ comments as
> implicit fall-through markings.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied, thank you.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  2020-11-20 18:37   ` Gustavo A. R. Silva
@ 2020-11-23  7:00     ` Michal Simek
  -1 siblings, 0 replies; 1306+ messages in thread
From: Michal Simek @ 2020-11-23  7:00 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Michal Simek, Adrian Hunter, Ulf Hansson
  Cc: linux-arm-kernel, linux-mmc, linux-kernel, linux-hardening



On 20. 11. 20 19:37, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 829ccef87426..1f7e42b6ced5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 8 Taps are available */
>  		tap_max = 8;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 30 Taps are available */
>  		tap_max = 30;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 8 Taps are available */
>  		tap_max = 8;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 30 Taps are available */
>  		tap_max = 30;
> +		break;
>  	default:
>  		break;
>  	}
> 

No problem with it.

Acked-by: Michal Simek <michal.simek@xilinx.com>

Thanks,
Michal

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
@ 2020-11-23  7:00     ` Michal Simek
  0 siblings, 0 replies; 1306+ messages in thread
From: Michal Simek @ 2020-11-23  7:00 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Michal Simek, Adrian Hunter, Ulf Hansson
  Cc: linux-mmc, linux-kernel, linux-arm-kernel, linux-hardening



On 20. 11. 20 19:37, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 829ccef87426..1f7e42b6ced5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 8 Taps are available */
>  		tap_max = 8;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 30 Taps are available */
>  		tap_max = 30;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 8 Taps are available */
>  		tap_max = 8;
> +		break;
>  	default:
>  		break;
>  	}
> @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>  	case MMC_TIMING_MMC_HS200:
>  		/* For 200MHz clock, 30 Taps are available */
>  		tap_max = 30;
> +		break;
>  	default:
>  		break;
>  	}
> 

No problem with it.

Acked-by: Michal Simek <michal.simek@xilinx.com>

Thanks,
Michal

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 050/141] RDMA/mlx5: Fix fall-through warnings for Clang
  2020-11-20 18:31 ` [PATCH 050/141] RDMA/mlx5: " Gustavo A. R. Silva
@ 2020-11-23  8:33   ` Leon Romanovsky
  2020-11-23 22:50     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Leon Romanovsky @ 2020-11-23  8:33 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:31:49PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding the new pseudo-keyword fallthrough; instead of
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/infiniband/hw/mlx5/qp.c | 1 +
>  1 file changed, 1 insertion(+)
>

Thanks,
Acked-by: Leon Romanovsky <leonro@nvidia.com>

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
  2020-11-20 18:37   ` Gustavo A. R. Silva
  (?)
@ 2020-11-23  8:33     ` Miquel Raynal
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miquel Raynal @ 2020-11-23  8:33 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Richard Weinberger, Vignesh Raghavendra, Maxime Coquelin,
	Alexandre Torgue, linux-mtd, linux-stm32, linux-arm-kernel,
	linux-kernel, linux-hardening

Hi Gustavo,

"Gustavo A. R. Silva" <gustavoars@kernel.org> wrote on Fri, 20 Nov 2020
12:37:48 -0600:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a couple of fallthrough pseudo-keywords
> instead of letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 550bda4d1415..002fa521036f 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			bit_position += shifting;
> +			fallthrough;

In patch 100, 101, 102, 103 you 'break' in this case (when the
statement falls into the empty following statement which itself
breaks). Please make it consistent and use break here, below, and in
patch 132.

LGTM otherwise.

>  		case 1:
>  			break;
>  		default:
> @@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			byte_addr += shifting;
> +			fallthrough;
>  		case 1:
>  			break;
>  		default:

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
@ 2020-11-23  8:33     ` Miquel Raynal
  0 siblings, 0 replies; 1306+ messages in thread
From: Miquel Raynal @ 2020-11-23  8:33 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Vignesh Raghavendra, Richard Weinberger, linux-kernel, linux-mtd,
	linux-hardening, Maxime Coquelin, linux-stm32, linux-arm-kernel,
	Alexandre Torgue

Hi Gustavo,

"Gustavo A. R. Silva" <gustavoars@kernel.org> wrote on Fri, 20 Nov 2020
12:37:48 -0600:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a couple of fallthrough pseudo-keywords
> instead of letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 550bda4d1415..002fa521036f 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			bit_position += shifting;
> +			fallthrough;

In patch 100, 101, 102, 103 you 'break' in this case (when the
statement falls into the empty following statement which itself
breaks). Please make it consistent and use break here, below, and in
patch 132.

LGTM otherwise.

>  		case 1:
>  			break;
>  		default:
> @@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			byte_addr += shifting;
> +			fallthrough;
>  		case 1:
>  			break;
>  		default:

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 104/141] mtd: rawnand: stm32_fmc2: Fix fall-through warnings for Clang
@ 2020-11-23  8:33     ` Miquel Raynal
  0 siblings, 0 replies; 1306+ messages in thread
From: Miquel Raynal @ 2020-11-23  8:33 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Vignesh Raghavendra, Richard Weinberger, linux-kernel, linux-mtd,
	linux-hardening, Maxime Coquelin, linux-stm32, linux-arm-kernel,
	Alexandre Torgue

Hi Gustavo,

"Gustavo A. R. Silva" <gustavoars@kernel.org> wrote on Fri, 20 Nov 2020
12:37:48 -0600:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a couple of fallthrough pseudo-keywords
> instead of letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 550bda4d1415..002fa521036f 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -531,6 +531,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			bit_position += shifting;
> +			fallthrough;

In patch 100, 101, 102, 103 you 'break' in this case (when the
statement falls into the empty following statement which itself
breaks). Please make it consistent and use break here, below, and in
patch 132.

LGTM otherwise.

>  		case 1:
>  			break;
>  		default:
> @@ -546,6 +547,7 @@ static int stm32_fmc2_nfc_ham_correct(struct nand_chip *chip, u8 *dat,
>  		switch (b % 4) {
>  		case 2:
>  			byte_addr += shifting;
> +			fallthrough;
>  		case 1:
>  			break;
>  		default:

Thanks,
Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 030/141] ext2: Fix fall-through warnings for Clang
  2020-11-20 18:28 ` [PATCH 030/141] ext2: " Gustavo A. R. Silva
@ 2020-11-23  9:37   ` Jan Kara
  2020-11-23 22:47     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jan Kara @ 2020-11-23  9:37 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: Jan Kara, linux-ext4, linux-kernel, linux-hardening

On Fri 20-11-20 12:28:25, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of just letting the code
> fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks. Applied.

								Honza

> ---
>  fs/ext2/inode.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
> index 11c5c6fe75bb..78c417d3c898 100644
> --- a/fs/ext2/inode.c
> +++ b/fs/ext2/inode.c
> @@ -1256,6 +1256,7 @@ static void __ext2_truncate_blocks(struct inode *inode, loff_t offset)
>  				mark_inode_dirty(inode);
>  				ext2_free_branches(inode, &nr, &nr+1, 3);
>  			}
> +			break;
>  		case EXT2_TIND_BLOCK:
>  			;
>  	}
> -- 
> 2.27.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 058/141] xen-blkfront: Fix fall-through warnings for Clang
  2020-11-20 18:32 ` [PATCH 058/141] xen-blkfront: " Gustavo A. R. Silva
  2020-11-20 21:36   ` boris.ostrovsky
@ 2020-11-23 10:28   ` Roger Pau Monné
  1 sibling, 0 replies; 1306+ messages in thread
From: Roger Pau Monné @ 2020-11-23 10:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Konrad Rzeszutek Wilk, Boris Ostrovsky, Juergen Gross,
	Stefano Stabellini, Jens Axboe, xen-devel, linux-block,
	linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:32:58PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/block/xen-blkfront.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 48629d3433b4..34b028be78ab 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2462,6 +2462,7 @@ static void blkback_changed(struct xenbus_device *dev,
>  			break;
>  		if (talk_to_blkback(dev, info))
>  			break;
> +		break;

I would have added a fallthrough like it's done below in
XenbusStateClosed.

Also, FWIW, I think clang's fallthrough warnings are a bit too verbose.
Falling through to a break like the case here shouldn't cause a
warning IMO, falling through to anything != break should indeed cause
those warnings to appear.

Thanks, Roger.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 064/141] ACPI: Fix fall-through warnings for Clang
  2020-11-20 18:33 ` [PATCH 064/141] ACPI: " Gustavo A. R. Silva
@ 2020-11-23 11:43   ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 11:43 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Rafael J. Wysocki, Len Brown, ACPI Devel Maling List,
	Linux Kernel Mailing List, linux-hardening

On Fri, Nov 20, 2020 at 7:34 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/acpi/sbshc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
> index 53c2862c4c75..0b3de0e63633 100644
> --- a/drivers/acpi/sbshc.c
> +++ b/drivers/acpi/sbshc.c
> @@ -231,6 +231,7 @@ static int smbus_alarm(void *context)
>                 case ACPI_SBS_BATTERY:
>                         acpi_os_execute(OSL_NOTIFY_HANDLER,
>                                         acpi_smbus_callback, hc);
> +                       break;
>                 default:;

Why don't you simply drop the default case below (it's empty anyway)?

>         }
>         mutex_unlock(&hc->lock);
> --
> 2.27.0
>

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 19:53                   ` James Bottomley
                                       ` (9 preceding siblings ...)
  (?)
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: Joe Perches, Kees Cook, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo





_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-mm, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-watchdog, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, drbd-dev,
	linux-hams, Nathan Chancellor, linux-can, linux-arm-kernel,
	linux-hwmon, Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev,
	nouveau, netdev, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, linux-crypto, Jonathan Cameron,
	patches, Joe Perches, linux-integrity, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo





--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo





_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo





_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392 at kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392 at kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo







^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 13:03                     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 13:03 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > Please tell me our reward for all this effort isn't a single
> > > > > missing error print.
> > > > 
> > > > There were quite literally dozens of logical defects found
> > > > by the fallthrough additions.  Very few were logging only.
> > > 
> > > So can you give us the best examples (or indeed all of them if
> > > someone is keeping score)?  hopefully this isn't a US election
> > > situation ...
> > 
> > Gustavo?  Are you running for congress now?
> > 
> > https://lwn.net/Articles/794944/
> 
> That's 21 reported fixes of which about 50% seem to produce no change
> in code behaviour at all, a quarter seem to have no user visible effect
> with the remaining quarter producing unexpected errors on obscure
> configuration parameters, which is why no-one really noticed them
> before.

The really important point here is the number of bugs this has prevented
and will prevent in the future. See an example of this, below:

https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

This work is still relevant, even if the total number of issues/bugs
we find in the process is zero (which is not the case).

"The sucky thing about doing hard work to deploy hardening is that the
result is totally invisible by definition (things not happening) [..]"
- Dmitry Vyukov

Thanks
--
Gustavo






^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 22:54               ` Finn Thain
                                   ` (11 preceding siblings ...)
  (?)
@ 2020-11-23 14:05                 ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, Nathan Chancellor, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:05                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
>         this();
> +       break;
>  case 4:
>         hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 22:36               ` James Bottomley
                                   ` (12 preceding siblings ...)
  (?)
@ 2020-11-23 14:19                 ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 14:19                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 14:19 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 14:19                 ` Miguel Ojeda
                                     ` (11 preceding siblings ...)
  (?)
@ 2020-11-23 15:58                   ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, Joe Perches, linux-integrity, wcn36xx, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 15:58                   ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 15:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-20 18:23 ` [PATCH 001/141] afs: " Gustavo A. R. Silva
  2020-11-20 23:18   ` Joe Perches
@ 2020-11-23 16:10   ` David Howells
  2020-11-23 16:51     ` Joe Perches
  2020-11-24 13:21     ` David Howells
  1 sibling, 2 replies; 1306+ messages in thread
From: David Howells @ 2020-11-23 16:10 UTC (permalink / raw)
  To: Joe Perches
  Cc: dhowells, Gustavo A. R. Silva, linux-afs, linux-kernel, linux-hardening

Joe Perches <joe@perches.com> wrote:

> >  		call->unmarshall++;
> > +
> > +		fallthrough;
> 
> My preference would be to change these to break and not fallthrough;
> 
> >  	case 5:
> >  		break;
> >  	}

My preference would be to fall through.  The case number is the state machine
state, as indexed by call->unmarshall.  All the other cases in the switch fall
through.

I would also generally prefer that the fallthrough statement occur before the
blank line, not after it, since it belongs with the previous clause, and not
between a comment about a case statement and its associated case statement,
i.e.:

		afs_extract_to_tmp(call);
		call->unmarshall++;

		/* extract the callback array and its count in two steps */
		fallthrough;
	case 3:

would be better written as:

		afs_extract_to_tmp(call);
		call->unmarshall++;
		fallthrough;

		/* extract the callback array and its count in two steps */
	case 3:

David


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 15:58                   ` James Bottomley
                                       ` (11 preceding siblings ...)
  (?)
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel,
	moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, ACPI Devel Maling List, linux-afs, Linux ARM,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, open list:FRAMEBUFFER LAYER, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	linux-iio, linux-input, linux-integrity,
	moderated list:ARM/Mediatek SoC...,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, open list:TARGET SUBSYSTEM,
	linux-sctp, linux-security-module, linux-stm32,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel,
	moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, ACPI Devel Maling List, linux-afs, Linux ARM,
	linux-arm-msm, linux-atm-general, linux-block, linux-can,
	linux-cifs, Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, open list:FRAMEBUFFER LAYER, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	linux-iio, linux-input, linux-integrity,
	moderated list:ARM/Mediatek SoC...,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, open list:TARGET SUBSYSTEM,
	linux-sctp, linux-security-module, linux-stm32,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, nouveau, linux-iio,
	linux-wireless, open list:FRAMEBUFFER LAYER, dri-devel,
	linux-kernel, Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:24                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 1306+ messages in thread
From: Rafael J. Wysocki @ 2020-11-23 16:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	open list:FRAMEBUFFER LAYER, dri-devel, linux-kernel,
	Nathan Chancellor,
	open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, open list:TARGET SUBSYSTEM, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx list,
	linux-stm32, cluster-devel, ACPI Devel Maling List, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	Ext4 Developers List, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee,
	moderated list:ARM/Mediatek SoC...,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp,
	open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

[cut]

> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Right.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.
>
> > If some company does not want to pay for that, that's fine, but they
> > don't get to be maintainers and claim `Supported`.
>
> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.
>
> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

Absolutely.

This is just one of the factors involved, but a significant one IMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 13:03                     ` Gustavo A. R. Silva
                                         ` (10 preceding siblings ...)
  (?)
@ 2020-11-23 16:31                       ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Joe Perches, Kees Cook, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Joe Perches, Kees Cook, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-mm, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-geode, linux-watchdog, devel,
	linux-cifs, Jakub, linux-scsi, linux-acpi, linux-rdma,
	oss-drivers, linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Kicinski, linux-ext4, netfilter-devel,
	linux-media, Kees Cook, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, rds-devel, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, nouveau, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392 at kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392 at kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:31                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 16:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	virtualization, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, linux-mm,
	netdev, linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-nfs, x86, linux-hardening

On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > > > Please tell me our reward for all this effort isn't a
> > > > > > single missing error print.
> > > > > 
> > > > > There were quite literally dozens of logical defects found
> > > > > by the fallthrough additions.  Very few were logging only.
> > > > 
> > > > So can you give us the best examples (or indeed all of them if
> > > > someone is keeping score)?  hopefully this isn't a US election
> > > > situation ...
> > > 
> > > Gustavo?  Are you running for congress now?
> > > 
> > > https://lwn.net/Articles/794944/
> > 
> > That's 21 reported fixes of which about 50% seem to produce no
> > change in code behaviour at all, a quarter seem to have no user
> > visible effect with the remaining quarter producing unexpected
> > errors on obscure configuration parameters, which is why no-one
> > really noticed them before.
> 
> The really important point here is the number of bugs this has
> prevented and will prevent in the future. See an example of this,
> below:
> 
> https://lore.kernel.org/linux-iio/20190813135802.GB27392@kroah.com/

I think this falls into the same category as the other six bugs: it
changes the output/input for parameters but no-one has really noticed,
usually because the command is obscure or the bias effect is minor.

> This work is still relevant, even if the total number of issues/bugs
> we find in the process is zero (which is not the case).

Really, no ... something which produces no improvement has no value at
all ... we really shouldn't be wasting maintainer time with it because
it has a cost to merge.  I'm not sure we understand where the balance
lies in value vs cost to merge but I am confident in the zero value
case.

> "The sucky thing about doing hard work to deploy hardening is that
> the result is totally invisible by definition (things not happening)
> [..]"
> - Dmitry Vyukov

Really, no.  Something that can't be measured at all doesn't exist.

And actually hardening is one of those things you can measure (which I
do have to admit isn't true for everything in the security space) ...
it's number of exploitable bugs found before you did it vs number of
exploitable bugs found after you did it.  Usually hardening eliminates
a class of bug, so the way I've measured hardening before is to go
through the CVE list for the last couple of years for product X, find
all the bugs that are of the class we're looking to eliminate and say
if we had hardened X against this class of bug we'd have eliminated Y%
of the exploits.  It can be quite impressive if Y is a suitably big
number.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 15:58                   ` James Bottomley
                                       ` (12 preceding siblings ...)
  (?)
@ 2020-11-23 16:32                     ` Joe Perches
  -1 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, linux-integrity, wcn36xx, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 16:32                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:32 UTC (permalink / raw)
  To: James Bottomley, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-23 16:10   ` David Howells
@ 2020-11-23 16:51     ` Joe Perches
  2020-11-24 13:21     ` David Howells
  1 sibling, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-23 16:51 UTC (permalink / raw)
  To: David Howells
  Cc: Gustavo A. R. Silva, linux-afs, linux-kernel, linux-hardening

On Mon, 2020-11-23 at 16:10 +0000, David Howells wrote:
> Joe Perches <joe@perches.com> wrote:
> 
> > >  		call->unmarshall++;
> > > +
> > > +		fallthrough;
> > 
> > My preference would be to change these to break and not fallthrough;
> > 
> > >  	case 5:
> > >  		break;
> > >  	}
> 
> My preference would be to fall through.  The case number is the state machine
> state, as indexed by call->unmarshall.

Then ideally the state machine states should be enums and not numbers
and the compiler should use a default block for unhandled states right?

Is code like call->marshall++ a common style for kernel state machines?
Perhaps not.

Does it work?
Sure.

Is it obvious what the transitions are?
No.

> All the other cases in the switch fall through.
> 
> I would also generally prefer that the fallthrough statement occur before the
> blank line, not after it, since it belongs with the previous clause, and not
> between a comment about a case statement and its associated case statement,
> i.e.:
> 
> 		afs_extract_to_tmp(call);
> 		call->unmarshall++;
> 
> 		/* extract the callback array and its count in two steps */
> 		fallthrough;
> 	case 3:
> 
> would be better written as:
> 
> 		afs_extract_to_tmp(call);
> 		call->unmarshall++;
> 		fallthrough;
> 
> 		/* extract the callback array and its count in two steps */
> 	case 3:

I agree completely.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 15:58                   ` James Bottomley
                                       ` (12 preceding siblings ...)
  (?)
@ 2020-11-23 18:56                     ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 18:56                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-23 18:56 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                     ` (10 preceding siblings ...)
  (?)
@ 2020-11-23 20:03   ` Jason Gunthorpe
  -1 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches,
	Kees Cook

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module, amd-gfx,
	linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:03   ` Jason Gunthorpe
  0 siblings, 0 replies; 1306+ messages in thread
From: Jason Gunthorpe @ 2020-11-23 20:03 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 18:56                     ` Miguel Ojeda
                                         ` (11 preceding siblings ...)
  (?)
@ 2020-11-23 20:37                       ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, Joe Perches, linux-integrity, wcn36xx, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:37                       ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-23 20:37 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-20 18:21 ` Gustavo A. R. Silva
                     ` (7 preceding siblings ...)
  (?)
@ 2020-11-23 20:38   ` Mark Brown
  -1 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-crypto, linux-sctp, Nathan Chancellor, linux-hardening,
	usb-storage, linux-block, linux-security-module, bridge,
	GR-Linux-NIC-Dev, rds-devel, dri-devel, linux-media, wcn36xx,
	linux-wireless, linux-mediatek, reiserfs-devel, oss-drivers,
	linux-arm-kernel, alsa-devel, virtualization, Joe Perches,
	patches, linux-gpio, linux-hwmon, linux-cifs, coreteam,
	Kees Cook, Nick Desaulniers, linux-scsi, linux-afs,
	netfilter-devel, rnel.org, linux-geode, drbd-dev, linux-ext4,
	linux-hams, target-devel, samba-technical, tipc-discussion,
	linux-stm32, linux-renesas-soc, linux-input, amd-gfx, linux-nfs,
	devel, selinux, linux-atm-general, linux-iio, linux-i3c,
	Miguel Ojeda, linux-can, linux-integrity, GR-everest-linux-l2,
	keyrings, intel-wired-lan, linux-usb, nouveau, x86, xen-devel,
	linux-mm, cluster-devel, linux1394-devel, linux-decnet-user,
	op-tee, l, inux-ide, intel-gfx, linux-acpi, dm-devel,
	linux-watchdog, linux-rdma, linux-mtd, ceph-devel, linux-arm-msm,
	linux-mmc, linux-fbdev, netdev

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, usb-storage, Nick Desaulniers,
	x86, dri-devel, virtualization, linux-mm, linux-sctp,
	target-devel, linux-mtd, linux-hardening, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, bridge,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, oss-drivers,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	xen-devel, linux-ext4, linux-media, Kees Cook, selinux,
	linux-arm-msm, intel-gfx, reiserfs-devel, linux-geode,
	linux-block, linux-gpio, op-tee, linux-mediatek, samba-technical,
	linux-fbdev, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, inux-ide, l, netfilter-devel,
	linux-decnet-user, patches, linux-usb, linux-wireless, dm-devel,
	linux-iio, linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, rnel.org, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-watchdog, alsa-devel, linux-atm-general, usb-storage,
	Nick Desaulniers, rnel.org, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, op-tee,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, xen-devel, linux-ext4, linux-media, l, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, reiserfs-devel, linux-geode,
	linux-block, linux-gpio, linux-mediatek, samba-technical,
	linux-fbdev, inux-ide, nouveau, linux-hams, Nathan Chancellor,
	linux-can, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, e.org, netfilter-devel, linux-decnet-user,
	patches, linux-usb, linux-wireless, dm-devel, linux-iio,
	linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-ide, linux-watchdog, alsa-devel, linux-atm-general,
	usb-storage, Nick Desaulniers, linux-mmc, rnel.org, dri-devel,
	virtualization, linux-mm, linux-sctp, target-devel, linux-mtd,
	linux-hardening, wcn36xx, linux-i3c, linux1394-devel, linux-afs,
	drbd-dev, devel, linux-cifs, rds-devel, linux-scsi, linux-acpi,
	linux-rdma, bridge, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, oss-drivers, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, xen-devel, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, netfilter-devel, linux-decnet-user,
	patches, linux-usb, linux-wireless, dm-devel, linux-iio,
	linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: alsa-devel, linux-atm-general, usb-storage, Nick Desaulniers,
	x86, dri-devel, virtualization, linux-mm, linux-sctp,
	target-devel, linux-mtd, linux-hardening, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-watchdog, devel, linux-cifs,
	rds-devel, linux-acpi, linux-scsi, netfilter-devel, linux-rdma,
	bridge, l.inux-ide, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, xen-devel, linux-ext4, linux-media, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, reiserfs-devel, linux-geode,
	linux-block, linux-gpio, op-tee, linux-mediatek, samba-technical,
	linux-fbdev, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, linux-mmc, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, linux-decnet-user, patches, linux-usb,
	linux-wireless, dm-devel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, tipc-discussion, linux-crypto,
	netdev, Joe Perches, ceph-devel, linux-integrity,
	GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-ide, linux-watchdog, alsa-devel, linux-atm-general,
	usb-storage, Nick Desaulniers, linux-mmc, rnel.org, dri-devel,
	virtualization, linux-mm, linux-sctp, target-devel, linux-mtd,
	linux-hardening, wcn36xx, linux-i3c, linux1394-devel, linux-afs,
	drbd-dev, devel, linux-cifs, rds-devel, linux-scsi, linux-acpi,
	linux-rdma, bridge, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, oss-drivers, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, xen-devel, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, netfilter-devel, linux-decnet-user,
	patches, linux-usb, linux-wireless, dm-devel, linux-iio,
	linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-ide, linux-watchdog, alsa-devel, linux-atm-general,
	usb-storage, Nick Desaulniers, linux-mmc, rnel.org, dri-devel,
	virtualization, linux-mm, linux-sctp, target-devel, linux-mtd,
	linux-hardening, wcn36xx, linux-i3c, linux1394-devel, linux-afs,
	drbd-dev, devel, linux-cifs, rds-devel, linux-scsi, linux-acpi,
	linux-rdma, bridge, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, oss-drivers, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, xen-devel, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon, x86,
	linux-nfs, GR-Linux-NIC-Dev, netfilter-devel, linux-decnet-user,
	patches, linux-usb, linux-wireless, dm-devel, linux-iio,
	linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: intel-wired-lan

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-23 20:38   ` Mark Brown
  0 siblings, 0 replies; 1306+ messages in thread
From: Mark Brown @ 2020-11-23 20:38 UTC (permalink / raw)
  To: linux-kernel, Gustavo A. R. Silva
  Cc: linux-watchdog, alsa-devel, linux-atm-general, usb-storage,
	Nick Desaulniers, rnel.org, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, op-tee,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, xen-devel, linux-ext4, linux-media, l, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, reiserfs-devel, linux-geode,
	linux-block, linux-gpio, linux-mediatek, samba-technical,
	linux-fbdev, inux-ide, nouveau, linux-hams, Nathan Chancellor,
	linux-can, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, e.org, netfilter-devel, linux-decnet-user,
	patches, linux-usb, linux-wireless, dm-devel, linux-iio,
	linux-renesas-soc, linux-security-module, keyrings,
	tipc-discussion, linux-crypto, netdev, Joe Perches,
	linux-integrity, GR-everest-linux-l2

On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
> 
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fallthrough statements instead of just
> letting the code fall through to the next case.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[1/1] regulator: as3722: Fix fall-through warnings for Clang
      commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
  2020-11-20 22:42     ` Alex Deucher
  (?)
@ 2020-11-23 22:42       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:42 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Alex Deucher, Christian König, David Airlie, Daniel Vetter,
	linux-hardening, Maling list - DRI developers, amd-gfx list,
	LKML

On Fri, Nov 20, 2020 at 05:42:38PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-23 22:42       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:42 UTC (permalink / raw)
  To: Alex Deucher
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Alex Deucher, Christian König

On Fri, Nov 20, 2020 at 05:42:38PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 004/141] drm/amdgpu: Fix fall-through warnings for Clang
@ 2020-11-23 22:42       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:42 UTC (permalink / raw)
  To: Alex Deucher
  Cc: amd-gfx list, David Airlie, LKML, Maling list - DRI developers,
	linux-hardening, Daniel Vetter, Alex Deucher,
	Christian König

On Fri, Nov 20, 2020 at 05:42:38PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:24 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 008/141] IB/hfi1: Fix fall-through warnings for Clang
  2020-11-22 14:30   ` Mike Marciniszyn
@ 2020-11-23 22:44     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:44 UTC (permalink / raw)
  To: Mike Marciniszyn
  Cc: Dennis Dalessandro, Doug Ledford, Jason Gunthorpe, linux-rdma,
	linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 09:30:25AM -0500, Mike Marciniszyn wrote:
> 
> On 11/20/2020 1:25 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> > 
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Looks good and tested with TID rdma to cover the interlock case.
> 
> Mike
> 
> Tested-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>

Thanks, Mike.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 013/141] media: dvb-frontends: Fix fall-through warnings for Clang
  2020-11-22 16:31   ` Mauro Carvalho Chehab
@ 2020-11-23 22:44     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:44 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Jemma Denson, Patrick Boettcher, Malcolm Priestley, linux-media,
	linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 05:31:16PM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 20 Nov 2020 12:26:09 -0600
> "Gustavo A. R. Silva" <gustavoars@kernel.org> escreveu:
> 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break and a return statements
> > instead of just letting the code fall through to the next case.
> 
> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Thanks, Mauro.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 015/141] netfilter: Fix fall-through warnings for Clang
  2020-11-20 22:47   ` Florian Westphal
@ 2020-11-23 22:45     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:45 UTC (permalink / raw)
  To: Florian Westphal
  Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
	Jakub Kicinski, netfilter-devel, coreteam, netdev, linux-kernel,
	linux-hardening

On Fri, Nov 20, 2020 at 11:47:37PM +0100, Florian Westphal wrote:
> Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> 
> Acked-by: Florian Westphal <fw@strlen.de>
> 
> Feel free to carry this in next iteration of series, if any.

Thanks, Florian.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 016/141] nfsd: Fix fall-through warnings for Clang
  2020-11-20 18:27   ` Chuck Lever
@ 2020-11-23 22:46     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:46 UTC (permalink / raw)
  To: Chuck Lever
  Cc: Bruce Fields, Linux NFS Mailing List, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 01:27:51PM -0500, Chuck Lever wrote:
> 
> 
> > On Nov 20, 2020, at 1:26 PM, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding a couple of break statements instead of
> > just letting the code fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> > fs/nfsd/nfs4state.c | 1 +
> > fs/nfsd/nfsctl.c    | 1 +
> > 2 files changed, 2 insertions(+)
> > 
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index d7f27ed6b794..cdab0d5be186 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -3113,6 +3113,7 @@ nfsd4_exchange_id(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> > 			goto out_nolock;
> > 		}
> > 		new->cl_mach_cred = true;
> > +		break;
> > 	case SP4_NONE:
> > 		break;
> > 	default:				/* checked by xdr code */
> > diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> > index f6d5d783f4a4..9a3bb1e217f9 100644
> > --- a/fs/nfsd/nfsctl.c
> > +++ b/fs/nfsd/nfsctl.c
> > @@ -1165,6 +1165,7 @@ static struct inode *nfsd_get_inode(struct super_block *sb, umode_t mode)
> > 		inode->i_fop = &simple_dir_operations;
> > 		inode->i_op = &simple_dir_inode_operations;
> > 		inc_nlink(inode);
> > +		break;
> > 	default:
> > 		break;
> > 	}
> > -- 
> > 2.27.0
> > 
> 
> Acked-by: Chuck Lever <chuck.lever@oracle.com>

Thanks, Chuck.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [EXT] [PATCH 018/141] qed: Fix fall-through warnings for Clang
  2020-11-20 18:50   ` [EXT] " Igor Russkikh
@ 2020-11-23 22:46     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:46 UTC (permalink / raw)
  To: Igor Russkikh
  Cc: Ariel Elior, David S. Miller, Jakub Kicinski,
	GR-everest-linux-l2, netdev, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 09:50:06PM +0300, Igor Russkikh wrote:
> 
> 
> On 20/11/2020 9:26 pm, Gustavo A. R. Silva wrote:
> > External Email
> > 
> > ----------------------------------------------------------------------
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding a couple of break statements instead of
> > just letting the code fall through to the next case.
> > 
> > Link:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_KSPP_linux
> > _issues_115&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=GtqbaEwqFLiM6BiwNMdKmpXb5o
> > up1VLiSIroUNQwbYA&m=6E7IvGvqcEGj8wEOVoN1BySZhGUVECVTBJCmNiRsHUw&s=J1SWrfEL
> > erJOzUlJdD_S5afGaZosmVP8lyKsu9DTULw&e= 
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Reviewed-by: Igor Russkikh <irusskikh@marvell.com>

Thanks, Igor.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
  2020-11-20 22:45     ` Alex Deucher
  (?)
@ 2020-11-23 22:47       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:47 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Harry Wentland, Leo Li, Alex Deucher, Christian König,
	David Airlie, Daniel Vetter, linux-hardening,
	Maling list - DRI developers, amd-gfx list, LKML

On Fri, Nov 20, 2020 at 05:45:07PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-23 22:47       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:47 UTC (permalink / raw)
  To: Alex Deucher
  Cc: amd-gfx list, Leo Li, LKML, Maling list - DRI developers,
	David Airlie, linux-hardening, Alex Deucher,
	Christian König

On Fri, Nov 20, 2020 at 05:45:07PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 028/141] drm/amd/display: Fix fall-through warnings for Clang
@ 2020-11-23 22:47       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:47 UTC (permalink / raw)
  To: Alex Deucher
  Cc: amd-gfx list, Leo Li, LKML, Maling list - DRI developers,
	David Airlie, linux-hardening, Daniel Vetter, Alex Deucher,
	Harry Wentland, Christian König

On Fri, Nov 20, 2020 at 05:45:07PM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2020 at 1:28 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of just
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied.  Thanks!

Thanks, Alex.
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 030/141] ext2: Fix fall-through warnings for Clang
  2020-11-23  9:37   ` Jan Kara
@ 2020-11-23 22:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:47 UTC (permalink / raw)
  To: Jan Kara; +Cc: Jan Kara, linux-ext4, linux-kernel, linux-hardening

On Mon, Nov 23, 2020 at 10:37:09AM +0100, Jan Kara wrote:
> On Fri 20-11-20 12:28:25, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of just letting the code
> > fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks. Applied.

Thanks, Jan.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [EXT] [PATCH 035/141] IB/qedr: Fix fall-through warnings for Clang
  2020-11-22 20:12   ` [EXT] " Michal Kalderon
@ 2020-11-23 22:48     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:48 UTC (permalink / raw)
  To: Michal Kalderon
  Cc: Ariel Elior, Doug Ledford, Jason Gunthorpe, linux-rdma,
	linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 08:12:15PM +0000, Michal Kalderon wrote:
> > From: Gustavo A. R. Silva <gustavoars@kernel.org>
> > Sent: Friday, November 20, 2020 8:29 PM
> > 
> > ----------------------------------------------------------------------
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by
> > explicitly adding a break statement instead of just letting the code fall
> > through to the next case.
> > 
> > Link: https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__github.com_KSPP_linux_issues_115&d=DwIBAg&c=nKjWec2b6R0mOyP
> > az7xtfQ&r=5_8rRZTDuAS-6X-cGRU9Fo4yjCnkS1t7T3-
> > gjL4FQng&m=ZJjyam8OGRTmM8iCzOSDOL7dMn31Pmw3aA-
> > QOVDY8eg&s=4rQYW1K3xAzeRV7SRkrvaivRWz2WwEuuk0ZnjnDTA1w&e=
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/infiniband/hw/qedr/main.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/infiniband/hw/qedr/main.c
> > b/drivers/infiniband/hw/qedr/main.c
> > index 967641662b24..10707b451ab8 100644
> > --- a/drivers/infiniband/hw/qedr/main.c
> > +++ b/drivers/infiniband/hw/qedr/main.c
> > @@ -796,6 +796,7 @@ static void qedr_affiliated_event(void *context, u8
> > e_code, void *fw_handle)
> >  		}
> >  		xa_unlock_irqrestore(&dev->srqs, flags);
> >  		DP_NOTICE(dev, "SRQ event %d on handle %p\n", e_code,
> > srq);
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > --
> > 2.27.0
> 
> Thanks, 
> 
> Acked-by: Michal Kalderon <michal.kalderon@marvell.com>

Thanks, Michal.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 037/141] Input: pcspkr - Fix fall-through warnings for Clang
  2020-11-23  6:15   ` Dmitry Torokhov
@ 2020-11-23 22:48     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:48 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 10:15:55PM -0800, Dmitry Torokhov wrote:
> On Fri, Nov 20, 2020 at 12:30:02PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of just letting the code
> > fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied, thank you.

Thanks, Dmitry.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 044/141] net/mlx4: Fix fall-through warnings for Clang
  2020-11-22  8:36   ` Tariq Toukan
@ 2020-11-23 22:49     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:49 UTC (permalink / raw)
  To: Tariq Toukan
  Cc: Tariq Toukan, David S. Miller, Jakub Kicinski, netdev,
	linux-rdma, linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 10:36:01AM +0200, Tariq Toukan wrote:
> 
> 
> On 11/20/2020 8:31 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of just letting the code
> > fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >   drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> > index 1187ef1375e2..e6b8b8dc7894 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
> > @@ -2660,6 +2660,7 @@ int mlx4_FREE_RES_wrapper(struct mlx4_dev *dev, int slave,
> >   	case RES_XRCD:
> >   		err = xrcdn_free_res(dev, slave, vhcr->op_modifier, alop,
> >   				     vhcr->in_param, &vhcr->out_param);
> > +		break;
> >   	default:
> >   		break;
> > 
> 
> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> 
> Thanks for your patch.

Thanks, Tariq.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 049/141] pinctrl: Fix fall-through warnings for Clang
  2020-11-20 19:04   ` Geert Uytterhoeven
@ 2020-11-23 22:49     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:49 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Linus Walleij, Linux-Renesas, open list:GPIO SUBSYSTEM,
	Linux Kernel Mailing List, linux-hardening

On Fri, Nov 20, 2020 at 08:04:42PM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2020 at 7:31 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-pinctrl-for-v5.11.

Thanks, Geert.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 050/141] RDMA/mlx5: Fix fall-through warnings for Clang
  2020-11-23  8:33   ` Leon Romanovsky
@ 2020-11-23 22:50     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:50 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Doug Ledford, Jason Gunthorpe, linux-rdma, linux-kernel, linux-hardening

On Mon, Nov 23, 2020 at 10:33:32AM +0200, Leon Romanovsky wrote:
> On Fri, Nov 20, 2020 at 12:31:49PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding the new pseudo-keyword fallthrough; instead of
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/infiniband/hw/mlx5/qp.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> 
> Thanks,
> Acked-by: Leon Romanovsky <leonro@nvidia.com>

Thanks, Leon.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 057/141] watchdog: Fix fall-through warnings for Clang
  2020-11-21 18:49   ` Guenter Roeck
@ 2020-11-23 22:50     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:50 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Wim Van Sebroeck, linux-watchdog, linux-kernel, linux-hardening

On Sat, Nov 21, 2020 at 10:49:51AM -0800, Guenter Roeck wrote:
> On Fri, Nov 20, 2020 at 12:32:51PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a fallthrough pseudo-keyword instead of letting the
> > code fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/watchdog/machzwd.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/watchdog/machzwd.c b/drivers/watchdog/machzwd.c
> > index 743377c5b173..73f2221f6222 100644
> > --- a/drivers/watchdog/machzwd.c
> > +++ b/drivers/watchdog/machzwd.c
> > @@ -174,6 +174,7 @@ static inline void zf_set_timer(unsigned short new, unsigned char n)
> >  		fallthrough;
> >  	case WD2:
> >  		zf_writeb(COUNTER_2, new > 0xff ? 0xff : new);
> > +		fallthrough;
> 
> fallthrough to return ? Oh well, this is an old style driver anyway,
> so I guess who cares.

:)

> Acked-by: Guenter Roeck <linux@roeck-us.net>

Thanks, Guenter.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 131/141] tpm: Fix fall-through warnings for Clang
  2020-11-20 18:40 ` [PATCH 131/141] tpm: " Gustavo A. R. Silva
@ 2020-11-23 22:52   ` Jarkko Sakkinen
  2020-11-23 22:53     ` Jarkko Sakkinen
  0 siblings, 1 reply; 1306+ messages in thread
From: Jarkko Sakkinen @ 2020-11-23 22:52 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Peter Huewe, Jason Gunthorpe, linux-integrity, linux-kernel,
	linux-hardening

On Fri, Nov 20, 2020 at 12:40:14PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/char/tpm/eventlog/tpm1.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
> index 2c96977ad080..8aa9057601d6 100644
> --- a/drivers/char/tpm/eventlog/tpm1.c
> +++ b/drivers/char/tpm/eventlog/tpm1.c
> @@ -210,6 +210,7 @@ static int get_event_name(char *dest, struct tcpa_event *event,
>  		default:
>  			break;
>  		}
> +		break;
>  	default:
>  		break;
>  	}
> -- 
> 2.27.0
> 
> 

Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>

Who is picking these patches?

/Jarkko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 131/141] tpm: Fix fall-through warnings for Clang
  2020-11-23 22:52   ` Jarkko Sakkinen
@ 2020-11-23 22:53     ` Jarkko Sakkinen
  2020-11-24 14:40       ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jarkko Sakkinen @ 2020-11-23 22:53 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Peter Huewe, Jason Gunthorpe, linux-integrity, linux-kernel,
	linux-hardening

On Tue, Nov 24, 2020 at 12:52:31AM +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 20, 2020 at 12:40:14PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/char/tpm/eventlog/tpm1.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
> > index 2c96977ad080..8aa9057601d6 100644
> > --- a/drivers/char/tpm/eventlog/tpm1.c
> > +++ b/drivers/char/tpm/eventlog/tpm1.c
> > @@ -210,6 +210,7 @@ static int get_event_name(char *dest, struct tcpa_event *event,
> >  		default:
> >  			break;
> >  		}
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > -- 
> > 2.27.0
> > 
> > 
> 
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
> 
> Who is picking these patches?
> 
> /Jarkko

I mean

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

/Jarkko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 058/141] xen-blkfront: Fix fall-through warnings for Clang
  2020-11-20 21:36   ` boris.ostrovsky
@ 2020-11-23 22:53     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:53 UTC (permalink / raw)
  To: boris.ostrovsky
  Cc: Konrad Rzeszutek Wilk, Roger Pau Monné,
	Juergen Gross, Stefano Stabellini, Jens Axboe, xen-devel,
	linux-block, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 04:36:26PM -0500, boris.ostrovsky@oracle.com wrote:
> 
> On 11/20/20 1:32 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/block/xen-blkfront.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 48629d3433b4..34b028be78ab 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -2462,6 +2462,7 @@ static void blkback_changed(struct xenbus_device *dev,
> >  			break;
> >  		if (talk_to_blkback(dev, info))
> >  			break;
> > +		break;
> >  	case XenbusStateInitialising:
> >  	case XenbusStateInitialised:
> >  	case XenbusStateReconfiguring:
> 
> 
> Reviewed-by Boris Ostrovsky <boris.ostrovsky@oracle.com>
> 
> 
> (for patch 138 as well)

Thank you for both reviews, Boris.

> Although I thought using 'fallthrough' attribute was the more common approach.

I've got it. I will consider that for a future patch.

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 052/141] security: keys: Fix fall-through warnings for Clang
  2020-11-20 18:32 ` [PATCH 052/141] security: keys: " Gustavo A. R. Silva
@ 2020-11-23 22:54   ` Jarkko Sakkinen
  2020-11-24 14:30     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Jarkko Sakkinen @ 2020-11-23 22:54 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: David Howells, James Morris, Serge E. Hallyn, keyrings,
	linux-security-module, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 12:32:20PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  security/keys/process_keys.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> index 1fe8b934f656..e3d79a7b6db6 100644
> --- a/security/keys/process_keys.c
> +++ b/security/keys/process_keys.c
> @@ -783,6 +783,7 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
>  				if (need_perm != KEY_AUTHTOKEN_OVERRIDE &&
>  				    need_perm != KEY_DEFER_PERM_CHECK)
>  					goto invalid_key;
> +				break;
>  			case 0:
>  				break;
>  			}
> -- 
> 2.27.0
> 
> 


Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

/Jarkko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 060/141] habanalabs: Fix fall-through warnings for Clang
  2020-11-21 12:34   ` Oded Gabbay
@ 2020-11-23 22:54     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:54 UTC (permalink / raw)
  To: Oded Gabbay
  Cc: Arnd Bergmann, Greg Kroah-Hartman,
	Linux-Kernel@Vger. Kernel. Org, linux-hardening

On Sat, Nov 21, 2020 at 02:34:23PM +0200, Oded Gabbay wrote:
> On Fri, Nov 20, 2020 at 8:33 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a fallthrough pseudo-keyword instead of letting the
> > code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/misc/habanalabs/gaudi/gaudi.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c b/drivers/misc/habanalabs/gaudi/gaudi.c
> > index 2519a34e25b7..eab4c0dc65c5 100644
> > --- a/drivers/misc/habanalabs/gaudi/gaudi.c
> > +++ b/drivers/misc/habanalabs/gaudi/gaudi.c
> > @@ -5436,6 +5436,7 @@ static void gaudi_handle_ecc_event(struct hl_device *hdev, u16 event_type,
> >                 params.num_memories = 33;
> >                 params.derr = true;
> >                 params.disable_clock_gating = true;
> > +               fallthrough;
> >         default:
> >                 return;
> >         }
> > --
> > 2.27.0
> >
> Hi Gustavo,
> So this is actually an error in the code, there shouldn't be a
> fallthrough there.
> So NAK for this patch, I'll have to send a fix for that.
> Thanks for catching this :)

Awesome. Glad this helped to catch a bug. :)

Thanks
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 061/141] tee: Fix fall-through warnings for Clang
  2020-11-22  9:26   ` Jens Wiklander
@ 2020-11-23 22:55     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:55 UTC (permalink / raw)
  To: Jens Wiklander; +Cc: op-tee, Linux Kernel Mailing List, linux-hardening

On Sun, Nov 22, 2020 at 10:26:09AM +0100, Jens Wiklander wrote:
> On Fri, Nov 20, 2020 at 7:33 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/tee/tee_core.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

Thanks, Jens.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
  2020-11-21  8:30     ` Takashi Iwai
@ 2020-11-23 22:56       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:56 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel, linux-hardening

On Sat, Nov 21, 2020 at 09:30:00AM +0100, Takashi Iwai wrote:
> On Fri, 20 Nov 2020 19:33:52 +0100,
> Gustavo A. R. Silva wrote:
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, applied.

Thanks for all you've taken, Takashi.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 066/141] ALSA: hdspm: Fix fall-through warnings for Clang
@ 2020-11-23 22:56       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:56 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linux-kernel, alsa-devel, linux-hardening, Takashi Iwai

On Sat, Nov 21, 2020 at 09:30:00AM +0100, Takashi Iwai wrote:
> On Fri, 20 Nov 2020 19:33:52 +0100,
> Gustavo A. R. Silva wrote:
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, applied.

Thanks for all you've taken, Takashi.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 075/141] crypto: ccree - Fix fall-through warnings for Clang
  2020-11-22  7:54   ` Gilad Ben-Yossef
@ 2020-11-23 22:57     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:57 UTC (permalink / raw)
  To: Gilad Ben-Yossef
  Cc: Herbert Xu, David S. Miller, Linux Crypto Mailing List,
	Linux kernel mailing list, linux-hardening

On Sun, Nov 22, 2020 at 09:54:29AM +0200, Gilad Ben-Yossef wrote:
> On Fri, Nov 20, 2020 at 8:34 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
[..]
> 
> Acked-by: Gilad Ben-Yossef <gilad@benyossef.com>

Thanks, Gilad.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 079/141] drm: Fix fall-through warnings for Clang
  2020-11-22 22:03     ` Sam Ravnborg
@ 2020-11-23 22:57       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:57 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, linux-kernel, dri-devel,
	linux-hardening

On Sun, Nov 22, 2020 at 11:03:22PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> thanks, applied to drm-misc-next.

Thanks, Sam.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 079/141] drm: Fix fall-through warnings for Clang
@ 2020-11-23 22:57       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:57 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Thomas Zimmermann, David Airlie, linux-kernel, dri-devel,
	linux-hardening

On Sun, Nov 22, 2020 at 11:03:22PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> thanks, applied to drm-misc-next.

Thanks, Sam.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 090/141] iio: adc: cpcap: Fix fall-through warnings for Clang
  2020-11-21 15:05   ` Jonathan Cameron
@ 2020-11-23 22:59     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:59 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Lars-Peter Clausen, Peter Meerwald-Stadler, linux-iio,
	linux-kernel, linux-hardening

On Sat, Nov 21, 2020 at 03:05:04PM +0000, Jonathan Cameron wrote:
> On Fri, 20 Nov 2020 12:36:26 -0600
> "Gustavo A. R. Silva" <gustavoars@kernel.org> wrote:
> 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> Hi Gustavo,

Hi Jonathan,

> I'm assuming there is no 'huge' rush for these an intent is that they will
> filter through the various subsystems.  Hence I've queued it up for the
> next merge window.

Yep; no rush for this.

> Applied to the togreg branch of iio.git

Thank you!
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  2020-11-23  7:00     ` Michal Simek
@ 2020-11-23 22:59       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:59 UTC (permalink / raw)
  To: Michal Simek
  Cc: Adrian Hunter, Ulf Hansson, linux-arm-kernel, linux-mmc,
	linux-kernel, linux-hardening

On Mon, Nov 23, 2020 at 08:00:35AM +0100, Michal Simek wrote:
> 
> 
> On 20. 11. 20 19:37, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of
> > letting the code fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> > index 829ccef87426..1f7e42b6ced5 100644
> > --- a/drivers/mmc/host/sdhci-of-arasan.c
> > +++ b/drivers/mmc/host/sdhci-of-arasan.c
> > @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 8 Taps are available */
> >  		tap_max = 8;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 30 Taps are available */
> >  		tap_max = 30;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 8 Taps are available */
> >  		tap_max = 8;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 30 Taps are available */
> >  		tap_max = 30;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > 
> 
> No problem with it.
> 
> Acked-by: Michal Simek <michal.simek@xilinx.com>

Thanks, Michal.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
@ 2020-11-23 22:59       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-23 22:59 UTC (permalink / raw)
  To: Michal Simek
  Cc: Ulf Hansson, linux-mmc, Adrian Hunter, linux-kernel,
	linux-hardening, linux-arm-kernel

On Mon, Nov 23, 2020 at 08:00:35AM +0100, Michal Simek wrote:
> 
> 
> On 20. 11. 20 19:37, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of
> > letting the code fall through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> > index 829ccef87426..1f7e42b6ced5 100644
> > --- a/drivers/mmc/host/sdhci-of-arasan.c
> > +++ b/drivers/mmc/host/sdhci-of-arasan.c
> > @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 8 Taps are available */
> >  		tap_max = 8;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 30 Taps are available */
> >  		tap_max = 30;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 8 Taps are available */
> >  		tap_max = 8;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
> >  	case MMC_TIMING_MMC_HS200:
> >  		/* For 200MHz clock, 30 Taps are available */
> >  		tap_max = 30;
> > +		break;
> >  	default:
> >  		break;
> >  	}
> > 
> 
> No problem with it.
> 
> Acked-by: Michal Simek <michal.simek@xilinx.com>

Thanks, Michal.
--
Gustavo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 053/141] selinux: Fix fall-through warnings for Clang
  2020-11-20 18:32 ` [PATCH 053/141] selinux: " Gustavo A. R. Silva
@ 2020-11-23 23:31   ` Paul Moore
  2020-11-24 14:30     ` Gustavo A. R. Silva
  0 siblings, 1 reply; 1306+ messages in thread
From: Paul Moore @ 2020-11-23 23:31 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Stephen Smalley, Eric Paris, selinux, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 1:32 PM Gustavo A. R. Silva
<gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  security/selinux/hooks.c | 1 +
>  1 file changed, 1 insertion(+)

Merged into selinux/next, thanks.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 6b1826fc3658..e57774367b3a 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4029,6 +4029,7 @@ static int selinux_kernel_load_data(enum kernel_load_data_id id, bool contents)
>         switch (id) {
>         case LOADING_MODULE:
>                 rc = selinux_kernel_module_from_file(NULL);
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 14:05                 ` Miguel Ojeda
                                     ` (10 preceding siblings ...)
  (?)
@ 2020-11-24  0:58                   ` Finn Thain
  -1 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, Nathan Chancellor, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: intel-wired-lan


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: cluster-devel.redhat.com


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  0:58                   ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  0:58 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening


On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> >         this();
> > +       fallthrough;
> >  case 2:
> >         that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> >         this();
> > +       break;
> >  case 4:
> >         hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24  0:58                   ` Finn Thain
                                       ` (11 preceding siblings ...)
  (?)
@ 2020-11-24  1:05                     ` Joe Perches
  -1 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, Linux, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage,
	linux-watchdog, devel, linux-cifs, rds-devel, Desaulniers,
	linux-scsi, Nick, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Media Mailing List,
	Kees Cook, Nathan Chancellor, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel, List,
	patches, linux-integrity, wcn36xx, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.


_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:05                     ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  1:05 UTC (permalink / raw)
  To: Finn Thain, Miguel Ojeda
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, linux-integrity,
	target-devel, linux-hardening

On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code 
> generation. That's for the patch author and (unfortunately) for reviewers.

Ideally, that proof would be provided by the compilation system itself
and not patch authors nor reviewers nor maintainers.

Unfortunately gcc does not guarantee repeatability or deterministic output.
To my knowledge, neither does clang.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-22 16:17         ` Kees Cook
                             ` (12 preceding siblings ...)
  (?)
@ 2020-11-24  1:32           ` Nick Desaulniers
  -1 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jakub Kicinski, Gustavo A. R. Silva, LKML, alsa-devel,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, Linux Memory Management List, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nathan Chancellor, Miguel Ojeda,
	Joe Perches

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jakub Kicinski, Gustavo A. R. Silva, LKML, alsa-devel,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, Linux Memory Management List, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nathan Chancellor, Miguel Ojeda,
	Joe Perches

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers via Virtualization @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, LKML,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, linux-scsi, linux-rdma, oss-drivers,
	bridge, linux-security-module, amd-gfx list, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: intel-wired-lan

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:32           ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-24  1:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
    ++x;
  default:
    break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
    ++x;
  default:
    goto y;
}
y:;

switch (x) {
  case 0:
    ++x;
  default:
    return;
}

switch (x) {
  case 0:
    ++x;
  default:
    ;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24  1:32           ` Nick Desaulniers
                               ` (7 preceding siblings ...)
  (?)
@ 2020-11-24  1:46             ` Jakub Kicinski
  -1 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Kees Cook, Gustavo A. R. Silva, LKML, alsa-devel, amd-gfx list,
	bridge, ceph-devel, cluster-devel, coreteam, devel, dm-devel,
	drbd-dev, dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev,
	intel-gfx, intel-wired-lan, keyrings, linux1394-devel,
	linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	open list:HARDWARE RANDOM NUMBER GENERATOR  CORE"        
	<linux-crypto@vger.kernel.org>,
	 linux-decnet-user@lists.sourceforge.net,
	linux-ext4@vger.kernel.org,  linux-fbdev@vger.kernel.org,
	linux-geode@lists.infradead.org,  linux-gpio@vger.kernel.org,
	linux-hams@vger.kernel.org,  linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org,  linux-ide@vger.kernel.org,
	linux-iio@vger.kernel.org,  linux-input@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	 linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	 linux-mmc@vger.kernel.org,
	Linux Memory Management List  <linux-mm@kvack.org>,
	linux-mtd@lists.infradead.org,  linux-nfs@vger.kernel.org,
	linux-rdma@vger.kernel.org,
	Linux-Renesas  <linux-renesas-soc@vger.kernel.org>,
	linux-scsi@vger.kernel.org,  linux-sctp@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	 linux-stm32@st-md-mailman.stormreply.com,
	linux-usb@vger.kernel.org,  linux-watchdog@vger.kernel.org,
	linux-wireless  <linux-wireless@vger.kernel. org>,
	Ne twork Development  <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org,  nouveau@lists.freedesktop.org,
	op-tee@lists.trustedfirmware.org,  oss-drivers@netronome.com,
	patches@opensource.cirrus.com,  rds-devel@oss.oracle.com,
	reiserfs-devel@vger.kernel.org,  samba-technical@lists.samba.org,
	selinux@vger.kernel.org,  target-devel@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	 usb-storage@lists.one-eyed-alien.net,
	 virtualization@lists.linux-foundation.org,
	wcn36xx@lists.infradead.org,  ,
	maintainer:X86, ARCHITECTURE, 32-BIT AND 64-BIT

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, dri-devel, Gustavo A. R. Silva,
	dm-devel, keyrings, GR-everest-linux-l2, maintainer:X86,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs, bridge,
	amd-gfx list, ARCHITECTURE, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, 32-BIT AND 64-BIT, Kees Cook, linux-arm-msm,
	intel-gfx, linux-can, linux-block, ceph-devel, Linux ARM,
	GR-Linux-NIC-Dev, LKML,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-decnet-user@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-input@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org,
	Linux Memory Management List  <linux-mm@kvack.org>,
	linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org,
	linux-rdma@vger.kernel.org,
	Linux-Renesas  <linux-renesas-soc@vger.kernel.org>,
	linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org,
	linux-wireless  <linux-wireless@vger.kernel. org>,
	Network Development  <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org,
	op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com,
	patches@opensource.cirrus.com, rds-devel@oss.oracle.com,
	reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org,
	selinux@vger.kernel.org, target-devel@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	usb-storage@lists.one-eyed-alien.net,
	virtualization@lists.linux-foundation.org,
	wcn36xx@lists.infradead.org,

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, 32-BIT AND 64-BIT, dri-devel,
	Gustavo A. R. Silva, dm-devel, keyrings, GR-everest-linux-l2,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs, bridge,
	amd-gfx list, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, Kees Cook, linux-arm-msm, intel-gfx,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-decnet-user@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-input@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org,
	Linux Memory Management List  <linux-mm@kvack.org>,
	linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org,
	linux-rdma@vger.kernel.org,
	Linux-Renesas  <linux-renesas-soc@vger.kernel.org>,
	linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org,
	linux-wireless  <linux-wireless@vger.kernel.org>,
	Network Development  <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org,
	op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com,
	patches@opensource.cirrus.com, rds-devel@oss.oracle.com,
	reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org,
	selinux@vger.kernel.org, target-devel@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	usb-storage@lists.one-eyed-alien.net,
	virtualization@lists.linux-foundation.org,
	wcn36xx@lists.infradead.org, ,
	linux-can, linux-block, ceph-devel, ARCHITECTURE, Linux ARM,
	GR-Linux-NIC-Dev, LKML, maintainer:X86

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
       [not found]           ` <CAKwvOdntVfXj2WRR5n6Kw7BfG7FdKpTeHeh5nPu5AzwVMhOHTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	linux-atm-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, dri-devel,
	Gustavo A. R. Silva, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
	keyrings-u79uwXL29TY76Z2rM5mHXA,
	GR-everest-linux-l2-eYqpPyKDWXRBDgjK7y7TUQ,
	linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
	devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA, 32-BIT AND 64-BIT,
	bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, amd-gfx list,
	cluster-devel-H+wXaHxf7aLQT0dZR+AlfA,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA,
	coreteam-Cap9r6Oaw4JrovVCs/uTlw,
	intel-wired-lan-qjLDD68F18P21nG7glBr7A, Kees Cook, linux-arm-msm,
	intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-can-u79uwXL29TY76Z2rM5mHXA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	ceph-devel-u79uwXL29TY76Z2rM5mHXA, Linux ARM

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, dri-devel, Gustavo A. R. Silva,
	dm-devel, keyrings, GR-everest-linux-l2, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, 32-BIT AND 64-BIT,
	bridge, amd-gfx list, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, Kees Cook, linux-arm-msm, intel-gfx, linux-can,
	linux-block, ceph-devel, Linux ARM, GR-Linux-NIC-Dev, LKML

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers; +Cc: alsa-devel, linux-atm-general, X86.ARCHITECTURE

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, dri-devel, Gustavo A. R. Silva,
	dm-devel, keyrings, GR-everest-linux-l2, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, 32-BIT AND 64-BIT,
	bridge, amd-gfx list, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, Kees Cook, linux-arm-msm, intel-gfx, linux-can,
	linux-block, ceph-devel, Linux ARM, GR-Linux-NIC-Dev, LKML

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, dri-devel, Gustavo A. R. Silva,
	dm-devel, keyrings, GR-everest-linux-l2, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, 32-BIT AND 64-BIT,
	bridge, amd-gfx list, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, Kees Cook, linux-arm-msm, intel-gfx, linux-can,
	linux-block, ceph-devel, Linux ARM, GR-Linux-NIC-Dev, LKML

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

?

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

?




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  1:46             ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-24  1:46 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, dri-devel, Gustavo A. R. Silva,
	dm-devel, keyrings, GR-everest-linux-l2, maintainer:X86,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs, bridge,
	amd-gfx list, ARCHITECTURE, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, 32-BIT AND 64-BIT, Kees Cook, linux-arm-msm,
	intel-gfx, linux-can, linux-block, ceph-devel, Linux ARM,
	GR-Linux-NIC-Dev, LKML,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-decnet-user@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-geode@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-hams@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i3c@lists.infradead.org, linux-ide@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-input@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
	linux-mmc@vger.kernel.org,
	Linux Memory Management List  <linux-mm@kvack.org>,
	linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org,
	linux-rdma@vger.kernel.org,
	Linux-Renesas  <linux-renesas-soc@vger.kernel.org>,
	linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-usb@vger.kernel.org, linux-watchdog@vger.kernel.org,
	linux-wireless  <linux-wireless@vger.kernel. org>,
	Network Development  <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, nouveau@lists.freedesktop.org,
	op-tee@lists.trustedfirmware.org, oss-drivers@netronome.com,
	patches@opensource.cirrus.com, rds-devel@oss.oracle.com,
	reiserfs-devel@vger.kernel.org, samba-technical@lists.samba.org,
	selinux@vger.kernel.org, target-devel@vger.kernel.org,
	tipc-discussion@lists.sourceforge.net,
	usb-storage@lists.one-eyed-alien.net,
	virtualization@lists.linux-foundation.org,
	wcn36xx@lists.infradead.org,

On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/  
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

😍

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
       [not found]             ` <CAKwvOdkxY4pXN4wbYM_B1cLjr8uX6sQ2iS=m=rRGL_TkJQUFZw@mail.gmail.com>
@ 2020-11-24  2:29               ` Joe Perches
  0 siblings, 0 replies; 1306+ messages in thread
From: Joe Perches @ 2020-11-24  2:29 UTC (permalink / raw)
  To: Nick Desaulniers, Jakub Kicinski, Kees Cook
  Cc: Gustavo A. R. Silva, LKML, linux-acpi, James Bottomley,
	Nathan Chancellor, fthain, clang-built-linux

On Mon, 2020-11-23 at 18:05 -0800, Nick Desaulniers wrote:
> (minus all of these lists, except LKML, CBL, and ACPI)
> 
> On Mon, Nov 23, 2020 at 5:46 PM Jakub Kicinski <kuba@kernel.org> wrote:
> 
> > On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> > > On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> > > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > > > If none of the 140 patches here fix a real bug, and there is no
> > change
> > > > > to machine code then it sounds to me like a W=2 kind of a warning.
> > > > 
> > > > FWIW, this series has found at least one bug so far:
> > > > 
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> > 
> > > 
> > > So looks like the bulk of these are:
> > > switch (x) {
> > >   case 0:
> > >     ++x;
> > >   default:
> > >     break;
> > > }
> > > 
> > > I have a patch that fixes those up for clang:
> > > https://reviews.llvm.org/D91895

Pity.  It's a good warning.  gcc not warning is a mistake in my view.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24  1:05                     ` Joe Perches
                                         ` (10 preceding siblings ...)
  (?)
@ 2020-11-24  2:48                       ` Finn Thain
  -1 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: Miguel Ojeda, James Bottomley, Kees Cook, Jakub Kicinski,
	Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: Miguel Ojeda, James Bottomley, Kees Cook, Jakub Kicinski,
	Gustavo A. R. Silva, linux-kernel, alsa-devel, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, devel, dm-devel, drbd-dev,
	dri-devel, GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, linux-watchdog, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, Miguel Ojeda, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: intel-wired-lan


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12 at nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8 at nippy.intranet/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: cluster-devel.redhat.com


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12 at nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8 at nippy.intranet/



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24  2:48                       ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24  2:48 UTC (permalink / raw)
  To: Joe Perches
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening


On Mon, 23 Nov 2020, Joe Perches wrote:

> On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> > it's not for me to prove that such patches don't affect code 
> > generation. That's for the patch author and (unfortunately) for 
> > reviewers.
> 
> Ideally, that proof would be provided by the compilation system itself 
> and not patch authors nor reviewers nor maintainers.
> 
> Unfortunately gcc does not guarantee repeatability or deterministic 
> output. To my knowledge, neither does clang.
> 

Yes, I've said the same thing myself. But having attempted it, I now think 
this is a hard problem. YMMV.

https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2004281017310.12@nippy.intranet/
https://lore.kernel.org/linux-scsi/alpine.LNX.2.22.394.2005211358460.8@nippy.intranet/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 126/141] slimbus: messaging: Fix fall-through warnings for Clang
  2020-11-20 18:39   ` Gustavo A. R. Silva
  (?)
@ 2020-11-24 10:48   ` Srinivas Kandagatla
  2020-11-24 14:38     ` Gustavo A. R. Silva
  -1 siblings, 1 reply; 1306+ messages in thread
From: Srinivas Kandagatla @ 2020-11-24 10:48 UTC (permalink / raw)
  To: Gustavo A. R. Silva; +Cc: alsa-devel, linux-kernel, linux-hardening



On 20/11/2020 18:39, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---


Applied thanks,

srini

>   drivers/slimbus/messaging.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c
> index d5879142dbef..f2b5d347d227 100644
> --- a/drivers/slimbus/messaging.c
> +++ b/drivers/slimbus/messaging.c
> @@ -258,6 +258,7 @@ int slim_xfer_msg(struct slim_device *sbdev, struct slim_val_inf *msg,
>   	case SLIM_MSG_MC_REQUEST_CLEAR_INFORMATION:
>   	case SLIM_MSG_MC_CLEAR_INFORMATION:
>   		txn->rl += msg->num_bytes;
> +		break;
>   	default:
>   		break;
>   	}
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 001/141] afs: Fix fall-through warnings for Clang
  2020-11-23 16:10   ` David Howells
  2020-11-23 16:51     ` Joe Perches
@ 2020-11-24 13:21     ` David Howells
  1 sibling, 0 replies; 1306+ messages in thread
From: David Howells @ 2020-11-24 13:21 UTC (permalink / raw)
  To: Joe Perches
  Cc: dhowells, Gustavo A. R. Silva, linux-afs, linux-kernel, linux-hardening

Joe Perches <joe@perches.com> wrote:

> > My preference would be to fall through.  The case number is the state machine
> > state, as indexed by call->unmarshall.
> 
> Then ideally the state machine states should be enums and not numbers
> and the compiler should use a default block for unhandled states right?
> 
> Is code like call->marshall++ a common style for kernel state machines?
> Perhaps not.

How the value is interpreted is unique to each delivery function, of which
there are a number, since it counts out the separate parts of the xdr encoding
for that particular RPC request or reply block.

Maybe "state machine" isn't the right term.

David


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  2020-11-20 18:37   ` Gustavo A. R. Silva
@ 2020-11-24 14:25     ` Ulf Hansson
  -1 siblings, 0 replies; 1306+ messages in thread
From: Ulf Hansson @ 2020-11-24 14:25 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Michal Simek, Adrian Hunter, Linux ARM, linux-mmc,
	Linux Kernel Mailing List, linux-hardening

On Fri, 20 Nov 2020 at 19:37, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 829ccef87426..1f7e42b6ced5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 8 Taps are available */
>                 tap_max = 8;
> +               break;
>         default:
>                 break;
>         }
> @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 30 Taps are available */
>                 tap_max = 30;
> +               break;
>         default:
>                 break;
>         }
> @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 8 Taps are available */
>                 tap_max = 8;
> +               break;
>         default:
>                 break;
>         }
> @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 30 Taps are available */
>                 tap_max = 30;
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
@ 2020-11-24 14:25     ` Ulf Hansson
  0 siblings, 0 replies; 1306+ messages in thread
From: Ulf Hansson @ 2020-11-24 14:25 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: linux-mmc, Linux Kernel Mailing List, Michal Simek,
	linux-hardening, Adrian Hunter, Linux ARM

On Fri, 20 Nov 2020 at 19:37, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
>
> In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> warnings by explicitly adding multiple break statements instead of
> letting the code fall through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 829ccef87426..1f7e42b6ced5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -627,6 +627,7 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 8 Taps are available */
>                 tap_max = 8;
> +               break;
>         default:
>                 break;
>         }
> @@ -695,6 +696,7 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 30 Taps are available */
>                 tap_max = 30;
> +               break;
>         default:
>                 break;
>         }
> @@ -760,6 +762,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 8 Taps are available */
>                 tap_max = 8;
> +               break;
>         default:
>                 break;
>         }
> @@ -831,6 +834,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw *hw, int degrees)
>         case MMC_TIMING_MMC_HS200:
>                 /* For 200MHz clock, 30 Taps are available */
>                 tap_max = 30;
> +               break;
>         default:
>                 break;
>         }
> --
> 2.27.0
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 052/141] security: keys: Fix fall-through warnings for Clang
  2020-11-23 22:54   ` Jarkko Sakkinen
@ 2020-11-24 14:30     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:30 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: David Howells, James Morris, Serge E. Hallyn, keyrings,
	linux-security-module, linux-kernel, linux-hardening

On Tue, Nov 24, 2020 at 12:54:02AM +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 20, 2020 at 12:32:20PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  security/keys/process_keys.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> > index 1fe8b934f656..e3d79a7b6db6 100644
> > --- a/security/keys/process_keys.c
> > +++ b/security/keys/process_keys.c
> > @@ -783,6 +783,7 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
> >  				if (need_perm != KEY_AUTHTOKEN_OVERRIDE &&
> >  				    need_perm != KEY_DEFER_PERM_CHECK)
> >  					goto invalid_key;
> > +				break;
> >  			case 0:
> >  				break;
> >  			}
> > -- 
> > 2.27.0
> > 
> > 
> 
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

Thank you, Jarkko.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 053/141] selinux: Fix fall-through warnings for Clang
  2020-11-23 23:31   ` Paul Moore
@ 2020-11-24 14:30     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:30 UTC (permalink / raw)
  To: Paul Moore
  Cc: Stephen Smalley, Eric Paris, selinux, linux-kernel, linux-hardening

On Mon, Nov 23, 2020 at 06:31:52PM -0500, Paul Moore wrote:
> On Fri, Nov 20, 2020 at 1:32 PM Gustavo A. R. Silva
> <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  security/selinux/hooks.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Merged into selinux/next, thanks.

Thanks, Paul.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
  2020-11-22 22:03     ` Sam Ravnborg
@ 2020-11-24 14:34       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:34 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: David Airlie, Daniel Vetter, linux-kernel, dri-devel, linux-hardening

On Sun, Nov 22, 2020 at 11:03:58PM +0100, Sam Ravnborg wrote:
> On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, also applied to drm-misc-next.

Thank you, Sam.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang
@ 2020-11-24 14:34       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:34 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: David Airlie, dri-devel, linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 11:03:58PM +0100, Sam Ravnborg wrote:
> On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, also applied to drm-misc-next.

Thank you, Sam.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 086/141] hwmon: (corsair-cpro) Fix fall-through warnings for Clang
  2020-11-21 18:50   ` Guenter Roeck
  2020-11-21 20:00     ` Joe Perches
@ 2020-11-24 14:35     ` Gustavo A. R. Silva
  1 sibling, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:35 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Marius Zachmann, Jean Delvare, linux-hwmon, linux-kernel,
	linux-hardening

On Sat, Nov 21, 2020 at 10:50:10AM -0800, Guenter Roeck wrote:
> On Fri, Nov 20, 2020 at 12:36:04PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Acked-by: Guenter Roeck <linux@roeck-us.net>

Thanks, Guenter.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
  2020-11-24 14:25     ` Ulf Hansson
@ 2020-11-24 14:36       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:36 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Michal Simek, Adrian Hunter, Linux ARM, linux-mmc,
	Linux Kernel Mailing List, linux-hardening

On Tue, Nov 24, 2020 at 03:25:32PM +0100, Ulf Hansson wrote:
> On Fri, 20 Nov 2020 at 19:37, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied for next, thanks!

Thank you, Uffe.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 098/141] mmc: sdhci-of-arasan: Fix fall-through warnings for Clang
@ 2020-11-24 14:36       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:36 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: linux-mmc, Linux Kernel Mailing List, Michal Simek,
	linux-hardening, Adrian Hunter, Linux ARM

On Tue, Nov 24, 2020 at 03:25:32PM +0100, Ulf Hansson wrote:
> On Fri, 20 Nov 2020 at 19:37, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> >
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
> > warnings by explicitly adding multiple break statements instead of
> > letting the code fall through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied for next, thanks!

Thank you, Uffe.
--
Gustavo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 108/141] netfilter: ipt_REJECT: Fix fall-through warnings for Clang
  2020-11-20 22:49   ` Florian Westphal
@ 2020-11-24 14:37     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:37 UTC (permalink / raw)
  To: Florian Westphal
  Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, David S. Miller,
	Alexey Kuznetsov, Hideaki YOSHIFUJI, Jakub Kicinski,
	netfilter-devel, coreteam, netdev, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 11:49:05PM +0100, Florian Westphal wrote:
> Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> 
> Acked-by: Florian Westphal <fw@strlen.de>

Thanks, Florian.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 126/141] slimbus: messaging: Fix fall-through warnings for Clang
  2020-11-24 10:48   ` Srinivas Kandagatla
@ 2020-11-24 14:38     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:38 UTC (permalink / raw)
  To: Srinivas Kandagatla; +Cc: alsa-devel, linux-kernel, linux-hardening

On Tue, Nov 24, 2020 at 10:48:04AM +0000, Srinivas Kandagatla wrote:
> 
> 
> On 20/11/2020 18:39, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> 
> 
> Applied thanks,

Thank you, Srini.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 131/141] tpm: Fix fall-through warnings for Clang
  2020-11-23 22:53     ` Jarkko Sakkinen
@ 2020-11-24 14:40       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:40 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Peter Huewe, Jason Gunthorpe, linux-integrity, linux-kernel,
	linux-hardening

On Tue, Nov 24, 2020 at 12:53:22AM +0200, Jarkko Sakkinen wrote:
> On Tue, Nov 24, 2020 at 12:52:31AM +0200, Jarkko Sakkinen wrote:
> > On Fri, Nov 20, 2020 at 12:40:14PM -0600, Gustavo A. R. Silva wrote:
> > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > > by explicitly adding a break statement instead of letting the code fall
> > > through to the next case.
> > > 
> > > Link: https://github.com/KSPP/linux/issues/115
> > > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > > ---
> > >  drivers/char/tpm/eventlog/tpm1.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/char/tpm/eventlog/tpm1.c b/drivers/char/tpm/eventlog/tpm1.c
> > > index 2c96977ad080..8aa9057601d6 100644
> > > --- a/drivers/char/tpm/eventlog/tpm1.c
> > > +++ b/drivers/char/tpm/eventlog/tpm1.c
> > > @@ -210,6 +210,7 @@ static int get_event_name(char *dest, struct tcpa_event *event,
> > >  		default:
> > >  			break;
> > >  		}
> > > +		break;
> > >  	default:
> > >  		break;
> > >  	}
> > > -- 
> > > 2.27.0
> > > 
> > > 
> > 
> > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
> > 
> > Who is picking these patches?

I can take it in my tree for 5.11 if people are OK with that. :)

> > 
> > /Jarkko
> 
> I mean
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

Thanks, Jarkko.
--
Gustavo


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  2020-11-22 22:05     ` Sam Ravnborg
@ 2020-11-24 14:44       ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:44 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Andres Salomon, Bartlomiej Zolnierkiewicz, linux-fbdev,
	linux-kernel, dri-devel, linux-geode, linux-hardening

Hi Sam,

On Sun, Nov 22, 2020 at 11:05:40PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, applied this and the following patch to drm-misc-next.
> Looks forward to have this warning enabled.
> 
> One can only wonder how many hours will be saved by lettting the
> compiler tell you a break is missing. This is the kind of bugs you can
> stare you blind at.

Absolutely. We'll never know how many bugs this will catch in the
future decades of kernel development, before the code is even
committed/submitted. :)

Thanks!
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
@ 2020-11-24 14:44       ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:44 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: linux-fbdev, Bartlomiej Zolnierkiewicz, linux-geode, dri-devel,
	linux-kernel, linux-hardening, Andres Salomon

Hi Sam,

On Sun, Nov 22, 2020 at 11:05:40PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Thanks, applied this and the following patch to drm-misc-next.
> Looks forward to have this warning enabled.
> 
> One can only wonder how many hours will be saved by lettting the
> compiler tell you a break is missing. This is the kind of bugs you can
> stare you blind at.

Absolutely. We'll never know how many bugs this will catch in the
future decades of kernel development, before the code is even
committed/submitted. :)

Thanks!
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 141/141] Input: libps2 - Fix fall-through warnings for Clang
  2020-11-23  6:16   ` Dmitry Torokhov
@ 2020-11-24 14:44     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:44 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, linux-hardening

On Sun, Nov 22, 2020 at 10:16:05PM -0800, Dmitry Torokhov wrote:
> On Fri, Nov 20, 2020 at 12:41:12PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a
> > warning by replacing a /* Fall through */ comment with the new
> > pseudo-keyword macro fallthrough.
> > 
> > Notice that Clang doesn't recognize /* Fall through */ comments as
> > implicit fall-through markings.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> 
> Applied, thank you.

Thank you, Dmitry.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 20:03   ` Jason Gunthorpe
                       ` (10 preceding siblings ...)
  (?)
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, linux-arm-kernel, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, linux-crypto,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, linux-mm, linux-mtd, linux-nfs,
	linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, netdev, netfilter-devel, nouveau, op-tee,
	oss-drivers, patches, rds-devel, reiserfs-devel, samba-technical,
	selinux, target-devel, tipc-discussion, usb-storage,
	virtualization, wcn36xx, x86, xen-devel, linux-hardening,
	Nick Desaulniers, Nathan Chancellor, Miguel Ojeda, Joe Perches,
	Kees Cook

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	virtualization, Nathan Chancellor, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, samba-technical,
	linux-i3c, linux1394-devel, linux-afs, usb-storage, target-devel,
	devel, linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module, amd-gfx,
	linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	target-devel, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, Kees Cook, linux-mm, netdev, linux-decnet-user,
	linux-mmc, linux-kernel, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, virtualization,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	Kees Cook, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, linux-crypto, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 20:38   ` Mark Brown
                       ` (10 preceding siblings ...)
  (?)
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  -1 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-kernel, linux-crypto, linux-sctp, Nathan Chancellor,
	linux-hardening, usb-storage, linux-block, linux-security-module,
	bridge, GR-Linux-NIC-Dev, rds-devel, dri-devel, linux-media,
	wcn36xx, linux-wireless, linux-mediatek, reiserfs-devel,
	oss-drivers, linux-arm-kernel, alsa-devel, virtualization,
	Joe Perches, patches, linux-gpio, linux-hwmon, linux-cifs,
	coreteam, Kees Cook, Nick Desaulniers, linux-scsi, linux-afs,
	netfilter-devel, linux-geode, drbd-dev, linux-ext4, linux-hams,
	target-devel, samba-technical, tipc-discussion, linux-stm32,
	linux-renesas-soc, linux-input, amd-gfx, linux-nfs, devel,
	selinux, linux-atm-general, linux-iio, linux-i3c, Miguel Ojeda,
	linux-can, linux-integrity, GR-everest-linux-l2, keyrings,
	intel-wired-lan, linux-usb, nouveau, x86, xen-devel, linux-mm,
	cluster-devel, linux1394-devel, linux-decnet-user, op-tee,
	linux-ide, intel-gfx, linux-acpi, dm-devel, linux-watchdog,
	linux-rdma, linux-mtd, ceph-devel, linux-arm-msm, linux-mmc,
	linux-fbdev, netdev

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, linux-mmc, x86, dri-devel, virtualization,
	linux-mm, linux-sctp, target-devel, linux-mtd, linux-hardening,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-ide, alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, linux-watchdog, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, drbd-dev, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-mmc, linux-nfs, GR-Linux-NIC-Dev, nouveau,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, linux-mmc, x86, dri-devel, virtualization,
	linux-mm, linux-sctp, target-devel, linux-mtd, linux-hardening,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, linux-mmc, x86, dri-devel, virtualization,
	linux-mm, linux-sctp, target-devel, linux-mtd, linux-hardening,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 14:47     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: alsa-devel, linux-atm-general, dm-devel, usb-storage,
	Nick Desaulniers, x86, dri-devel, virtualization, linux-mm,
	linux-sctp, target-devel, linux-mtd, linux-hardening, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	bridge, ceph-devel, amd-gfx, linux-stm32, cluster-devel,
	oss-drivers, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, tipc-discussion, linux-ext4, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	samba-technical, linux-fbdev, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, linux-ide,
	linux-decnet-user, patches, linux-usb, linux-wireless,
	linux-kernel, linux-iio, linux-renesas-soc,
	linux-security-module, keyrings, netfilter-devel, linux-crypto,
	netdev, Joe Perches, linux-integrity, GR-everest-linux-l2

On Mon, Nov 23, 2020 at 08:38:46PM +0000, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>       commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 117/141] rtl8xxxu: Fix fall-through warnings for Clang
  2020-11-20 21:39   ` Jes Sorensen
@ 2020-11-24 16:09     ` Gustavo A. R. Silva
  0 siblings, 0 replies; 1306+ messages in thread
From: Gustavo A. R. Silva @ 2020-11-24 16:09 UTC (permalink / raw)
  To: Jes Sorensen
  Cc: Kalle Valo, David S. Miller, Jakub Kicinski, linux-wireless,
	netdev, linux-kernel, linux-hardening

On Fri, Nov 20, 2020 at 04:39:42PM -0500, Jes Sorensen wrote:
> On 11/20/20 1:38 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix
> > multiple warnings by replacing /* fall through */ comments with
> > the new pseudo-keyword macro fallthrough; instead of letting the
> > code fall through to the next case.
> > 
> > Notice that Clang doesn't recognize /* fall through */ comments as
> > implicit fall-through markings.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> While I wasn't CC'ed on the cover-letter I see Jakub also raised issues
> about this unnecessary patch noise.
> 
> Quite frankly, this seems to be patch churn for the sake of patch churn.
> If clang is broken, fix clang instead.

Just notice that the idea behind this and the following patch is exactly
the same:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=3f95e92c8a8516b745594049dfccc8c5f8895eea

I could resend this same patch with a different changelog text, but I
don't think such a thing is necessary. However, if people prefer that
approach, just let me know and I can do it.

Thanks
--
Gustavo

> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > index 5cd7ef3625c5..afc97958fa4d 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > @@ -1145,7 +1145,7 @@ void rtl8xxxu_gen1_config_channel(struct ieee80211_hw *hw)
> >  	switch (hw->conf.chandef.width) {
> >  	case NL80211_CHAN_WIDTH_20_NOHT:
> >  		ht = false;
> > -		/* fall through */
> > +		fallthrough;
> >  	case NL80211_CHAN_WIDTH_20:
> >  		opmode |= BW_OPMODE_20MHZ;
> >  		rtl8xxxu_write8(priv, REG_BW_OPMODE, opmode);
> > @@ -1272,7 +1272,7 @@ void rtl8xxxu_gen2_config_channel(struct ieee80211_hw *hw)
> >  	switch (hw->conf.chandef.width) {
> >  	case NL80211_CHAN_WIDTH_20_NOHT:
> >  		ht = false;
> > -		/* fall through */
> > +		fallthrough;
> >  	case NL80211_CHAN_WIDTH_20:
> >  		rf_mode_bw |= WMAC_TRXPTCL_CTL_BW_20;
> >  		subchannel = 0;
> > @@ -1741,11 +1741,11 @@ static int rtl8xxxu_identify_chip(struct rtl8xxxu_priv *priv)
> >  		case 3:
> >  			priv->ep_tx_low_queue = 1;
> >  			priv->ep_tx_count++;
> > -			/* fall through */
> > +			fallthrough;
> >  		case 2:
> >  			priv->ep_tx_normal_queue = 1;
> >  			priv->ep_tx_count++;
> > -			/* fall through */
> > +			fallthrough;
> >  		case 1:
> >  			priv->ep_tx_high_queue = 1;
> >  			priv->ep_tx_count++;
> > 
> 

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang
  2020-11-24 14:44       ` Gustavo A. R. Silva
  (?)
@ 2020-11-24 20:58       ` deloptes
  -1 siblings, 0 replies; 1306+ messages in thread
From: deloptes @ 2020-11-24 20:58 UTC (permalink / raw)
  To: linux-kernel; +Cc: dri-devel, linux-geode

Gustavo A. R. Silva wrote:

> Absolutely. We'll never know how many bugs this will catch in the
> future decades of kernel development, before the code is even
> committed/submitted. :)

A little bit OT here, but what are the plans for Geode in general as there
was discussion around the fact that Debian will be one of the last
platforms to drop i386 arch support.

Thank you


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24  1:32           ` Nick Desaulniers
                               ` (11 preceding siblings ...)
  (?)
@ 2020-11-24 21:25             ` Kees Cook
  -1 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Jakub Kicinski, Gustavo A. R. Silva, LKML, alsa-devel,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, Linux Memory Management List, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nathan Chancellor, Miguel Ojeda,
	Joe Perches

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Jakub Kicinski, Gustavo A. R. Silva, LKML, alsa-devel,
	amd-gfx list, bridge, ceph-devel, cluster-devel, coreteam, devel,
	dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	linux-decnet-user, linux-ext4, linux-fbdev, linux-geode,
	linux-gpio, linux-hams, linux-hwmon, linux-i3c, linux-ide,
	linux-iio, linux-input, linux-integrity, linux-mediatek,
	linux-media, linux-mmc, Linux Memory Management List, linux-mtd,
	linux-nfs, linux-rdma, Linux-Renesas, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nathan Chancellor, Miguel Ojeda,
	Joe Perches

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, LKML,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, target-devel, devel,
	linux-cifs, rds-devel, linux-scsi, linux-rdma, oss-drivers,
	bridge, linux-security-module, amd-gfx list, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams, ceph-devel,
	virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ at mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:25             ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:25 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux Memory Management List, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=Kr_CQ@mail.gmail.com/
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
>     ++x;
>   default:
>     break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895

I still think this isn't right -- it's a case statement that runs off
the end without an explicit flow control determination. I think Clang is
right to warn for these, and GCC should also warn.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 16:31                       ` James Bottomley
                                           ` (9 preceding siblings ...)
  (?)
@ 2020-11-24 21:32                         ` Kees Cook
  -1 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: Gustavo A. R. Silva, Joe Perches, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-mm, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, devel, linux-cifs, rds-devel,
	linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, netdev, linux-decnet-user,
	linux-wireless, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, linux-integrity, x86,
	linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 21:32                         ` Kees Cook
  0 siblings, 0 replies; 1306+ messages in thread
From: Kees Cook @ 2020-11-24 21:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> Really, no ... something which produces no improvement has no value at
> all ... we really shouldn't be wasting maintainer time with it because
> it has a cost to merge.  I'm not sure we understand where the balance
> lies in value vs cost to merge but I am confident in the zero value
> case.

What? We can't measure how many future bugs aren't introduced because the
kernel requires explicit case flow-control statements for all new code.

We already enable -Wimplicit-fallthrough globally, so that's not the
discussion. The issue is that Clang is (correctly) even more strict
than GCC for this, so these are the remaining ones to fix for full Clang
coverage too.

People have spent more time debating this already than it would have
taken to apply the patches. :)

This is about robustness and language wrangling. It's a big code-base,
and this is the price of our managing technical debt for permanent
robustness improvements. (The numbers I ran from Gustavo's earlier
patches were that about 10% of the places adjusted were identified as
legitimate bugs being fixed. This final series may be lower, but there
are still bugs being found from it -- we need to finish this and shut
the door on it for good.)

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24 21:32                         ` Kees Cook
                                             ` (9 preceding siblings ...)
  (?)
@ 2020-11-24 22:24                           ` Finn Thain
  -1 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, linux-ext4,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-geode, linux-can, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams, ceph-devel,
	virtualization, linux-arm-kernel, linux-hwmon, x86, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	patches, Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	patches, Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, linux-integrity, x86,
	linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, devel, linux-cifs, rds-devel,
	linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, linux-mm, linux-media, linux-watchdog, selinux,
	linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, netfilter-devel,
	linux-integrity, x86, linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, linux-integrity, x86,
	linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, linux-integrity, x86,
	linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	patches, Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 22:24                           ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 22:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, Nathan Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, linux-mm, netdev, linux-decnet-user,
	samba-technical, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	patches, Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 24 Nov 2020, Kees Cook wrote:

> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value at 
> > all ... we really shouldn't be wasting maintainer time with it because 
> > it has a cost to merge.  I'm not sure we understand where the balance 
> > lies in value vs cost to merge but I am confident in the zero value 
> > case.
> 
> What? We can't measure how many future bugs aren't introduced because 
> the kernel requires explicit case flow-control statements for all new 
> code.
> 

These statements are not "missing" unless you presume that code written 
before the latest de facto language spec was written should somehow be 
held to that spec.

If the 'fallthrough' statement is not part of the latest draft spec then 
we should ask why not before we embrace it. Being that the kernel still 
prefers -std=gnu89 you might want to consider what has prevented 
-std=gnu99 or -std=gnu2x etc.

> We already enable -Wimplicit-fallthrough globally, so that's not the 
> discussion. The issue is that Clang is (correctly) even more strict than 
> GCC for this, so these are the remaining ones to fix for full Clang 
> coverage too.
> 

Seems to me you should be patching the compiler.

When you have consensus among the language lawyers you'll have more 
credibility with those being subjected to enforcement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24 22:24                           ` Finn Thain
                                               ` (10 preceding siblings ...)
  (?)
@ 2020-11-24 23:15                             ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-watchdog, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, Linux-MM, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	Linux ARM, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, Network Development,
	linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, Linux Crypto Mailing List, Jonathan Cameron,
	patches, Joe Perches, netfilter-devel, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:15                             ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:15 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 11:24 PM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> These statements are not "missing" unless you presume that code written
> before the latest de facto language spec was written should somehow be
> held to that spec.

There is no "language spec" the kernel adheres to. Even if it did,
kernel code is not frozen. If an improvement is found, it should be
applied.

> If the 'fallthrough' statement is not part of the latest draft spec then
> we should ask why not before we embrace it. Being that the kernel still
> prefers -std=gnu89 you might want to consider what has prevented
> -std=gnu99 or -std=gnu2x etc.

The C standard has nothing to do with this. We use compiler extensions
of several kinds, for many years. Even discounting those extensions,
the kernel is not even conforming to C due to e.g. strict aliasing. I
am not sure what you are trying to argue here.

But, since you insist: yes, the `fallthrough` attribute is in the
current C2x draft.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24  0:58                   ` Finn Thain
                                       ` (10 preceding siblings ...)
  (?)
@ 2020-11-24 23:46                     ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: James Bottomley, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, Nathan Chancellor, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel, linux-renesas-soc,
	linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:46                     ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-24 23:46 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	James Bottomley, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi,
	Nathan Chancellor, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, nouveau, linux-hams, ceph-devel, virtualization,
	Linux ARM, linux-hwmon, linux-watchdog, linux-nfs,
	GR-Linux-NIC-Dev, tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-kernel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Tue, Nov 24, 2020 at 1:58 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> What I meant was that you've used pessimism as if it was fact.

"future mistakes that it might prevent" is neither pessimism nor states a fact.

> For example, "There is no way to guess what the effect would be if the
> compiler trained programmers to add a knee-jerk 'break' statement to avoid
> a warning".

It is only knee-jerk if you think you are infallible.

> Moreover, what I meant was that preventing programmer mistakes is a
> problem to be solved by development tools

This warning comes from a development tool -- the compiler.

> The idea that retro-fitting new
> language constructs onto mature code is somehow necessary to "prevent
> future mistakes" is entirely questionable.

The kernel is not a frozen codebase.

Further, "mature code vs. risk of change" arguments don't apply here
because the semantics of the program and binary output isn't changing.

> Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that
> leads to well-intentioned patches that cause regressions, it is partly on
> you.

Again: adding a `fallthrough` does not change the program semantics.
If you are a maintainer and want to cross-check, compare the codegen.

> Have you ever considered the overall cost of the countless
> -Wpresume-incompetence flags?

Yeah: negative. On the other hand, the overall cost of the countless
-fI-am-infallible flags is very noticeable.

> Perhaps you pay the power bill for a build farm that produces logs that
> no-one reads? Perhaps you've run git bisect, knowing that the compiler
> messages are not interesting? Or compiled software in using a language
> that generates impenetrable messages? If so, here's a tip:
>
> # grep CFLAGS /etc/portage/make.conf
> CFLAGS="... -Wno-all -Wno-extra ..."
> CXXFLAGS="${CFLAGS}"
>
> Now allow me some pessimism: the hardware upgrades, gigawatt hours and
> wait time attributable to obligatory static analyses are a net loss.

If you really believe compiler warnings and static analysis are
useless and costly, I think there is not much point in continuing the
discussion.

> No, it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.

I was not asking you to prove it. I am stating that proving it is very easy.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24 23:15                             ` Miguel Ojeda
                                                 ` (9 preceding siblings ...)
  (?)
@ 2020-11-24 23:53                               ` Finn Thain
  -1 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-watchdog, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, Linux-MM, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	Linux ARM, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, Network Development,
	linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, Linux Crypto Mailing List, Jonathan Cameron,
	patches, Joe Perches, netfilter-devel, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: intel-wired-lan


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: cluster-devel.redhat.com


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-24 23:53                               ` Finn Thain
  0 siblings, 0 replies; 1306+ messages in thread
From: Finn Thain @ 2020-11-24 23:53 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening


On Wed, 25 Nov 2020, Miguel Ojeda wrote:

> 
> The C standard has nothing to do with this. We use compiler extensions 
> of several kinds, for many years. Even discounting those extensions, the 
> kernel is not even conforming to C due to e.g. strict aliasing. I am not 
> sure what you are trying to argue here.
> 

I'm saying that supporting the official language spec makes more sense 
than attempting to support a multitude of divergent interpretations of the 
spec (i.e. gcc, clang, coverity etc.)

I'm also saying that the reason why we use -std=gnu89 is that existing 
code was written in that language, not in ad hoc languages comprised of 
collections of extensions that change with every release.

> But, since you insist: yes, the `fallthrough` attribute is in the 
> current C2x draft.
> 

Thank you for checking. I found a free version that's only 6 weeks old:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2583.pdf

It will be interesting to see whether 6.7.11.5 changes once the various 
implementations reach agreement.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 20:37                       ` James Bottomley
                                           ` (11 preceding siblings ...)
  (?)
@ 2020-11-25  0:32                         ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Jakub Kicinski, Gustavo A. R. Silva, linux-kernel,
	alsa-devel, amd-gfx, bridge, ceph-devel, cluster-devel, coreteam,
	devel, dm-devel, drbd-dev, dri-devel, GR-everest-linux-l2,
	GR-Linux-NIC-Dev, intel-gfx, intel-wired-lan, keyrings,
	linux1394-devel, linux-acpi, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, linux-fbdev, linux-geode, linux-gpio,
	linux-hams, linux-hwmon, linux-i3c, linux-ide, linux-iio,
	linux-input, linux-integrity, linux-mediatek,
	Linux Media Mailing List, linux-mmc, Linux-MM, linux-mtd,
	linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi, linux-sctp,
	linux-security-module, linux-stm32, linux-usb, linux-watchdog,
	linux-wireless, Network Development, netfilter-devel, nouveau,
	op-tee, oss-drivers, patches, rds-devel, reiserfs-devel,
	samba-technical, selinux, target-devel, tipc-discussion,
	usb-storage, virtualization, wcn36xx,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Nathan Chancellor, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, linux-watchdog, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, Ext4 Developers List, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-geode,
	linux-can, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, ceph-devel, virtualization,
	target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc, linux-kernel,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, linux-renesas-soc, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel



^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  0:32                         ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  0:32 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, Gustavo A. R. Silva,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	linux-kernel, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

^ permalink raw reply related	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24 23:53                               ` Finn Thain
                                                   ` (10 preceding siblings ...)
  (?)
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  -1 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: Kees Cook, James Bottomley, Gustavo A. R. Silva, Joe Perches,
	Jakub Kicinski, alsa-devel, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, tipc-discussion, Ext4 Developers List,
	Linux Media Mailing List, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, linux-renesas-soc, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, linux-watchdog, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, Linux-MM, Linux Media Mailing List, Kees Cook,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Nathan Chancellor, linux-can,
	Linux ARM, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, nouveau, Network Development,
	linux-decnet-user, samba-technical, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, Linux Crypto Mailing List, Jonathan Cameron,
	patches, Joe Perches, netfilter-devel, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  1:05                                 ` Miguel Ojeda
  0 siblings, 0 replies; 1306+ messages in thread
From: Miguel Ojeda @ 2020-11-25  1:05 UTC (permalink / raw)
  To: Finn Thain
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	linux-wireless, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, James Bottomley, linux-ide, dm-devel,
	keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, drbd-dev, devel, linux-cifs,
	rds-devel, linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, linux-mmc, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	virtualization, netfilter-devel, Linux Media Mailing List,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	Nick Desaulniers, linux-watchdog, GR-Linux-NIC-Dev, Linux-MM,
	Network Development, linux-decnet-user, samba-technical,
	linux-kernel, linux-renesas-soc, linux-security-module,
	linux-usb, tipc-discussion, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-nfs,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Wed, Nov 25, 2020 at 12:53 AM Finn Thain <fthain@telegraphics.com.au> wrote:
>
> I'm saying that supporting the official language spec makes more sense
> than attempting to support a multitude of divergent interpretations of the
> spec (i.e. gcc, clang, coverity etc.)

Making the kernel strictly conforming is a ship that sailed long ago,
for several reasons. Anyway, supporting several compilers and other
tools, regardless of extensions, is valuable.

> I'm also saying that the reason why we use -std=gnu89 is that existing
> code was written in that language, not in ad hoc languages comprised of
> collections of extensions that change with every release.

No, we aren't particularly tied to `gnu89` or anything like that. We
could actually go for `gnu11` already, since the minimum GCC and Clang
support it. Even if a bit of code needs fixing, that shouldn't be a
problem if someone puts the work.

In other words, the kernel code is not frozen, nor are the features it
uses from compilers. They do, in fact, change from time to time.

> Thank you for checking. I found a free version that's only 6 weeks old:

You're welcome! There are quite a few new attributes coming, mostly
following C++ ones.

> It will be interesting to see whether 6.7.11.5 changes once the various
> implementations reach agreement.

Not sure what you mean. The standard does not evolve through
implementations' agreement (although standardizing existing practice
is one of the best arguments to back a change).

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 127/141] staging: qlge: Fix fall-through warnings for Clang
  2020-11-20 18:39   ` Gustavo A. R. Silva
@ 2020-11-25  4:42     ` Benjamin Poirier
  -1 siblings, 0 replies; 1306+ messages in thread
From: Benjamin Poirier @ 2020-11-25  4:42 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Manish Chopra, Greg Kroah-Hartman, GR-Linux-NIC-Dev, netdev,
	devel, linux-kernel, linux-hardening

On 2020-11-20 12:39 -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/staging/qlge/qlge_main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
> index 27da386f9d87..c41b1373dcf8 100644
> --- a/drivers/staging/qlge/qlge_main.c
> +++ b/drivers/staging/qlge/qlge_main.c
> @@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
>  		break;
>  	case IB_MAC_IOCB_RSP_ERR_CRC:
>  		stats->rx_crc_err++;
> +		break;
>  	default:
>  		break;
>  	}

In this instance, it think it would be more appropriate to remove the
"default" case.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 127/141] staging: qlge: Fix fall-through warnings for Clang
@ 2020-11-25  4:42     ` Benjamin Poirier
  0 siblings, 0 replies; 1306+ messages in thread
From: Benjamin Poirier @ 2020-11-25  4:42 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: devel, GR-Linux-NIC-Dev, Manish Chopra, Greg Kroah-Hartman,
	linux-kernel, linux-hardening, netdev

On 2020-11-20 12:39 -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/staging/qlge/qlge_main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/qlge/qlge_main.c b/drivers/staging/qlge/qlge_main.c
> index 27da386f9d87..c41b1373dcf8 100644
> --- a/drivers/staging/qlge/qlge_main.c
> +++ b/drivers/staging/qlge/qlge_main.c
> @@ -1385,6 +1385,7 @@ static void ql_categorize_rx_err(struct ql_adapter *qdev, u8 rx_err,
>  		break;
>  	case IB_MAC_IOCB_RSP_ERR_CRC:
>  		stats->rx_crc_err++;
> +		break;
>  	default:
>  		break;
>  	}

In this instance, it think it would be more appropriate to remove the
"default" case.
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-24 21:32                         ` Kees Cook
                                             ` (9 preceding siblings ...)
  (?)
@ 2020-11-25  7:05                           ` James Bottomley
  -1 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: Gustavo A. R. Silva, Joe Perches, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: Gustavo A. R. Silva, Joe Perches, Jakub Kicinski, alsa-devel,
	linux-atm-general, reiserfs-devel, linux-iio, linux-wireless,
	linux-fbdev, dri-devel, linux-kernel, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, linux-rdma, oss-drivers, bridge,
	linux-security-module, amd-gfx, linux-stm32, cluster-devel,
	linux-acpi, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	tipc-discussion, linux-ext4, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-geode, linux-can,
	linux-block, linux-gpio, op-tee, linux-mediatek, xen-devel,
	nouveau, linux-hams, ceph-devel, virtualization,
	linux-arm-kernel, linux-hwmon, x86, linux-nfs, GR-Linux-NIC-Dev,
	linux-mm, netdev, linux-decnet-user, linux-mmc,
	linux-renesas-soc, linux-sctp, linux-usb, netfilter-devel,
	linux-crypto, patches, linux-integrity, target-devel,
	linux-hardening, Jonathan Cameron, Greg KH

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-mm, linux-ide, dm-devel, keyrings,
	linux-mtd, GR-everest-linux-l2, wcn36xx, linux-i3c,
	linux1394-devel, linux-afs, devel, linux-cifs, rds-devel,
	linux-scsi, linux-acpi, linux-rdma, oss-drivers,
	linux-atm-general, ceph-devel, amd-gfx, linux-stm32,
	cluster-devel, usb-storage, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, linux-ext4,
	virtualization, netfilter-devel, linux-media, linux-watchdog,
	selinux, linux-arm-msm, intel-gfx, linux-sctp, reiserfs-devel,
	linux-geode, linux-block, linux-gpio, op-tee, linux-mediatek,
	xen-devel, drbd-dev, linux-hams, Chancellor, linux-can,
	linux-arm-kernel, linux-hwmon, Nick Desaulniers, linux-nfs,
	GR-Linux-NIC-Dev, Nathan, nouveau, netdev, linux-decnet-user,
	linux-wireless, linux-kernel, linux-renesas-soc,
	linux-security-module, linux-usb, tipc-discussion, linux-crypto,
	Jonathan Cameron, patches, Joe Perches, linux-integrity, x86,
	linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, Jonathan Cameron, patches,
	Joe Perches, linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James



_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James





^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  7:05                           ` James Bottomley
  0 siblings, 0 replies; 1306+ messages in thread
From: James Bottomley @ 2020-11-25  7:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx, linux-stm32, cluster-devel, usb-storage,
	linux-mmc, coreteam, intel-wired-lan, linux-input, Miguel Ojeda,
	Jakub Kicinski, linux-ext4, virtualization, netfilter-devel,
	linux-media, linux-watchdog, selinux, linux-arm-msm, intel-gfx,
	linux-sctp, reiserfs-devel, linux-geode, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	Nathan Chancellor, linux-can, linux-arm-kernel, linux-hwmon,
	Nick Desaulniers, linux-nfs, GR-Linux-NIC-Dev, linux-mm, netdev,
	linux-decnet-user, linux-wireless, linux-kernel,
	linux-renesas-soc, linux-security-module, linux-usb,
	tipc-discussion, linux-crypto, patches, Joe Perches,
	linux-integrity, x86, linux-hardening

On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> On Mon, Nov 23, 2020 at 08:31:30AM -0800, James Bottomley wrote:
> > Really, no ... something which produces no improvement has no value
> > at all ... we really shouldn't be wasting maintainer time with it
> > because it has a cost to merge.  I'm not sure we understand where
> > the balance lies in value vs cost to merge but I am confident in
> > the zero value case.
> 
> What? We can't measure how many future bugs aren't introduced because
> the kernel requires explicit case flow-control statements for all new
> code.

No but we can measure how vulnerable our current coding habits are to
the mistake this warning would potentially prevent.  I don't think it's
wrong to extrapolate that if we had no instances at all of prior coding
problems we likely wouldn't have any in future either making adopting
the changes needed to enable the warning valueless ... that's the zero
value case I was referring to above.

Now, what we have seems to be about 6 cases (at least what's been shown
in this thread) where a missing break would cause potentially user
visible issues.  That means the value of this isn't zero, but it's not
a no-brainer massive win either.  That's why I think asking what we've
invested vs the return isn't a useless exercise.

> We already enable -Wimplicit-fallthrough globally, so that's not the
> discussion. The issue is that Clang is (correctly) even more strict
> than GCC for this, so these are the remaining ones to fix for full
> Clang coverage too.
> 
> People have spent more time debating this already than it would have
> taken to apply the patches. :)

You mean we've already spent 90% of the effort to come this far so we
might as well go the remaining 10% because then at least we get some
return? It's certainly a clinching argument in defence procurement ...

> This is about robustness and language wrangling. It's a big code-
> base, and this is the price of our managing technical debt for
> permanent robustness improvements. (The numbers I ran from Gustavo's
> earlier patches were that about 10% of the places adjusted were
> identified as legitimate bugs being fixed. This final series may be
> lower, but there are still bugs being found from it -- we need to
> finish this and shut the door on it for good.)

I got my six patches by analyzing the lwn.net report of the fixes that
was cited which had 21 of which 50% didn't actually change the emitted
code, and 25% didn't have a user visible effect.

But the broader point I'm making is just because the compiler people
come up with a shiny new warning doesn't necessarily mean the problem
it's detecting is one that causes us actual problems in the code base. 
I'd really be happier if we had a theory about what classes of CVE or
bug we could eliminate before we embrace the next new warning.

James




^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 15:58                   ` James Bottomley
                                       ` (8 preceding siblings ...)
  (?)
@ 2020-11-25  9:01                     ` Sean Young
  -1 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, alsa-devel, amd-gfx, bridge, ceph-devel,
	cluster-devel, coreteam, devel, dm-devel, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel, linux-acpi,
	linux-afs, Linux ARM, linux-arm-msm, linux-atm-general,
	linux-block, linux-can, linux-cifs, Linux Crypto Mailing List,
	linux-decnet-user, Ext4 Developers List, linux-fbdev,
	linux-geode, linux-gpio, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	linux-mediatek, Linux Media Mailing List, linux-mmc, Linux-MM,
	linux-mtd, linux-nfs, linux-rdma, linux-renesas-soc, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, linux-usb,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, Miguel Ojeda, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, nouveau,
	linux-iio, linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, linux-watchdog, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, drbd-dev, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, Miguel Ojeda, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, Miguel Ojeda, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, target-devel, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, linux-renesas-soc, Miguel Ojeda, linux-sctp,
	linux-usb, netfilter-devel, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25  9:01                     ` Sean Young
  0 siblings, 0 replies; 1306+ messages in thread
From: Sean Young @ 2020-11-25  9:01 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, linux-kernel,
	Nathan Chancellor, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev, devel,
	linux-cifs, rds-devel, Nick Desaulniers, linux-scsi, linux-rdma,
	oss-drivers, bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, linux-acpi, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-renesas-soc, Miguel Ojeda, linux-sctp, linux-usb,
	netfilter-devel, Linux Crypto Mailing List, patches, Joe Perches,
	linux-integrity, target-devel, linux-hardening

On Mon, Nov 23, 2020 at 07:58:06AM -0800, James Bottomley wrote:
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > It's not about the risk of the changes it's about the cost of
> > > implementing them.  Even if you discount the producer time (which
> > > someone gets to pay for, and if I were the engineering manager, I'd
> > > be unhappy about), the review/merge/rework time is pretty
> > > significant in exchange for six minor bug fixes.  Fine, when a new
> > > compiler warning comes along it's certainly reasonable to see if we
> > > can benefit from it and the fact that the compiler people think
> > > it's worthwhile is enough evidence to assume this initially.  But
> > > at some point you have to ask whether that assumption is supported
> > > by the evidence we've accumulated over the time we've been using
> > > it.  And if the evidence doesn't support it perhaps it is time to
> > > stop the experiment.
> > 
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
> 
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129
> 
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

You're assuming burn out or recruitment problems is due to patch workload
or too many "trivial" patches.

In my experience, "other maintainers" is by far the biggest cause of
burn out for my kernel maintenance work.

Certainly arguing with a maintainer about some obviously-correct patch
series must be a good example of this.


Sean

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-23 20:37                       ` James Bottomley
                                           ` (9 preceding siblings ...)
  (?)
@ 2020-11-25 10:38                         ` Andy Shevchenko
  -1 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, ALSA Development Mailing List, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, open list:STAGING SUBSYSTEM,
	device-mapper development, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel,
	ACPI Devel Maling List, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, open list:FRAMEBUFFER LAYER, linux-geode,
	open list:GPIO SUBSYSTEM, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	moderated list:ARM/Mediatek SoC support,
	Linux Media Mailing List, linux-mmc, Linux-MM,
	open list:MEMORY TECHNOLOGY...,
	linux-nfs, open list:HFI1 DRIVER, Linux-Renesas, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, USB,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: Miguel Ojeda, Kees Cook, Jakub Kicinski, Gustavo A. R. Silva,
	linux-kernel, ALSA Development Mailing List, amd-gfx, bridge,
	ceph-devel, cluster-devel, coreteam, open list:STAGING SUBSYSTEM,
	device-mapper development, drbd-dev, dri-devel,
	GR-everest-linux-l2, GR-Linux-NIC-Dev, intel-gfx,
	intel-wired-lan, keyrings, linux1394-devel,
	ACPI Devel Maling List, linux-afs, Linux ARM, linux-arm-msm,
	linux-atm-general, linux-block, linux-can, linux-cifs,
	Linux Crypto Mailing List, linux-decnet-user,
	Ext4 Developers List, open list:FRAMEBUFFER LAYER, linux-geode,
	open list:GPIO SUBSYSTEM, linux-hams, linux-hwmon, linux-i3c,
	linux-ide, linux-iio, linux-input, linux-integrity,
	moderated list:ARM/Mediatek SoC support,
	Linux Media Mailing List, linux-mmc, Linux-MM,
	open list:MEMORY TECHNOLOGY...,
	linux-nfs, open list:HFI1 DRIVER, Linux-Renesas, linux-scsi,
	linux-sctp, linux-security-module, linux-stm32, USB,
	linux-watchdog, linux-wireless, Network Development,
	netfilter-devel, nouveau, op-tee, oss-drivers, patches,
	rds-devel, reiserfs-devel, samba-technical, selinux,
	target-devel, tipc-discussion, usb-storage, virtualization,
	wcn36xx, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	xen-devel, linux-hardening, Nick Desaulniers, Nathan Chancellor,
	Miguel Ojeda, Joe Perches

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, target-devel, Linux ARM,
	linux-hwmon, linux-watchdog, linux-nfs, GR-Linux-NIC-Dev,
	tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	nouveau, linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, linux-watchdog,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, drbd-dev,
	linux-hams, ceph-devel, virtualization, target-devel, Linux ARM,
	linux-hwmon, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, tipc-discussion, Linux-MM,
	Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva, Linux-Renesas, Miguel Ojeda, linux-sctp,
	USB, netfilter-devel, Linux Crypto Mailing List, patches,
	Joe Perches, linux-integrity, linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, target-devel, Linux ARM,
	linux-hwmon, linux-watchdog, linux-nfs, GR-Linux-NIC-Dev,
	tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, target-devel, Linux ARM,
	linux-hwmon, linux-watchdog, linux-nfs, GR-Linux-NIC-Dev,
	tipc-discussion, Linux-MM, Network Development,
	linux-decnet-user, linux-mmc, Gustavo A. R. Silva, Linux-Renesas,
	Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: intel-wired-lan

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 10:38                         ` Andy Shevchenko
  0 siblings, 0 replies; 1306+ messages in thread
From: Andy Shevchenko @ 2020-11-25 10:38 UTC (permalink / raw)
  To: James Bottomley
  Cc: ALSA Development Mailing List, linux-atm-general, reiserfs-devel,
	linux-iio, linux-wireless, open list:FRAMEBUFFER LAYER,
	dri-devel, linux-kernel, Nathan Chancellor, linux-ide,
	device-mapper development, keyrings,
	open list:MEMORY TECHNOLOGY...,
	GR-everest-linux-l2, wcn36xx, samba-technical, linux-i3c,
	linux1394-devel, linux-afs, usb-storage, drbd-dev,
	open list:STAGING SUBSYSTEM, linux-cifs, rds-devel,
	Nick Desaulniers, linux-scsi, open list:HFI1 DRIVER, oss-drivers,
	bridge, linux-security-module, amd-gfx, linux-stm32,
	cluster-devel, ACPI Devel Maling List, coreteam, intel-wired-lan,
	linux-input, Miguel Ojeda, Jakub Kicinski, Ext4 Developers List,
	Linux Media Mailing List, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block,
	open list:GPIO SUBSYSTEM, op-tee,
	moderated list:ARM/Mediatek SoC support, xen-devel, nouveau,
	linux-hams, ceph-devel, virtualization, Linux ARM, linux-hwmon,
	linux-watchdog, linux-nfs, GR-Linux-NIC-Dev, tipc-discussion,
	Linux-MM, Network Development, linux-decnet-user, linux-mmc,
	Gustavo A. R. Silva,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	Linux-Renesas, Miguel Ojeda, linux-sctp, USB, netfilter-devel,
	Linux Crypto Mailing List, patches, Joe Perches, linux-integrity,
	target-devel, linux-hardening

On Mon, Nov 23, 2020 at 10:39 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> > On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:

...

> > But if we do the math, for an author, at even 1 minute per line
> > change and assuming nothing can be automated at all, it would take 1
> > month of work. For maintainers, a couple of trivial lines is noise
> > compared to many other patches.
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

In my practice most of the one line patches were either to fix or to
introduce quite interesting issues.
1 minute is 2-3 orders less than usually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-25  7:05                           ` James Bottomley
                                               ` (10 preceding siblings ...)
  (?)
@ 2020-11-25 12:24                             ` Nick Desaulniers
  -1 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Gustavo A. R. Silva, Joe Perches, Jakub Kicinski,
	alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-mmc, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: Kees Cook, Gustavo A. R. Silva, Joe Perches, Jakub Kicinski,
	alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-mmc, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	linux-integrity, target-devel, linux-hardening, Jonathan Cameron,
	Greg KH

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers via Virtualization @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, Linux Memory Management List, linux-ide,
	dm-devel, keyrings, linux-mtd, GR-everest-linux-l2, wcn36xx,
	linux-i3c, linux1394-devel, linux-afs, linux-watchdog, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	oss-drivers, linux-atm-general, ceph-devel, amd-gfx list,
	linux-stm32, cluster-devel, usb-storage, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, Jakub Kicinski,
	linux-ext4, virtualization, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, xen-devel, drbd-dev, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, nouveau, Network Development,
	linux-decnet-user, linux-wireless, LKML, Linux-Renesas,
	linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, linux-mmc, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
	Jonathan Cameron, patches, Joe Perches, linux-integrity,
	linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: intel-wired-lan

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Cluster-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: cluster-devel.redhat.com

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers



^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Bridge] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 12:24                             ` Nick Desaulniers
  0 siblings, 0 replies; 1306+ messages in thread
From: Nick Desaulniers @ 2020-11-25 12:24 UTC (permalink / raw)
  To: James Bottomley
  Cc: alsa-devel, bridge, target-devel, Greg KH, linux-iio,
	samba-technical, Jonathan Cameron, linux-fbdev, dri-devel,
	Gustavo A. R. Silva, linux-ide, dm-devel, keyrings, linux-mtd,
	GR-everest-linux-l2, wcn36xx, linux-i3c, linux1394-devel,
	linux-afs, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, linux-mmc, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, Jakub Kicinski, linux-ext4, virtualization,
	netfilter-devel, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, xen-devel, nouveau,
	linux-hams, Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-wireless, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, patches,
	Joe Perches, linux-integrity, linux-nfs, linux-hardening

On Tue, Nov 24, 2020 at 11:05 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2020-11-24 at 13:32 -0800, Kees Cook wrote:
> > We already enable -Wimplicit-fallthrough globally, so that's not the
> > discussion. The issue is that Clang is (correctly) even more strict
> > than GCC for this, so these are the remaining ones to fix for full
> > Clang coverage too.
> >
> > People have spent more time debating this already than it would have
> > taken to apply the patches. :)
>
> You mean we've already spent 90% of the effort to come this far so we
> might as well go the remaining 10% because then at least we get some
> return? It's certainly a clinching argument in defence procurement ...

So developers and distributions using Clang can't have
-Wimplicit-fallthrough enabled because GCC is less strict (which has
been shown in this thread to lead to bugs)?  We'd like to have nice
things too, you know.

I even agree that most of the churn comes from

case 0:
  ++x;
default:
  break;

which I have a patch for: https://reviews.llvm.org/D91895.  I agree
that can never lead to bugs.  But that's not the sole case of this
series, just most of them.

Though, note how the reviewer (C++ spec editor and clang front end
owner) in https://reviews.llvm.org/D91895 even asks in that review how
maybe a new flag would be more appropriate for a watered
down/stylistic variant of the existing behavior.  And if the current
wording of Documentation/process/deprecated.rst around "fallthrough"
is a straightforward rule of thumb, I kind of agree with him.

>
> > This is about robustness and language wrangling. It's a big code-
> > base, and this is the price of our managing technical debt for
> > permanent robustness improvements. (The numbers I ran from Gustavo's
> > earlier patches were that about 10% of the places adjusted were
> > identified as legitimate bugs being fixed. This final series may be
> > lower, but there are still bugs being found from it -- we need to
> > finish this and shut the door on it for good.)
>
> I got my six patches by analyzing the lwn.net report of the fixes that
> was cited which had 21 of which 50% didn't actually change the emitted
> code, and 25% didn't have a user visible effect.
>
> But the broader point I'm making is just because the compiler people
> come up with a shiny new warning doesn't necessarily mean the problem

That's not what this is though; you're attacking a strawman.  I'd
encourage you to bring that up when that actually occurs, unlike this
case since it's actively hindering getting -Wimplicit-fallthrough
enabled for Clang.  This is not a shiny new warning; it's already on
for GCC and has existed in both compilers for multiple releases.

And I'll also note that warnings are warnings and not errors because
they cannot be proven to be bugs in 100% of cases, but they have led
to bugs in the past.  They require a human to review their intent and
remove ambiguities.  If 97% of cases would end in a break ("Expert C
Programming: Deep C Secrets" - Peter van der Linden), then it starts
to look to me like a language defect; certainly an incorrectly chosen
default.  But the compiler can't know those 3% were intentional,
unless you're explicit for those exceptional cases.

> it's detecting is one that causes us actual problems in the code base.
> I'd really be happier if we had a theory about what classes of CVE or
> bug we could eliminate before we embrace the next new warning.

We don't generally file CVEs and waiting for them to occur might be
too reactive, but I agree that pointing to some additional
documentation in commit messages about how a warning could lead to a
bug would make it clearer to reviewers why being able to enable it
treewide, even if there's no bug in their particular subsystem, is in
the general interest of the commons.

On Mon, Nov 23, 2020 at 7:58 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
>
> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches ... I'm pushing back
> on that assumption in two places, firstly the valulessness of the time
> and secondly that all trivial patches are valuable.

It's critical to the longevity of any open source project that there
are not single points of failure.  If someone is not expendable or
replaceable (or claims to be) then that's a risk to the project and a
bottleneck.  Not having a replacement in training or some form of
redundancy is short sighted.

If trivial patches are adding too much to your workload, consider
training a co-maintainer or asking for help from one of your reviewers
whom you trust.  I don't doubt it's hard to find maintainers, but
existing maintainers should go out of their way to entrust
co-maintainers especially when they find their workload becomes too
high.  And reviewing/picking up trivial patches is probably a great
way to get started.  If we allow too much knowledge of any one
subsystem to collect with one maintainer, what happens when that
maintainer leaves the community (which, given a finite lifespan, is an
inevitability)?
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 062/141] HID: usbhid: Fix fall-through warnings for Clang
  2020-11-20 18:33 ` [PATCH 062/141] HID: usbhid: " Gustavo A. R. Silva
@ 2020-11-25 13:02   ` Jiri Kosina
  0 siblings, 0 replies; 1306+ messages in thread
From: Jiri Kosina @ 2020-11-25 13:02 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Benjamin Tissoires, linux-usb, linux-input, linux-kernel,
	linux-hardening

On Fri, 20 Nov 2020, Gustavo A. R. Silva wrote:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
> of warnings by explicitly adding a couple of break statements instead
> of letting the code fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/hid/usbhid/hid-core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 17a29ee0ac6c..86257ce6d619 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -438,6 +438,7 @@ static void hid_irq_out(struct urb *urb)
>  		break;
>  	case -ESHUTDOWN:	/* unplug */
>  		unplug = 1;
> +		break;
>  	case -EILSEQ:		/* protocol error or unplug */
>  	case -EPROTO:		/* protocol error or unplug */
>  	case -ECONNRESET:	/* unlink */
> @@ -489,6 +490,7 @@ static void hid_ctrl(struct urb *urb)
>  		break;
>  	case -ESHUTDOWN:	/* unplug */
>  		unplug = 1;
> +		break;
>  	case -EILSEQ:		/* protocol error or unplug */
>  	case -EPROTO:		/* protocol error or unplug */
>  	case -ECONNRESET:	/* unlink */

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [PATCH 063/141] HID: input: Fix fall-through warnings for Clang
  2020-11-20 18:33 ` [PATCH 063/141] HID: input: " Gustavo A. R. Silva
@ 2020-11-25 13:04   ` Jiri Kosina
  2020-11-25 13:34     ` David Laight
  0 siblings, 1 reply; 1306+ messages in thread
From: Jiri Kosina @ 2020-11-25 13:04 UTC (permalink / raw)
  To: Gustavo A. R. Silva
  Cc: Benjamin Tissoires, linux-input, linux-kernel, linux-hardening

On Fri, 20 Nov 2020, Gustavo A. R. Silva wrote:

> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a goto statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>  drivers/hid/hid-input.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 9770db624bfa..37601b800a2e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -743,6 +743,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
>  				field->flags |= HID_MAIN_ITEM_RELATIVE;
>  				break;
>  			}
> +			goto unknown;
>  
>  		default: goto unknown;

This makes my eyes hurt :) But adding the annotation would be ugly as 
well, so let me just take it as-is.

Thanks,

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* RE: [PATCH 063/141] HID: input: Fix fall-through warnings for Clang
  2020-11-25 13:04   ` Jiri Kosina
@ 2020-11-25 13:34     ` David Laight
  0 siblings, 0 replies; 1306+ messages in thread
From: David Laight @ 2020-11-25 13:34 UTC (permalink / raw)
  To: 'Jiri Kosina', Gustavo A. R. Silva
  Cc: Benjamin Tissoires, linux-input, linux-kernel, linux-hardening

From: Jiri Kosina <jikos@kernel.org>
> Sent: 25 November 2020 13:04
> On Fri, 20 Nov 2020, Gustavo A. R. Silva wrote:
> 
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a goto statement instead of letting the code fall
> > through to the next case.
> >
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> > ---
> >  drivers/hid/hid-input.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> > index 9770db624bfa..37601b800a2e 100644
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -743,6 +743,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> >  				field->flags |= HID_MAIN_ITEM_RELATIVE;
> >  				break;
> >  			}
> > +			goto unknown;
> >
> >  		default: goto unknown;
> 
> This makes my eyes hurt :) But adding the annotation would be ugly as
> well, so let me just take it as-is.

                case HID_GD_RFKILL_BTN:
                        /* MS wireless radio ctl extension, also check CA */
                        if (field->application == HID_GD_WIRELESS_RADIO_CTLS) {
                                map_key_clear(KEY_RFKILL);
                                /* We need to simulate the btn release */
                                field->flags |= HID_MAIN_ITEM_RELATIVE;
                                break;
                        }

It might be best to invert the condition and de-indent the code.
                case HID_GD_RFKILL_BTN:
                        /* MS wireless radio ctl extension, also check CA */
                        if (field->application != HID_GD_WIRELESS_RADIO_CTLS)
                                goto unknown;
                        map_key_clear(KEY_RFKILL);
                        /* We need to simulate the btn release */
                        field->flags |= HID_MAIN_ITEM_RELATIVE;
                        break;

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
  2020-11-25 12:24                             ` Nick Desaulniers
                                                 ` (4 preceding siblings ...)
  (?)
@ 2020-11-25 16:24                               ` Jakub Kicinski
  -1 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: James Bottomley, Kees Cook, Gustavo A. R. Silva, Joe Perches,
	alsa-devel, linux-atm-general, reiserfs-devel, linux-iio,
	linux-wireless, linux-fbdev, dri-devel, LKML, Nathan Chancellor,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, samba-technical, linux-i3c, linux1394-devel, linux-afs,
	usb-storage, drbd-dev, devel, linux-cifs, rds-devel, linux-scsi,
	linux-rdma, oss-drivers, bridge, linux-security-module,
	amd-gfx list, linux-stm32, cluster-devel, linux-acpi, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, tipc-discussion,
	linux-ext4, linux-media, linux-watchdog, selinux, linux-arm-msm,
	intel-gfx, linux-geode, linux-can, linux-block, linux-gpio,
	op-tee, linux-mediatek, xen-devel, nouveau, linux-hams,
	ceph-devel, virtualization, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, linux-mmc, Linux-Renesas,
	linux-sctp, linux-usb, netfilter-devel,
	open  list:HARDWARE RANDOM NUMBER GENERATOR CORE"         
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com,  linux-integrity@vger.kernel.org,
	target-devel@vger.kernel.org,  linux-hardening@vger.kernel.org,
	Jonathan Cameron  <Jonathan.Cameron@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, bridge, linux-iio, linux-wireless,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com, linux-integrity@vger.kernel.org,
	target-devel@vger.kernel.org, linux-hardening@vger.kernel.org,
	Jonathan Cameron  <Jonathan.Cameron@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-fbdev, dri-devel, Gustavo A. R. Silva, James Bottomley,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	wcn36xx, linux-i3c, linux1394-devel, linux-afs, drbd-dev, devel,
	linux-cifs, rds-devel, linux-scsi, linux-acpi, linux-rdma,
	oss-drivers, linux-atm-general, ceph-devel, amd-gfx list,
	linux-stm32, cluster-devel, usb-storage, linux-mmc, coreteam,
	intel-wired-lan, linux-input, Miguel Ojeda, xen-devel,
	linux-ext4, virtualization, netfilter-devel, linux-media,
	Kees Cook, selinux, linux-arm-msm, intel-gfx, linux-sctp,
	reiserfs-devel, linux-geode, linux-block, linux-gpio, op-tee,
	linux-mediatek, nouveau, linux-hams, Nathan Chancellor,
	linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-watchdog, GR-Linux-NIC-Dev, Linux Memory Management List,
	Network Development, linux-decnet-user, samba-technical, LKML,
	Linux-Renesas, linux-security-module, linux-usb, tipc-discussion,
	Joe Perches, linux-nfs

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
       [not found]                             ` <CAKwvOdkGBn7nuWTAqrORMeN1G+w3YwBfCqqaRD2nwvoAXKi=Aw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	open-CC+yJ3UmIYqDUpFQwHEjaQ, list:HARDWARE,
	RANDOM-CC+yJ3UmIYqDUpFQwHEjaQ, NUMBER-CC+yJ3UmIYqDUpFQwHEjaQ,
	GENERATOR-CC+yJ3UmIYqDUpFQwHEjaQ, CORE-CC+yJ3UmIYqDUpFQwHEjaQ,
	         
	<linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	patches-yzvPICuk2AA4QjBA90+/kJqQE7yCjDx5@public.gmane.org,
	 linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	target-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	 linux-hardening-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jonathan Cameron 
	<Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Greg KH
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	 linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	 linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	 dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	 ,
	Gustavo-CC+yJ3UmIYqDUpFQwHEjaQ, A.R.Silva-CC+yJ3UmIYqDUpFQwHEjaQ,
	gustavoars-DgEjT+Ai2ygdnm+yROfE0A, James Bottomley,
	linux-ide-u79uwXL29TY76Z2rM5mHXA,
	dm-devel-H+wXaHxf7aLQT0dZR+AlfA, keyrings-u79uwXL29TY76Z2rM5mHXA,
	li

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, bridge, open, list:HARDWARE, RANDOM, NUMBER,
	GENERATOR, CORE,           <linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com,  linux-integrity@vger.kernel.org,
	target-devel@vger.kernel.org,  linux-hardening@vger.kernel.org,
	Jonathan Cameron  <Jonathan.Cameron@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	 linux-iio@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	 linux-mmc@vger.kernel.org, linux-fbdev@vger.kernel.org,
	 dri-devel <dri-devel@lists.freedesktop.org>,  ,
	Gustavo, A.R.Silva,  <gustavoars@kernel.org>,
	 James Bottomley <James.Bottomley@hansenpartnership.com>,
	 linux-ide@vger.kernel.org, dm-devel@redhat.com,
	keyrings@vger.kernel.org,  linux-mtd@lists.infradead.org,
	GR-everest-linux-l2@marvell.com,  wcn36xx@lists.infradead.org,
	linux-i3c@lists.infradead.org,
	 linux1394-devel@lists.sourceforge.net,
	linux-afs@lists.infradead.org,  drbd-dev@lists.linbit.com,
	devel@driverdev.osuosl.org,  linux-cifs@vger.kernel.org,
	rds-devel@oss.oracle.com,  linux-scsi@vger.kernel.org,
	linux-acpi@vger.kernel.org,  linux-rdma@vger.kernel.org,
	oss-drivers@netronome.com,
	 linux-atm-general@lists.sourceforge.net,
	ceph-devel@vger.kernel.org,
	 amd-gfx list <amd-gfx@lists.freedesktop.org>,
	 linux-stm32@st-md-mailman.stormreply.com,
	cluster-devel@redhat.com,  usb-storage@lists.one-eyed-alien.net,
	coreteam@netfilter.org,  intel-wired-lan@lists.osuosl.org,
	linux-input@vger.kernel.org,
	 Miguel Ojeda <ojeda@kernel.org>,
	xen-devel@lists.xenproject.org,  linux-ext4@vger.kernel.org,
	virtuali zation@lists.linux-foundation.org,
	 netfilter-devel@vger.kernel.org, linux-media@vger.kernel.org,
	 Kees Cook <keescook@chromium.org>,
	selinux@vger.kernel.org,
	 linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	intel-gfx@lists.freedesktop.org,  linux-sctp@vger.kernel.org,
	reiserfs-devel@vger.kernel.org,  linux-geode@lists.infradead.org,
	linux-block@vger.kernel.org,  linux-gpio@vger.kernel.org,
	op-tee@lists.trustedfirmware.org,
	 linux-mediatek@lists.infradead.org,
	nouveau@lists.freedesktop.org,  linux-hams@vger.kernel.org,
	Nathan Chancellor <natechancellor@gmail.com>,
	 linux-can@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-hwmon@vger.kernel.org,  ,
	maintainer:X86, ARCHITECTURE, (32-BIT, AND, 64-BIT),
	 <x86@kernel.org>,
	 linux-watchdog@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com,
	 Linux Memory Management List <linux-mm@kvack.org>,
	 Network Development <netdev@vger.kernel.org>,
	 linux-decnet-user@lists.sourceforge.net,
	samba-technical@lists.samba.org,
	 LKML <linux-kernel@vger.kernel.org>,
	 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	 linux-security-module@vger.kernel.org,
	linux-usb@vger.kernel.org,
	 tipc-discussion@lists.sourceforge.net,
	Joe Perches <joe@perches.com>,
	 linux-nfs@vger.kernel.org

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [dm-devel] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, bridge, linux-iio, linux-wireless, linux-mmc,
	linux-fbdev, dri-devel, Gustavo A. R. Silva, James Bottomley,
	linux-ide, dm-devel, keyrings, linux-mtd, GR-everest-linux-l2,
	Linux, wcn36xx, linux-i3c, linux1394-devel, linux-afs,
	linux-watchdog, devel, linux-cifs, rds-devel, linux-scsi,
	linux-acpi, linux-rdma, oss-drivers, linux-atm-general,
	ceph-devel, amd-gfx list, linux-stm32, cluster-devel,
	usb-storage, coreteam, intel-wired-lan, linux-input,
	Miguel Ojeda, xen-devel, linux-ext4, virtualization,
	Management List, linux-media, Kees Cook, selinux, linux-arm-msm,
	intel-gfx, linux-sctp, reiserfs-devel, linux-geode, linux-block,
	linux-gpio, op-tee, linux-mediatek, Joe, drbd-dev, linux-hams,
	Nathan Chancellor, linux-can, Linux ARM, linux-hwmon,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
	linux-nfs, GR-Linux-NIC-Dev, nouveau, Network Development,
	linux-decnet-user, samba-technical, LKML, Linux-Renesas,
	linux-security-module, linux-usb, tipc-discussion, Perches,
	netfilter-devel, HARDWARE

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-gfx] [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, bridge, open, list:HARDWARE, RANDOM, NUMBER,
	GENERATOR, CORE,           <linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com,  linux-integrity@vger.kernel.org,
	target-devel@vger.kernel.org,  linux-hardening@vger.kernel.org,
	Jonathan Cameron  <Jonathan.Cameron@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	 linux-iio@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	 linux-mmc@vger.kernel.org, linux-fbdev@vger.kernel.org,
	 dri-devel <dri-devel@lists.freedesktop.org>,  ,
	Gustavo, A.R.Silva,  <gustavoars@kernel.org>,
	 James Bottomley <James.Bottomley@hansenpartnership.com>,
	 linux-ide@vger.kernel.org, dm-devel@redhat.com,
	keyrings@vger.kernel.org,  linux-mtd@lists.infradead.org,
	GR-everest-linux-l2@marvell.com,  wcn36xx@lists.infradead.org,
	linux-i3c@lists.infradead.org,
	 linux1394-devel@lists.sourceforge.net,
	linux-afs@lists.infradead.org,  drbd-dev@lists.linbit.com,
	devel@driverdev.osuosl.org,  linux-cifs@vger.kernel.org,
	rds-devel@oss.oracle.com,  linux-scsi@vger.kernel.org,
	linux-acpi@vger.kernel.org,  linux-rdma@vger.kernel.org,
	oss-drivers@netronome.com,
	 linux-atm-general@lists.sourceforge.net,
	ceph-devel@vger.kernel.org,
	 amd-gfx list <amd-gfx@lists.freedesktop.org>,
	 linux-stm32@st-md-mailman.stormreply.com,
	cluster-devel@redhat.com,  usb-storage@lists.one-eyed-alien.net,
	coreteam@netfilter.org,  intel-wired-lan@lists.osuosl.org,
	linux-input@vger.kernel.org,
	 Miguel Ojeda <ojeda@kernel.org>,
	xen-devel@lists.xenproject.org,  linux-ext4@vger.kernel.org,
	virtuali zation@lists.linux-foundation.org,
	 netfilter-devel@vger.kernel.org, linux-media@vger.kernel.org,
	 Kees Cook <keescook@chromium.org>,
	selinux@vger.kernel.org,
	 linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	intel-gfx@lists.freedesktop.org,  linux-sctp@vger.kernel.org,
	reiserfs-devel@vger.kernel.org,  linux-geode@lists.infradead.org,
	linux-block@vger.kernel.org,  linux-gpio@vger.kernel.org,
	op-tee@lists.trustedfirmware.org,
	 linux-mediatek@lists.infradead.org,
	nouveau@lists.freedesktop.org,  linux-hams@vger.kernel.org,
	Nathan Chancellor <natechancellor@gmail.com>,
	 linux-can@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-hwmon@vger.kernel.org,  ,
	maintainer:X86, ARCHITECTURE, (32-BIT, AND, 64-BIT),
	 <x86@kernel.org>,
	 linux-watchdog@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com,
	 Linux Memory Management List <linux-mm@kvack.org>,
	 Network Development <netdev@vger.kernel.org>,
	 linux-decnet-user@lists.sourceforge.net,
	samba-technical@lists.samba.org,
	 LKML <linux-kernel@vger.kernel.org>,
	 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	 linux-security-module@vger.kernel.org,
	linux-usb@vger.kernel.org,
	 tipc-discussion@lists.sourceforge.net,
	Joe Perches <joe@perches.com>,
	 linux-nfs@vger.kernel.org

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* Re: [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: alsa-devel, bridge, open, list:HARDWARE, RANDOM, NUMBER,
	GENERATOR, CORE,           <linux-crypto@vger.kernel.org>,
	patches@opensource.cirrus.com,  linux-integrity@vger.kernel.org,
	target-devel@vger.kernel.org,  linux-hardening@vger.kernel.org,
	Jonathan Cameron  <Jonathan.Cameron@huawei.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	 linux-iio@vger.kernel.org,
	linux-wireless <linux-wireless@vger.kernel.org>,
	 linux-mmc@vger.kernel.org, linux-fbdev@vger.kernel.org,
	 dri-devel <dri-devel@lists.freedesktop.org>,  ,
	Gustavo, A.R.Silva,  <gustavoars@kernel.org>,
	 James Bottomley <James.Bottomley@hansenpartnership.com>,
	 linux-ide@vger.kernel.org, dm-devel@redhat.com,
	keyrings@vger.kernel.org,  linux-mtd@lists.infradead.org,
	GR-everest-linux-l2@marvell.com,  wcn36xx@lists.infradead.org,
	linux-i3c@lists.infradead.org,
	 linux1394-devel@lists.sourceforge.net,
	linux-afs@lists.infradead.org,  drbd-dev@lists.linbit.com,
	devel@driverdev.osuosl.org,  linux-cifs@vger.kernel.org,
	rds-devel@oss.oracle.com,  linux-scsi@vger.kernel.org,
	linux-acpi@vger.kernel.org,  linux-rdma@vger.kernel.org,
	oss-drivers@netronome.com,
	 linux-atm-general@lists.sourceforge.net,
	ceph-devel@vger.kernel.org,
	 amd-gfx list <amd-gfx@lists.freedesktop.org>,
	 linux-stm32@st-md-mailman.stormreply.com,
	cluster-devel@redhat.com,  usb-storage@lists.one-eyed-alien.net,
	coreteam@netfilter.org,  intel-wired-lan@lists.osuosl.org,
	linux-input@vger.kernel.org,
	 Miguel Ojeda <ojeda@kernel.org>,
	xen-devel@lists.xenproject.org,  linux-ext4@vger.kernel.org,
	virtuali zation@lists.linux-foundation.org,
	 netfilter-devel@vger.kernel.org, linux-media@vger.kernel.org,
	 Kees Cook <keescook@chromium.org>,
	selinux@vger.kernel.org,
	 linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	intel-gfx@lists.freedesktop.org,  linux-sctp@vger.kernel.org,
	reiserfs-devel@vger.kernel.org,  linux-geode@lists.infradead.org,
	linux-block@vger.kernel.org,  linux-gpio@vger.kernel.org,
	op-tee@lists.trustedfirmware.org,
	 linux-mediatek@lists.infradead.org,
	nouveau@lists.freedesktop.org,  linux-hams@vger.kernel.org,
	Nathan Chancellor <natechancellor@gmail.com>,
	 linux-can@vger.kernel.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 linux-hwmon@vger.kernel.org,  ,
	maintainer:X86, ARCHITECTURE, (32-BIT, AND, 64-BIT),
	 <x86@kernel.org>,
	 linux-watchdog@vger.kernel.org, GR-Linux-NIC-Dev@marvell.com,
	 Linux Memory Management List <linux-mm@kvack.org>,
	 Network Development <netdev@vger.kernel.org>,
	 linux-decnet-user@lists.sourceforge.net,
	samba-technical@lists.samba.org,
	 LKML <linux-kernel@vger.kernel.org>,
	 Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	 linux-security-module@vger.kernel.org,
	linux-usb@vger.kernel.org,
	 tipc-discussion@lists.sourceforge.net,
	Joe Perches <joe@perches.com>,
	 linux-nfs@vger.kernel.org

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 1306+ messages in thread

* [Intel-wired-lan] [PATCH 000/141] Fix fall-through warnings for Clang
@ 2020-11-25 16:24                               ` Jakub Kicinski
  0 siblings, 0 replies; 1306+ messages in thread
From: Jakub Kicinski @ 2020-11-25 16:24 UTC (permalink / raw)
  To: intel-wired-lan

On Wed, 25 Nov 2020 04:24:27 -0800 Nick Desaulniers wrote:
> I even agree that most of the churn comes from
> 
> case 0:
>   ++x;
> default:
>   break;

And just to spell it out,

case ENUM_VALUE1:
	bla();
	break;
case ENUM_VALUE2:
	bla();
default:
	break;

is a fairly idiomatic way of indicating that not all values of the enum
are expected to be handled by the switch statement. 

I really hope the Clang folks are reasonable and merge your patch.

> If trivial patches are adding too much to your workload, consider
> training a co-maintainer or asking for help from one of your reviewers
> whom you trust.  I don't doubt it's hard to find maintainers, but
> existing maintainers should go out of their way to entrust
> co-maintainers especially when they find their workload becomes too
> high.  And reviewing/picking up trivial patches is probably a great
> way to get started.  If we allow too much knowledge of any one
> subsystem to collect with one maintainer, what happens when that
> maintainer leaves the community (which, given a finite lifespan, is an
> inevitability)?

The burn out point is about enjoying your work and feeling that it
matters. It really doesn't make much difference if you're doing
something you don't like for 12 hours every day or only in shifts with
another maintainer. You'll dislike it either way.

Applying a real patch set and then getting a few follow ups the next day
for trivial coding things like fallthrough missing or static missing,
just because I didn't have the full range of compilers to check with
before applying makes me feel pretty shitty, like I'm not doing a good
job. YMMV.

^ permalink raw reply	[flat|nested] 1306+ messages in thread

end of thread, other threads:[~2020-12-01  7:39 UTC | newest]

Thread overview: 1306+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-20 18:21 [PATCH 000/141] Fix fall-through warnings for Clang Gustavo A. R. Silva
2020-11-20 18:21 ` [Bridge] " Gustavo A. R. Silva
2020-11-20 18:21 ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-20 18:21 ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-20 18:21 ` [dm-devel] " Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:21 ` Gustavo A. R. Silva
2020-11-20 18:23 ` [PATCH 001/141] afs: " Gustavo A. R. Silva
2020-11-20 23:18   ` Joe Perches
2020-11-20 23:28     ` Gustavo A. R. Silva
2020-11-20 23:41       ` Joe Perches
2020-11-23 16:10   ` David Howells
2020-11-23 16:51     ` Joe Perches
2020-11-24 13:21     ` David Howells
2020-11-20 18:23 ` [PATCH 002/141] ASoC: codecs: " Gustavo A. R. Silva
2020-11-20 18:23   ` Gustavo A. R. Silva
2020-11-20 18:24 ` [PATCH 003/141] cifs: " Gustavo A. R. Silva
2020-11-20 18:24 ` [PATCH 004/141] drm/amdgpu: " Gustavo A. R. Silva
2020-11-20 18:24   ` Gustavo A. R. Silva
2020-11-20 18:24   ` Gustavo A. R. Silva
2020-11-20 22:42   ` Alex Deucher
2020-11-20 22:42     ` Alex Deucher
2020-11-20 22:42     ` Alex Deucher
2020-11-23 22:42     ` Gustavo A. R. Silva
2020-11-23 22:42       ` Gustavo A. R. Silva
2020-11-23 22:42       ` Gustavo A. R. Silva
2020-11-20 18:24 ` [PATCH 005/141] drm/radeon: " Gustavo A. R. Silva
2020-11-20 18:24   ` Gustavo A. R. Silva
2020-11-20 18:24   ` Gustavo A. R. Silva
2020-11-20 22:43   ` Alex Deucher
2020-11-20 22:43     ` Alex Deucher
2020-11-20 22:43     ` Alex Deucher
2020-11-20 18:25 ` [PATCH 006/141] gfs2: " Gustavo A. R. Silva
2020-11-20 18:25   ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-20 18:25 ` [PATCH 007/141] gpio: " Gustavo A. R. Silva
2020-11-20 18:56   ` Andy Shevchenko
2020-11-20 18:58     ` Gustavo A. R. Silva
2020-11-20 18:25 ` [PATCH 008/141] IB/hfi1: " Gustavo A. R. Silva
2020-11-22 14:30   ` Mike Marciniszyn
2020-11-23 22:44     ` Gustavo A. R. Silva
2020-11-20 18:25 ` [PATCH 009/141] igb: " Gustavo A. R. Silva
2020-11-20 18:25   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:25 ` [PATCH 010/141] ima: " Gustavo A. R. Silva
2020-11-20 18:25 ` [PATCH 011/141] ipv4: " Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 012/141] ixgbe: " Gustavo A. R. Silva
2020-11-20 18:26   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 013/141] media: dvb-frontends: " Gustavo A. R. Silva
2020-11-22 16:31   ` Mauro Carvalho Chehab
2020-11-23 22:44     ` Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 014/141] media: usb: dvb-usb-v2: " Gustavo A. R. Silva
2020-11-22 16:31   ` Mauro Carvalho Chehab
2020-11-20 18:26 ` [PATCH 015/141] netfilter: " Gustavo A. R. Silva
2020-11-20 22:47   ` Florian Westphal
2020-11-23 22:45     ` Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 016/141] nfsd: " Gustavo A. R. Silva
2020-11-20 18:27   ` Chuck Lever
2020-11-23 22:46     ` Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 017/141] nfs: " Gustavo A. R. Silva
2020-11-20 18:26 ` [PATCH 018/141] qed: " Gustavo A. R. Silva
2020-11-20 18:50   ` [EXT] " Igor Russkikh
2020-11-23 22:46     ` Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 019/141] qlcnic: " Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 020/141] scsi: aic7xxx: " Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 021/141] scsi: aic94xx: " Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 022/141] scsi: bfa: " Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 023/141] staging: rtl8723bs: core: " Gustavo A. R. Silva
2020-11-20 18:27   ` Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 024/141] staging: vt6655: " Gustavo A. R. Silva
2020-11-20 18:27   ` Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 025/141] bnxt_en: " Gustavo A. R. Silva
2020-11-20 18:27 ` [PATCH 026/141] ceph: " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 027/141] drbd: " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 028/141] drm/amd/display: " Gustavo A. R. Silva
2020-11-20 18:28   ` Gustavo A. R. Silva
2020-11-20 18:28   ` Gustavo A. R. Silva
2020-11-20 22:45   ` Alex Deucher
2020-11-20 22:45     ` Alex Deucher
2020-11-20 22:45     ` Alex Deucher
2020-11-23 22:47     ` Gustavo A. R. Silva
2020-11-23 22:47       ` Gustavo A. R. Silva
2020-11-23 22:47       ` Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 029/141] e1000: " Gustavo A. R. Silva
2020-11-20 18:28   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 030/141] ext2: " Gustavo A. R. Silva
2020-11-23  9:37   ` Jan Kara
2020-11-23 22:47     ` Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 031/141] ext4: " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 032/141] floppy: " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 033/141] fm10k: " Gustavo A. R. Silva
2020-11-20 18:28   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 000/141] " Joe Perches
2020-11-20 18:28   ` [Bridge] " Joe Perches
2020-11-20 18:28   ` [Cluster-devel] " Joe Perches
2020-11-20 18:28   ` [Intel-wired-lan] " Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` [Intel-gfx] " Joe Perches
2020-11-20 18:28   ` [dm-devel] " Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 18:28   ` Joe Perches
2020-11-20 19:02   ` Gustavo A. R. Silva
2020-11-20 19:02     ` [Bridge] " Gustavo A. R. Silva
2020-11-20 19:02     ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-20 19:02     ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-20 19:02     ` [dm-devel] " Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 19:02     ` Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 034/141] IB/mlx4: " Gustavo A. R. Silva
2020-11-20 18:28 ` [PATCH 035/141] IB/qedr: " Gustavo A. R. Silva
2020-11-22 20:12   ` [EXT] " Michal Kalderon
2020-11-23 22:48     ` Gustavo A. R. Silva
2020-11-20 18:29 ` [PATCH 036/141] ice: " Gustavo A. R. Silva
2020-11-20 18:29   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 037/141] Input: pcspkr - " Gustavo A. R. Silva
2020-11-23  6:15   ` Dmitry Torokhov
2020-11-23 22:48     ` Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 038/141] isofs: " Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 039/141] ixgbevf: " Gustavo A. R. Silva
2020-11-20 18:30   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 040/141] kprobes/x86: " Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 041/141] mm: " Gustavo A. R. Silva
2020-11-20 18:30 ` [PATCH 042/141] net: 3c509: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 043/141] net: cassini: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 044/141] net/mlx4: " Gustavo A. R. Silva
2020-11-22  8:36   ` Tariq Toukan
2020-11-23 22:49     ` Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 045/141] net: mscc: ocelot: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 046/141] netxen_nic: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 047/141] nfp: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 048/141] perf/x86: " Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 049/141] pinctrl: " Gustavo A. R. Silva
2020-11-20 19:04   ` Geert Uytterhoeven
2020-11-23 22:49     ` Gustavo A. R. Silva
2020-11-20 18:31 ` [PATCH 050/141] RDMA/mlx5: " Gustavo A. R. Silva
2020-11-23  8:33   ` Leon Romanovsky
2020-11-23 22:50     ` Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 051/141] reiserfs: " Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 052/141] security: keys: " Gustavo A. R. Silva
2020-11-23 22:54   ` Jarkko Sakkinen
2020-11-24 14:30     ` Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 053/141] selinux: " Gustavo A. R. Silva
2020-11-23 23:31   ` Paul Moore
2020-11-24 14:30     ` Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 054/141] target: " Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 055/141] uprobes/x86: " Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 056/141] vxge: " Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 057/141] watchdog: " Gustavo A. R. Silva
2020-11-21 18:49   ` Guenter Roeck
2020-11-23 22:50     ` Gustavo A. R. Silva
2020-11-20 18:32 ` [PATCH 058/141] xen-blkfront: " Gustavo A. R. Silva
2020-11-20 21:36   ` boris.ostrovsky
2020-11-23 22:53     ` Gustavo A. R. Silva
2020-11-23 10:28   ` Roger Pau Monné
2020-11-20 18:33 ` [PATCH 059/141] regulator: as3722: " Gustavo A. R. Silva
2020-11-20 18:33 ` [PATCH 060/141] habanalabs: " Gustavo A. R. Silva
2020-11-21 12:34   ` Oded Gabbay
2020-11-23 22:54     ` Gustavo A. R. Silva
2020-11-20 18:33 ` [PATCH 061/141] tee: " Gustavo A. R. Silva
2020-11-22  9:26   ` Jens Wiklander
2020-11-23 22:55     ` Gustavo A. R. Silva
2020-11-20 18:33 ` [PATCH 062/141] HID: usbhid: " Gustavo A. R. Silva
2020-11-25 13:02   ` Jiri Kosina
2020-11-20 18:33 ` [PATCH 063/141] HID: input: " Gustavo A. R. Silva
2020-11-25 13:04   ` Jiri Kosina
2020-11-25 13:34     ` David Laight
2020-11-20 18:33 ` [PATCH 064/141] ACPI: " Gustavo A. R. Silva
2020-11-23 11:43   ` Rafael J. Wysocki
2020-11-20 18:33 ` [PATCH 065/141] airo: " Gustavo A. R. Silva
2020-11-20 18:33 ` [PATCH 066/141] ALSA: hdspm: " Gustavo A. R. Silva
2020-11-20 18:33   ` Gustavo A. R. Silva
2020-11-21  8:30   ` Takashi Iwai
2020-11-21  8:30     ` Takashi Iwai
2020-11-23 22:56     ` Gustavo A. R. Silva
2020-11-23 22:56       ` Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 067/141] ALSA: pcsp: " Gustavo A. R. Silva
2020-11-20 18:34   ` Gustavo A. R. Silva
2020-11-21  8:30   ` Takashi Iwai
2020-11-21  8:30     ` Takashi Iwai
2020-11-20 18:34 ` [PATCH 068/141] ALSA: sb: " Gustavo A. R. Silva
2020-11-20 18:34   ` Gustavo A. R. Silva
2020-11-21  8:29   ` Takashi Iwai
2020-11-21  8:29     ` Takashi Iwai
2020-11-20 18:34 ` [PATCH 069/141] ath5k: " Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 070/141] atm: fore200e: " Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 071/141] braille_console: " Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 072/141] can: peak_usb: " Gustavo A. R. Silva
2020-11-21 13:17   ` Marc Kleine-Budde
2020-11-21 19:50     ` Joe Perches
2020-11-21 23:04       ` Marc Kleine-Budde
2020-11-22  2:46         ` Joe Perches
2020-11-20 18:34 ` [PATCH 073/141] carl9170: " Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 074/141] cfg80211: " Gustavo A. R. Silva
2020-11-20 18:34 ` [PATCH 075/141] crypto: ccree - " Gustavo A. R. Silva
2020-11-22  7:54   ` Gilad Ben-Yossef
2020-11-23 22:57     ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 076/141] decnet: " Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 077/141] dm raid: " Gustavo A. R. Silva
2020-11-20 18:35   ` [dm-devel] " Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 078/141] drm/amd/pm: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 22:46   ` Alex Deucher
2020-11-20 22:46     ` Alex Deucher
2020-11-20 22:46     ` Alex Deucher
2020-11-20 18:35 ` [PATCH 079/141] drm: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-22 22:03   ` Sam Ravnborg
2020-11-22 22:03     ` Sam Ravnborg
2020-11-23 22:57     ` Gustavo A. R. Silva
2020-11-23 22:57       ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 080/141] drm/i915/gem: " Gustavo A. R. Silva
2020-11-20 18:35   ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 081/141] drm/nouveau/clk: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 082/141] drm/nouveau: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 083/141] drm/nouveau/therm: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 084/141] drm/via: " Gustavo A. R. Silva
2020-11-20 18:35   ` Gustavo A. R. Silva
2020-11-22 22:03   ` Sam Ravnborg
2020-11-22 22:03     ` Sam Ravnborg
2020-11-24 14:34     ` Gustavo A. R. Silva
2020-11-24 14:34       ` Gustavo A. R. Silva
2020-11-20 18:35 ` [PATCH 085/141] firewire: core: " Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 086/141] hwmon: (corsair-cpro) " Gustavo A. R. Silva
2020-11-21 18:50   ` Guenter Roeck
2020-11-21 20:00     ` Joe Perches
2020-11-22  0:58       ` Guenter Roeck
2020-11-24 14:35     ` Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 087/141] hwmon: (max6621) " Gustavo A. R. Silva
2020-11-21 18:50   ` Guenter Roeck
2020-11-20 18:36 ` [PATCH 088/141] i3c: master: cdns: " Gustavo A. R. Silva
2020-11-20 18:36   ` Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 089/141] ide: " Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 090/141] iio: adc: cpcap: " Gustavo A. R. Silva
2020-11-21 15:05   ` Jonathan Cameron
2020-11-23 22:59     ` Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 091/141] iwlwifi: iwl-drv: " Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 092/141] libata: " Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 093/141] mac80211: " Gustavo A. R. Silva
2020-11-20 18:36 ` [PATCH 094/141] media: atomisp: " Gustavo A. R. Silva
2020-11-20 18:36   ` Gustavo A. R. Silva
2020-11-22 16:32   ` Mauro Carvalho Chehab
2020-11-22 16:32     ` Mauro Carvalho Chehab
2020-11-20 18:36 ` [PATCH 095/141] media: dvb_frontend: " Gustavo A. R. Silva
2020-11-22 16:32   ` Mauro Carvalho Chehab
2020-11-20 18:37 ` [PATCH 096/141] media: rcar_jpu: " Gustavo A. R. Silva
2020-11-22 16:33   ` Mauro Carvalho Chehab
2020-11-20 18:37 ` [PATCH 097/141] media: saa7134: " Gustavo A. R. Silva
2020-11-22 16:32   ` Mauro Carvalho Chehab
2020-11-20 18:37 ` [PATCH 098/141] mmc: sdhci-of-arasan: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-23  7:00   ` Michal Simek
2020-11-23  7:00     ` Michal Simek
2020-11-23 22:59     ` Gustavo A. R. Silva
2020-11-23 22:59       ` Gustavo A. R. Silva
2020-11-24 14:25   ` Ulf Hansson
2020-11-24 14:25     ` Ulf Hansson
2020-11-24 14:36     ` Gustavo A. R. Silva
2020-11-24 14:36       ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 099/141] mt76: mt7615: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 100/141] mtd: cfi: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 101/141] mtd: mtdchar: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 102/141] mtd: onenand: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 103/141] mtd: rawnand: fsmc: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 104/141] mtd: rawnand: stm32_fmc2: " Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-20 18:37   ` Gustavo A. R. Silva
2020-11-23  8:33   ` Miquel Raynal
2020-11-23  8:33     ` Miquel Raynal
2020-11-23  8:33     ` Miquel Raynal
2020-11-20 18:37 ` [PATCH 105/141] net: ax25: " Gustavo A. R. Silva
2020-11-20 18:37 ` [PATCH 106/141] net: bridge: " Gustavo A. R. Silva
2020-11-20 18:37   ` [Bridge] " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 107/141] net: core: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 108/141] netfilter: ipt_REJECT: " Gustavo A. R. Silva
2020-11-20 22:49   ` Florian Westphal
2020-11-24 14:37     ` Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 109/141] net: netrom: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 110/141] net/packet: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 111/141] net: plip: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 112/141] net: rose: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 113/141] nl80211: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 114/141] phy: qcom-usb-hs: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 115/141] rds: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 116/141] rt2x00: " Gustavo A. R. Silva
2020-11-20 18:38 ` [PATCH 117/141] rtl8xxxu: " Gustavo A. R. Silva
2020-11-20 21:39   ` Jes Sorensen
2020-11-24 16:09     ` Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 118/141] rtw88: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 119/141] rxrpc: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 120/141] scsi: aacraid: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 121/141] scsi: aha1740: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 122/141] scsi: csiostor: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 123/141] scsi: lpfc: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 124/141] scsi: stex: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 125/141] sctp: " Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 126/141] slimbus: messaging: " Gustavo A. R. Silva
2020-11-20 18:39   ` Gustavo A. R. Silva
2020-11-24 10:48   ` Srinivas Kandagatla
2020-11-24 14:38     ` Gustavo A. R. Silva
2020-11-20 18:39 ` [PATCH 127/141] staging: qlge: " Gustavo A. R. Silva
2020-11-20 18:39   ` Gustavo A. R. Silva
2020-11-25  4:42   ` Benjamin Poirier
2020-11-25  4:42     ` Benjamin Poirier
2020-11-20 18:39 ` [PATCH 128/141] staging: vt6656: " Gustavo A. R. Silva
2020-11-20 18:39   ` Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 129/141] SUNRPC: " Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 130/141] tipc: " Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 131/141] tpm: " Gustavo A. R. Silva
2020-11-23 22:52   ` Jarkko Sakkinen
2020-11-23 22:53     ` Jarkko Sakkinen
2020-11-24 14:40       ` Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 132/141] ubi: " Gustavo A. R. Silva
2020-11-20 18:40   ` Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 133/141] usb: " Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 134/141] video: fbdev: lxfb_ops: " Gustavo A. R. Silva
2020-11-20 18:40   ` Gustavo A. R. Silva
2020-11-22 22:05   ` Sam Ravnborg
2020-11-22 22:05     ` Sam Ravnborg
2020-11-24 14:44     ` Gustavo A. R. Silva
2020-11-24 14:44       ` Gustavo A. R. Silva
2020-11-24 20:58       ` deloptes
2020-11-20 18:40 ` [PATCH 135/141] video: fbdev: pm2fb: " Gustavo A. R. Silva
2020-11-20 18:40   ` Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 136/141] virtio_net: " Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 137/141] wcn36xx: " Gustavo A. R. Silva
2020-11-20 18:40 ` [PATCH 138/141] xen/manage: " Gustavo A. R. Silva
2020-11-20 18:41 ` [PATCH 139/141] xfrm: " Gustavo A. R. Silva
2020-11-20 18:41 ` [PATCH 140/141] zd1201: " Gustavo A. R. Silva
2020-11-20 18:41 ` [PATCH 141/141] Input: libps2 - " Gustavo A. R. Silva
2020-11-23  6:16   ` Dmitry Torokhov
2020-11-24 14:44     ` Gustavo A. R. Silva
2020-11-20 18:53 ` [PATCH 000/141] " Jakub Kicinski
2020-11-20 18:53   ` [Bridge] " Jakub Kicinski
2020-11-20 18:53   ` [Cluster-devel] " Jakub Kicinski
2020-11-20 18:53   ` [Intel-wired-lan] " Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` [Intel-gfx] " Jakub Kicinski
2020-11-20 18:53   ` [dm-devel] " Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 18:53   ` Jakub Kicinski
2020-11-20 19:04   ` Gustavo A. R. Silva
2020-11-20 19:04     ` [Bridge] " Gustavo A. R. Silva
2020-11-20 19:04     ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-20 19:04     ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-20 19:04     ` [dm-devel] " Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:04     ` Gustavo A. R. Silva
2020-11-20 19:30   ` Kees Cook
2020-11-20 19:30     ` [Bridge] " Kees Cook
2020-11-20 19:30     ` [Cluster-devel] " Kees Cook
2020-11-20 19:30     ` [Intel-wired-lan] " Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` [Intel-gfx] " Kees Cook
2020-11-20 19:30     ` [dm-devel] " Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:30     ` Kees Cook
2020-11-20 19:51     ` Jakub Kicinski
2020-11-20 19:51       ` [Bridge] " Jakub Kicinski
2020-11-20 19:51       ` [Cluster-devel] " Jakub Kicinski
2020-11-20 19:51       ` [Intel-wired-lan] " Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` [Intel-gfx] " Jakub Kicinski
2020-11-20 19:51       ` [dm-devel] " Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 19:51       ` Jakub Kicinski
2020-11-20 20:48       ` Kees Cook
2020-11-20 20:48         ` [Bridge] " Kees Cook
2020-11-20 20:48         ` [Cluster-devel] " Kees Cook
2020-11-20 20:48         ` [Intel-wired-lan] " Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` [Intel-gfx] " Kees Cook
2020-11-20 20:48         ` [dm-devel] " Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-20 20:48         ` Kees Cook
2020-11-22 16:17       ` Kees Cook
2020-11-22 16:17         ` [Bridge] " Kees Cook
2020-11-22 16:17         ` [Cluster-devel] " Kees Cook
2020-11-22 16:17         ` [Intel-wired-lan] " Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` [Intel-gfx] " Kees Cook
2020-11-22 16:17         ` [dm-devel] " Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 16:17         ` Kees Cook
2020-11-22 18:21         ` James Bottomley
2020-11-22 18:21           ` [Bridge] " James Bottomley
2020-11-22 18:21           ` [Cluster-devel] " James Bottomley
2020-11-22 18:21           ` [Intel-wired-lan] " James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` [Intel-gfx] " James Bottomley
2020-11-22 18:21           ` [dm-devel] " James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:21           ` James Bottomley
2020-11-22 18:25           ` Joe Perches
2020-11-22 18:25             ` [Bridge] " Joe Perches
2020-11-22 18:25             ` [Cluster-devel] " Joe Perches
2020-11-22 18:25             ` [Intel-wired-lan] " Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` [Intel-gfx] " Joe Perches
2020-11-22 18:25             ` [dm-devel] " Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 18:25             ` Joe Perches
2020-11-22 19:12             ` James Bottomley
2020-11-22 19:12               ` [Bridge] " James Bottomley
2020-11-22 19:12               ` [Cluster-devel] " James Bottomley
2020-11-22 19:12               ` [Intel-wired-lan] " James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` [Intel-gfx] " James Bottomley
2020-11-22 19:12               ` [dm-devel] " James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:12               ` James Bottomley
2020-11-22 19:22               ` Joe Perches
2020-11-22 19:22                 ` [Bridge] " Joe Perches
2020-11-22 19:22                 ` [Cluster-devel] " Joe Perches
2020-11-22 19:22                 ` [Intel-wired-lan] " Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` [Intel-gfx] " Joe Perches
2020-11-22 19:22                 ` [dm-devel] " Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:22                 ` Joe Perches
2020-11-22 19:53                 ` James Bottomley
2020-11-22 19:53                   ` [Bridge] " James Bottomley
2020-11-22 19:53                   ` [Cluster-devel] " James Bottomley
2020-11-22 19:53                   ` [Intel-wired-lan] " James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` [Intel-gfx] " James Bottomley
2020-11-22 19:53                   ` [dm-devel] " James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-22 19:53                   ` James Bottomley
2020-11-23 13:03                   ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-23 13:03                     ` [Bridge] " Gustavo A. R. Silva
2020-11-23 13:03                     ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-23 13:03                     ` [dm-devel] " Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 13:03                     ` Gustavo A. R. Silva
2020-11-23 16:31                     ` James Bottomley
2020-11-23 16:31                       ` [Bridge] " James Bottomley
2020-11-23 16:31                       ` [Cluster-devel] " James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` [Intel-gfx] " James Bottomley
2020-11-23 16:31                       ` [dm-devel] " James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-23 16:31                       ` James Bottomley
2020-11-24 21:32                       ` Kees Cook
2020-11-24 21:32                         ` [Bridge] " Kees Cook
2020-11-24 21:32                         ` [Cluster-devel] " Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` [Intel-gfx] " Kees Cook
2020-11-24 21:32                         ` [dm-devel] " Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 21:32                         ` Kees Cook
2020-11-24 22:24                         ` Finn Thain
2020-11-24 22:24                           ` [Bridge] " Finn Thain
2020-11-24 22:24                           ` [Cluster-devel] " Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` [Intel-gfx] " Finn Thain
2020-11-24 22:24                           ` [dm-devel] " Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 22:24                           ` Finn Thain
2020-11-24 23:15                           ` Miguel Ojeda
2020-11-24 23:15                             ` [Bridge] " Miguel Ojeda
2020-11-24 23:15                             ` [Cluster-devel] " Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` [Intel-gfx] " Miguel Ojeda
2020-11-24 23:15                             ` [dm-devel] " Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:15                             ` Miguel Ojeda
2020-11-24 23:53                             ` Finn Thain
2020-11-24 23:53                               ` [Bridge] " Finn Thain
2020-11-24 23:53                               ` [Cluster-devel] " Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` [Intel-gfx] " Finn Thain
2020-11-24 23:53                               ` [dm-devel] " Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-24 23:53                               ` Finn Thain
2020-11-25  1:05                               ` Miguel Ojeda
2020-11-25  1:05                                 ` [Bridge] " Miguel Ojeda
2020-11-25  1:05                                 ` [Cluster-devel] " Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` [Intel-gfx] " Miguel Ojeda
2020-11-25  1:05                                 ` [dm-devel] " Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  1:05                                 ` Miguel Ojeda
2020-11-25  7:05                         ` James Bottomley
2020-11-25  7:05                           ` [Bridge] " James Bottomley
2020-11-25  7:05                           ` [Cluster-devel] " James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` [Intel-gfx] " James Bottomley
2020-11-25  7:05                           ` [dm-devel] " James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25  7:05                           ` James Bottomley
2020-11-25 12:24                           ` Nick Desaulniers
2020-11-25 12:24                             ` [Bridge] " Nick Desaulniers
2020-11-25 12:24                             ` [Cluster-devel] " Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` [Intel-gfx] " Nick Desaulniers
2020-11-25 12:24                             ` [dm-devel] " Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers via Virtualization
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
2020-11-25 12:24                             ` Nick Desaulniers
     [not found]                             ` <CAKwvOdkGBn7nuWTAqrORMeN1G+w3YwBfCqqaRD2nwvoAXKi=Aw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-11-25 16:24                               ` Jakub Kicinski
2020-11-25 16:24                             ` Jakub Kicinski
2020-11-25 16:24                               ` Jakub Kicinski
2020-11-25 16:24                               ` Jakub Kicinski
2020-11-25 16:24                               ` [Intel-gfx] " Jakub Kicinski
2020-11-25 16:24                               ` [dm-devel] " Jakub Kicinski
2020-11-25 16:24                               ` Jakub Kicinski
2020-11-25 16:24                               ` Jakub Kicinski
2020-11-22 20:35           ` Miguel Ojeda
2020-11-22 20:35             ` [Bridge] " Miguel Ojeda
2020-11-22 20:35             ` [Cluster-devel] " Miguel Ojeda
2020-11-22 20:35             ` [Intel-wired-lan] " Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` [Intel-gfx] " Miguel Ojeda
2020-11-22 20:35             ` [dm-devel] " Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 20:35             ` Miguel Ojeda
2020-11-22 22:36             ` James Bottomley
2020-11-22 22:36               ` [Bridge] " James Bottomley
2020-11-22 22:36               ` [Cluster-devel] " James Bottomley
2020-11-22 22:36               ` [Intel-wired-lan] " James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` [Intel-gfx] " James Bottomley
2020-11-22 22:36               ` [dm-devel] " James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-22 22:36               ` James Bottomley
2020-11-23 14:19               ` Miguel Ojeda
2020-11-23 14:19                 ` [Bridge] " Miguel Ojeda
2020-11-23 14:19                 ` [Cluster-devel] " Miguel Ojeda
2020-11-23 14:19                 ` [Intel-wired-lan] " Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` [Intel-gfx] " Miguel Ojeda
2020-11-23 14:19                 ` [dm-devel] " Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 14:19                 ` Miguel Ojeda
2020-11-23 15:58                 ` James Bottomley
2020-11-23 15:58                   ` [Bridge] " James Bottomley
2020-11-23 15:58                   ` [Cluster-devel] " James Bottomley
2020-11-23 15:58                   ` [Intel-wired-lan] " James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` [Intel-gfx] " James Bottomley
2020-11-23 15:58                   ` [dm-devel] " James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 15:58                   ` James Bottomley
2020-11-23 16:24                   ` Rafael J. Wysocki
2020-11-23 16:24                     ` [Bridge] " Rafael J. Wysocki
2020-11-23 16:24                     ` [Cluster-devel] " Rafael J. Wysocki
2020-11-23 16:24                     ` [Intel-wired-lan] " Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` [Intel-gfx] " Rafael J. Wysocki
2020-11-23 16:24                     ` [dm-devel] " Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:24                     ` Rafael J. Wysocki
2020-11-23 16:32                   ` Joe Perches
2020-11-23 16:32                     ` [Bridge] " Joe Perches
2020-11-23 16:32                     ` [Cluster-devel] " Joe Perches
2020-11-23 16:32                     ` [Intel-wired-lan] " Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` [Intel-gfx] " Joe Perches
2020-11-23 16:32                     ` [dm-devel] " Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 16:32                     ` Joe Perches
2020-11-23 18:56                   ` Miguel Ojeda
2020-11-23 18:56                     ` [Bridge] " Miguel Ojeda
2020-11-23 18:56                     ` [Cluster-devel] " Miguel Ojeda
2020-11-23 18:56                     ` [Intel-wired-lan] " Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` [Intel-gfx] " Miguel Ojeda
2020-11-23 18:56                     ` [dm-devel] " Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 18:56                     ` Miguel Ojeda
2020-11-23 20:37                     ` James Bottomley
2020-11-23 20:37                       ` [Bridge] " James Bottomley
2020-11-23 20:37                       ` [Cluster-devel] " James Bottomley
2020-11-23 20:37                       ` [Intel-wired-lan] " James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` [Intel-gfx] " James Bottomley
2020-11-23 20:37                       ` [dm-devel] " James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-23 20:37                       ` James Bottomley
2020-11-25  0:32                       ` Miguel Ojeda
2020-11-25  0:32                         ` [Bridge] " Miguel Ojeda
2020-11-25  0:32                         ` [Cluster-devel] " Miguel Ojeda
2020-11-25  0:32                         ` [Intel-wired-lan] " Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` [Intel-gfx] " Miguel Ojeda
2020-11-25  0:32                         ` [dm-devel] " Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25  0:32                         ` Miguel Ojeda
2020-11-25 10:38                       ` Andy Shevchenko
2020-11-25 10:38                         ` [Bridge] " Andy Shevchenko
2020-11-25 10:38                         ` [Cluster-devel] " Andy Shevchenko
2020-11-25 10:38                         ` [Intel-wired-lan] " Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25 10:38                         ` [Intel-gfx] " Andy Shevchenko
2020-11-25 10:38                         ` [dm-devel] " Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25 10:38                         ` Andy Shevchenko
2020-11-25  9:01                   ` Sean Young
2020-11-25  9:01                     ` [Bridge] " Sean Young
2020-11-25  9:01                     ` [Cluster-devel] " Sean Young
2020-11-25  9:01                     ` [Intel-wired-lan] " Sean Young
2020-11-25  9:01                     ` Sean Young
2020-11-25  9:01                     ` Sean Young
2020-11-25  9:01                     ` [Intel-gfx] " Sean Young
2020-11-25  9:01                     ` [dm-devel] " Sean Young
2020-11-25  9:01                     ` Sean Young
2020-11-25  9:01                     ` Sean Young
2020-11-25  9:01                     ` Sean Young
2020-11-22 22:54             ` Finn Thain
2020-11-22 22:54               ` [Bridge] " Finn Thain
2020-11-22 22:54               ` [Cluster-devel] " Finn Thain
2020-11-22 22:54               ` [Intel-wired-lan] " Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 22:54               ` [Intel-gfx] " Finn Thain
2020-11-22 22:54               ` [dm-devel] " Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 22:54               ` Finn Thain
2020-11-22 23:04               ` James Bottomley
2020-11-22 23:04                 ` [Bridge] " James Bottomley
2020-11-22 23:04                 ` [Cluster-devel] " James Bottomley
2020-11-22 23:04                 ` [Intel-wired-lan] " James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` [Intel-gfx] " James Bottomley
2020-11-22 23:04                 ` [dm-devel] " James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-22 23:04                 ` James Bottomley
2020-11-23 14:05               ` Miguel Ojeda
2020-11-23 14:05                 ` [Bridge] " Miguel Ojeda
2020-11-23 14:05                 ` [Cluster-devel] " Miguel Ojeda
2020-11-23 14:05                 ` [Intel-wired-lan] " Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` [Intel-gfx] " Miguel Ojeda
2020-11-23 14:05                 ` [dm-devel] " Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-23 14:05                 ` Miguel Ojeda
2020-11-24  0:58                 ` Finn Thain
2020-11-24  0:58                   ` [Bridge] " Finn Thain
2020-11-24  0:58                   ` [Cluster-devel] " Finn Thain
2020-11-24  0:58                   ` [Intel-wired-lan] " Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` [Intel-gfx] " Finn Thain
2020-11-24  0:58                   ` [dm-devel] " Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  0:58                   ` Finn Thain
2020-11-24  1:05                   ` Joe Perches
2020-11-24  1:05                     ` [Bridge] " Joe Perches
2020-11-24  1:05                     ` [Cluster-devel] " Joe Perches
2020-11-24  1:05                     ` [Intel-wired-lan] " Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` [Intel-gfx] " Joe Perches
2020-11-24  1:05                     ` [dm-devel] " Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  1:05                     ` Joe Perches
2020-11-24  2:48                     ` Finn Thain
2020-11-24  2:48                       ` [Bridge] " Finn Thain
2020-11-24  2:48                       ` [Cluster-devel] " Finn Thain
2020-11-24  2:48                       ` [Intel-wired-lan] " Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` [Intel-gfx] " Finn Thain
2020-11-24  2:48                       ` [dm-devel] " Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24  2:48                       ` Finn Thain
2020-11-24 23:46                   ` Miguel Ojeda
2020-11-24 23:46                     ` [Bridge] " Miguel Ojeda
2020-11-24 23:46                     ` [Cluster-devel] " Miguel Ojeda
2020-11-24 23:46                     ` [Intel-wired-lan] " Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` [Intel-gfx] " Miguel Ojeda
2020-11-24 23:46                     ` [dm-devel] " Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-24 23:46                     ` Miguel Ojeda
2020-11-22 22:10           ` Sam Ravnborg
2020-11-22 22:10             ` [Bridge] " Sam Ravnborg
2020-11-22 22:10             ` [Cluster-devel] " Sam Ravnborg
2020-11-22 22:10             ` [Intel-wired-lan] " Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` [Intel-gfx] " Sam Ravnborg
2020-11-22 22:10             ` [dm-devel] " Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-22 22:10             ` Sam Ravnborg
2020-11-24  1:32         ` Nick Desaulniers
2020-11-24  1:32           ` [Bridge] " Nick Desaulniers
2020-11-24  1:32           ` [Cluster-devel] " Nick Desaulniers
2020-11-24  1:32           ` [Intel-wired-lan] " Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` [Intel-gfx] " Nick Desaulniers
2020-11-24  1:32           ` [dm-devel] " Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers via Virtualization
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
2020-11-24  1:32           ` Nick Desaulniers
     [not found]           ` <CAKwvOdntVfXj2WRR5n6Kw7BfG7FdKpTeHeh5nPu5AzwVMhOHTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-11-24  1:46             ` Jakub Kicinski
2020-11-24  1:46           ` Jakub Kicinski
2020-11-24  1:46             ` [Bridge] " Jakub Kicinski
2020-11-24  1:46             ` [Cluster-devel] " Jakub Kicinski
2020-11-24  1:46             ` [Intel-wired-lan] " Jakub Kicinski
2020-11-24  1:46             ` Jakub Kicinski
2020-11-24  1:46             ` [Intel-gfx] " Jakub Kicinski
2020-11-24  1:46             ` [dm-devel] " Jakub Kicinski
2020-11-24  1:46             ` Jakub Kicinski
2020-11-24  1:46             ` Jakub Kicinski
2020-11-24  1:46             ` Jakub Kicinski
     [not found]             ` <CAKwvOdkxY4pXN4wbYM_B1cLjr8uX6sQ2iS=m=rRGL_TkJQUFZw@mail.gmail.com>
2020-11-24  2:29               ` Joe Perches
2020-11-24 21:25           ` Kees Cook
2020-11-24 21:25             ` [Bridge] " Kees Cook
2020-11-24 21:25             ` [Cluster-devel] " Kees Cook
2020-11-24 21:25             ` [Intel-wired-lan] " Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` [Intel-gfx] " Kees Cook
2020-11-24 21:25             ` [dm-devel] " Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-24 21:25             ` Kees Cook
2020-11-20 22:21 ` Miguel Ojeda
2020-11-20 22:21   ` [Bridge] " Miguel Ojeda
2020-11-20 22:21   ` [Cluster-devel] " Miguel Ojeda
2020-11-20 22:21   ` [Intel-wired-lan] " Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` [Intel-gfx] " Miguel Ojeda
2020-11-20 22:21   ` [dm-devel] " Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-20 22:21   ` Miguel Ojeda
2020-11-23 20:03 ` Jason Gunthorpe
2020-11-23 20:03   ` [Bridge] " Jason Gunthorpe
2020-11-23 20:03   ` [Cluster-devel] " Jason Gunthorpe
2020-11-23 20:03   ` [Intel-wired-lan] " Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` [Intel-gfx] " Jason Gunthorpe
2020-11-23 20:03   ` [dm-devel] " Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-23 20:03   ` Jason Gunthorpe
2020-11-24 14:47   ` Gustavo A. R. Silva
2020-11-24 14:47     ` [Bridge] " Gustavo A. R. Silva
2020-11-24 14:47     ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-24 14:47     ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-24 14:47     ` [dm-devel] " Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-23 20:38 ` Mark Brown
2020-11-23 20:38   ` [Bridge] " Mark Brown
2020-11-23 20:38   ` [Cluster-devel] " Mark Brown
2020-11-23 20:38   ` [Intel-wired-lan] " Mark Brown
2020-11-23 20:38   ` Mark Brown
2020-11-23 20:38   ` [Intel-gfx] " Mark Brown
2020-11-23 20:38   ` [dm-devel] " Mark Brown
2020-11-23 20:38   ` Mark Brown
2020-11-23 20:38   ` Mark Brown
2020-11-23 20:38   ` Mark Brown
2020-11-24 14:47   ` Gustavo A. R. Silva
2020-11-24 14:47     ` [Bridge] " Gustavo A. R. Silva
2020-11-24 14:47     ` [Cluster-devel] " Gustavo A. R. Silva
2020-11-24 14:47     ` [Intel-wired-lan] " Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` [Intel-gfx] " Gustavo A. R. Silva
2020-11-24 14:47     ` [dm-devel] " Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva
2020-11-24 14:47     ` Gustavo A. R. Silva

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.