* [GIT] Security subsystem upate for 3.18
@ 2014-10-10 8:23 James Morris
2014-10-12 14:12 ` Linus Torvalds
0 siblings, 1 reply; 10+ messages in thread
From: James Morris @ 2014-10-10 8:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel, Stephen Rothwell
This is the security subsystem update for 3.18.
I'm not entirely sure what's going on with the diffstat output below --
it shows a bunch of unrelated changes. The summary log is correct,
however.
Stephen Rothwell suggested it's from having two merge bases:
$ git merge-base -a origin/master security/next
478d085524c57cf4283699f529d5a4c22188ea69
19583ca584d6f574384e17fe7613dfaeadcdc4a6
One of these is from merging with your v3.16, and the other from a merge
of the keys tree. That's about all I understand of it.
---
The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9:
Linux 3.17 (2014-10-05 12:23:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
Casey Schaufler (1):
Smack: Bring-up access mode
David Howells (21):
KEYS: Set pr_fmt() in asymmetric key signature handling
KEYS: Fix missing statics
PKCS#7: Add a missing static
KEYS: Reinstate EPERM for a key type name beginning with a '.'
PKCS#7: Provide a single place to do signed info block freeing
PKCS#7: Fix the parser cleanup to drain parsed out X.509 certs
Merge tag 'keys-fixes-20140916' into keys-next
Merge tag 'keys-next-fixes-20140916' into keys-next
Provide a binary to hex conversion function
KEYS: Preparse match data
KEYS: Remove key_type::def_lookup_type
KEYS: Remove key_type::match in favour of overriding default by match_preparse
KEYS: Make the key matching functions return bool
KEYS: Update the keyrings documentation for match changes
KEYS: Implement binary asymmetric key ID handling
KEYS: Overhaul key identification when searching for asymmetric keys
PKCS#7: Better handling of unsupported crypto
PKCS#7: Handle PKCS#7 messages that contain no X.509 certs
Merge tag 'keys-pkcs7-20140916' into keys-next
KEYS: Check hex2bin()'s return when generating an asymmetric key ID
X.509: If available, use the raw subjKeyId to form the key description
Dmitry Kasatkin (26):
ima: prevent buffer overflow in ima_alloc_tfm()
ima: fix fallback to use new_sync_read()
evm: fix checkpatch warnings
evm: prevent passing integrity check if xattr read fails
ima: provide flag to identify new empty files
evm: properly handle INTEGRITY_NOXATTRS EVM status
ima: pass 'opened' flag to identify newly created files
integrity: prevent flooding with 'Request for unknown key'
integrity: remove declaration of non-existing functions
ima: simplify conditional statement to improve performance
ima: remove unnecessary extra variable
ima: add missing '__init' keywords
ima: remove unnecessary appraisal test
ima: remove usage of filename parameter
ima: initialize only required template
integrity: move asymmetric keys config option
integrity: base integrity subsystem kconfig options on integrity
integrity: make integrity files as 'integrity' module
ima: move keyring initialization to ima_init()
ima: provide 'ima_appraise=log' kernel option
KEYS: handle error code encoded in pointer
KEYS: Restore partial ID matching functionality for asymmetric keys
KEYS: use swapped SKID for performing partial matching
KEYS: strip 'id:' from ca_keyid
KEYS: output last portion of fingerprint in /proc/keys
integrity: do zero padding of the key id
James Morris (6):
Merge branch 'next' of git://git.kernel.org/.../zohar/linux-integrity into next
Merge branch 'smack-for-3.18' of git://git.gitorious.org/smack-next/kernel into next
Merge tag 'keys-next-20140922' of git://git.kernel.org/.../dhowells/linux-fs into next
Merge commit 'v3.16' into next
Merge branch 'next' of git://git.infradead.org/users/pcmoore/selinux into next
Merge branch 'next' of git://git.kernel.org/.../zohar/linux-integrity into next
Jiri Pirko (1):
selinux: register nf hooks with single nf_register_hooks call
Kees Cook (1):
seccomp: Add reviewers to MAINTAINERS
Konstantin Khlebnikov (3):
Smack: fix behavior of smack_inode_listsecurity
Smack: handle zero-length security labels without panic
Smack: remove unneeded NULL-termination from securtity label
Lukasz Pawelczyk (3):
Small fixes in comments describing function parameters
Fix a bidirectional UDS connect check typo
Make Smack operate on smack_known struct where it still used char*
Marcin Niesluchowski (1):
Smack: Fix setting label on successful file open
Mark Rustad (1):
security: Silence shadow warning
Mimi Zohar (1):
ima: fix ima_alloc_atfm()
Paul Moore (3):
Merge tag 'v3.16' into next
selinux: fix a problem with IPv6 traffic denials in selinux_ip_postroute()
selinux: make the netif cache namespace aware
Richard Guy Briggs (2):
selinux: cleanup error reporting in selinux_nlmsg_perm()
selinux: normalize audit log formatting
Roberto Sassu (4):
ima: return an error code from ima_add_boot_aggregate()
ima: added ima_policy_flag variable
ima: fix race condition on ima_rdwr_violation_check and process_measurement
ima: detect violations for mmaped files
Stephen Smalley (1):
selinux: Permit bounded transitions under NO_NEW_PRIVS or NOSUID.
.mailmap | 5 +
CREDITS | 7 +-
Documentation/acpi/enumeration.txt | 6 -
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 6 +-
Documentation/input/event-codes.txt | 13 +
Documentation/kernel-parameters.txt | 10 +-
Documentation/security/keys.txt | 65 ++-
MAINTAINERS | 26 +-
Makefile | 4 +-
arch/arm/Kconfig | 5 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 4 +-
arch/arm/boot/dts/hi3620.dtsi | 2 +-
arch/arm/boot/dts/omap3-n900.dts | 2 +-
arch/arm/boot/dts/r8a7791.dtsi | 4 +-
arch/arm/boot/dts/ste-nomadik-s8815.dts | 2 +-
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 7 +-
arch/arm/crypto/aesbs-glue.c | 10 +-
arch/arm/include/asm/mach/arch.h | 1 +
arch/arm/kernel/devtree.c | 8 +-
arch/arm/kernel/iwmmxt.S | 23 +-
arch/arm/kernel/kgdb.c | 4 +
arch/arm/kernel/topology.c | 2 +-
arch/arm/mach-exynos/exynos.c | 10 +
arch/arm/mach-exynos/hotplug.c | 10 +-
arch/arm/mach-exynos/platsmp.c | 34 +-
arch/arm/mach-imx/clk-imx6q.c | 4 +-
arch/arm/mach-mvebu/coherency.c | 6 +-
arch/arm/mach-mvebu/headsmp-a9.S | 9 +-
arch/arm/mach-mvebu/pmsu.c | 10 +-
arch/arm/mach-omap2/gpmc-nand.c | 18 +-
arch/arm/mach-omap2/omap4-common.c | 4 +
arch/arm/mm/dma-mapping.c | 11 +-
arch/arm/mm/idmap.c | 12 +
arch/arm/mm/mmu.c | 6 +-
arch/arm/xen/grant-table.c | 5 +
arch/arm64/Kconfig | 1 +
arch/arm64/crypto/aes-glue.c | 12 +-
arch/arm64/kernel/efi-stub.c | 2 -
arch/arm64/mm/init.c | 17 +-
arch/blackfin/configs/BF609-EZKIT_defconfig | 2 +-
arch/blackfin/kernel/vmlinux.lds.S | 2 +-
arch/blackfin/mach-bf533/boards/blackstamp.c | 1 +
arch/blackfin/mach-bf537/boards/cm_bf537e.c | 1 +
arch/blackfin/mach-bf537/boards/cm_bf537u.c | 1 +
arch/blackfin/mach-bf537/boards/tcm_bf537.c | 1 +
arch/blackfin/mach-bf548/boards/ezkit.c | 6 +-
arch/blackfin/mach-bf561/boards/acvilon.c | 1 +
arch/blackfin/mach-bf561/boards/cm_bf561.c | 1 +
arch/blackfin/mach-bf561/boards/ezkit.c | 1 +
arch/blackfin/mach-bf609/boards/ezkit.c | 20 +-
arch/blackfin/mach-bf609/include/mach/pm.h | 5 +-
arch/blackfin/mach-bf609/pm.c | 4 +-
arch/blackfin/mach-common/ints-priority.c | 2 -
arch/parisc/include/uapi/asm/signal.h | 2 -
arch/parisc/mm/init.c | 1 -
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/cputable.h | 1 +
arch/powerpc/include/asm/kvm_book3s_64.h | 19 +-
arch/powerpc/include/asm/mmu-hash64.h | 3 +-
arch/powerpc/include/asm/ppc_asm.h | 2 +
arch/powerpc/kernel/cputable.c | 20 +
arch/powerpc/kernel/rtas_flash.c | 6 +-
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 7 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
arch/powerpc/kvm/book3s_interrupts.S | 4 +
arch/powerpc/kvm/book3s_rmhandlers.S | 6 +-
arch/powerpc/kvm/book3s_rtas.c | 65 +--
arch/powerpc/kvm/e500_mmu_host.c | 3 +-
arch/powerpc/lib/mem_64.S | 2 +-
arch/powerpc/lib/sstep.c | 10 +-
arch/powerpc/net/bpf_jit_comp.c | 10 +-
arch/powerpc/perf/core-book3s.c | 6 +-
arch/powerpc/platforms/powernv/opal-elog.c | 4 +-
arch/powerpc/platforms/pseries/dlpar.c | 1 +
arch/powerpc/platforms/pseries/reconfig.c | 1 +
arch/s390/include/asm/switch_to.h | 4 +-
arch/s390/kernel/head.S | 6 +-
arch/s390/kernel/ptrace.c | 12 +-
arch/s390/pci/pci.c | 49 +--
arch/sh/Makefile | 3 +-
arch/sparc/Kconfig | 1 +
arch/sparc/include/uapi/asm/unistd.h | 3 +-
arch/sparc/kernel/sys32.S | 1 +
arch/sparc/kernel/systbls_32.S | 1 +
arch/sparc/kernel/systbls_64.S | 2 +
arch/um/kernel/tlb.c | 9 +-
arch/um/kernel/trap.c | 2 +-
arch/um/os-Linux/skas/process.c | 9 +-
arch/x86/Kconfig | 1 +
arch/x86/boot/header.S | 26 +-
arch/x86/boot/tools/build.c | 38 ++-
arch/x86/include/asm/irqflags.h | 2 +-
arch/x86/kernel/apm_32.c | 1 -
arch/x86/kernel/cpu/intel.c | 22 +-
arch/x86/kernel/cpu/intel_cacheinfo.c | 12 +
arch/x86/kernel/cpu/mcheck/mce.c | 10 +-
arch/x86/kernel/cpu/perf_event.c | 3 +
arch/x86/kernel/cpu/perf_event.h | 12 +-
arch/x86/kernel/cpu/perf_event_intel.c | 78 +++-
arch/x86/kernel/cpu/perf_event_intel_ds.c | 6 +-
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 11 +-
arch/x86/kernel/entry_32.S | 9 +-
arch/x86/kernel/entry_64.S | 28 +-
arch/x86/kernel/espfix_64.c | 5 +-
arch/x86/kernel/kprobes/core.c | 3 +
arch/x86/kernel/paravirt_patch_64.c | 2 -
arch/x86/kernel/tsc.c | 4 +-
arch/x86/kvm/x86.c | 12 +
arch/x86/xen/grant-table.c | 148 ++++--
arch/xtensa/kernel/vectors.S | 158 +++++-
arch/xtensa/kernel/vmlinux.lds.S | 4 +-
arch/xtensa/mm/init.c | 2 +-
block/blk-cgroup.c | 7 +
block/blk-tag.c | 33 +-
block/compat_ioctl.c | 1 +
crypto/af_alg.c | 2 +
crypto/asymmetric_keys/asymmetric_keys.h | 5 +-
crypto/asymmetric_keys/asymmetric_type.c | 265 ++++++++---
crypto/asymmetric_keys/pkcs7_key_type.c | 2 -
crypto/asymmetric_keys/pkcs7_parser.c | 99 +++--
crypto/asymmetric_keys/pkcs7_parser.h | 6 +-
crypto/asymmetric_keys/pkcs7_trust.c | 90 +++-
crypto/asymmetric_keys/pkcs7_verify.c | 102 +++--
crypto/asymmetric_keys/signature.c | 1 +
crypto/asymmetric_keys/x509_cert_parser.c | 57 ++-
crypto/asymmetric_keys/x509_parser.h | 8 +-
crypto/asymmetric_keys/x509_public_key.c | 115 +++--
drivers/acpi/video.c | 10 +-
drivers/ata/ahci.c | 1 +
drivers/ata/libata-core.c | 12 +-
drivers/ata/libata-eh.c | 9 +-
drivers/ata/pata_ep93xx.c | 2 +-
drivers/base/platform.c | 18 +-
drivers/block/drbd/drbd_nl.c | 6 +
drivers/block/zram/zram_drv.c | 22 +-
drivers/bluetooth/ath3k.c | 2 -
drivers/bluetooth/btusb.c | 1 -
drivers/bluetooth/hci_h5.c | 1 +
drivers/char/hw_random/core.c | 47 ++-
drivers/char/hw_random/virtio-rng.c | 10 +
drivers/char/random.c | 17 +-
drivers/clk/ti/clk-7xx.c | 7 +-
drivers/cpufreq/Kconfig.arm | 3 +-
drivers/cpufreq/cpufreq-cpu0.c | 7 +-
drivers/cpufreq/cpufreq.c | 6 +-
drivers/cpufreq/sa1110-cpufreq.c | 2 +-
drivers/firewire/Kconfig | 1 +
drivers/firewire/ohci.c | 4 +-
drivers/firmware/efi/efi.c | 22 +-
drivers/firmware/efi/fdt.c | 10 -
drivers/gpio/gpio-mcp23s08.c | 6 -
drivers/gpio/gpio-rcar.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 25 +-
drivers/gpu/drm/i915/i915_gem_render_state.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 11 +-
drivers/gpu/drm/i915/intel_display.c | 4 +
drivers/gpu/drm/i915/intel_dp.c | 4 +-
drivers/gpu/drm/i915/intel_lvds.c | 7 +
drivers/gpu/drm/i915/intel_panel.c | 8 +-
drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 6 +-
drivers/gpu/drm/qxl/qxl_irq.c | 3 +
drivers/gpu/drm/radeon/atombios_crtc.c | 8 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 10 +-
drivers/gpu/drm/radeon/cik.c | 2 +
drivers/gpu/drm/radeon/evergreen.c | 6 +-
drivers/gpu/drm/radeon/evergreen_reg.h | 1 -
drivers/gpu/drm/radeon/r600.c | 1 +
drivers/gpu/drm/radeon/radeon.h | 18 +-
drivers/gpu/drm/radeon/radeon_cs.c | 20 +-
drivers/gpu/drm/radeon/radeon_device.c | 22 +-
drivers/gpu/drm/radeon/radeon_display.c | 198 ++++----
drivers/gpu/drm/radeon/radeon_drv.c | 4 +-
drivers/gpu/drm/radeon/radeon_kms.c | 26 +-
drivers/gpu/drm/radeon/radeon_vm.c | 87 +++-
drivers/gpu/drm/radeon/rv515.c | 5 +-
drivers/gpu/drm/radeon/si.c | 1 +
drivers/gpu/drm/radeon/trinity_dpm.c | 15 +-
drivers/hv/hv_fcopy.c | 2 +-
drivers/hwmon/adt7470.c | 6 +-
drivers/hwmon/da9052-hwmon.c | 2 +-
drivers/hwmon/da9055-hwmon.c | 2 +-
drivers/hwmon/smsc47m192.c | 4 +-
drivers/ide/Kconfig | 5 +-
drivers/ide/ide-probe.c | 8 +-
drivers/iio/accel/bma180.c | 8 +-
drivers/iio/accel/mma8452.c | 8 +-
drivers/iio/industrialio-buffer.c | 2 +-
drivers/iio/industrialio-event.c | 3 +
drivers/infiniband/hw/cxgb4/cm.c | 14 +-
drivers/infiniband/hw/cxgb4/device.c | 18 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 +-
drivers/infiniband/hw/mlx5/qp.c | 2 +-
drivers/input/input.c | 6 +-
drivers/input/keyboard/st-keyscan.c | 2 +
drivers/input/misc/sirfsoc-onkey.c | 2 +-
drivers/input/mouse/synaptics.c | 5 +-
drivers/input/serio/i8042-x86ia64io.h | 7 +
drivers/input/tablet/wacom_wac.c | 28 +-
drivers/input/touchscreen/ti_am335x_tsc.c | 5 +-
drivers/iommu/fsl_pamu.c | 8 +-
drivers/iommu/fsl_pamu_domain.c | 18 +-
drivers/irqchip/irq-gic.c | 7 +-
drivers/isdn/gigaset/bas-gigaset.c | 1 +
drivers/isdn/hisax/l3ni1.c | 14 +-
drivers/isdn/i4l/isdn_ppp.c | 28 +-
drivers/md/dm-bufio.c | 2 +-
drivers/md/dm-cache-metadata.c | 9 +
drivers/md/dm-cache-target.c | 13 +-
drivers/md/dm-thin-metadata.c | 9 +
drivers/media/dvb-frontends/si2168.c | 16 +-
drivers/media/dvb-frontends/si2168_priv.h | 2 +-
drivers/media/dvb-frontends/tda10071.c | 12 +-
drivers/media/dvb-frontends/tda10071_priv.h | 1 +
drivers/media/pci/saa7134/saa7134-empress.c | 2 +-
drivers/media/platform/davinci/vpif_capture.c | 1 +
drivers/media/platform/davinci/vpif_display.c | 1 +
drivers/media/tuners/si2157.c | 2 +-
drivers/media/usb/dvb-usb-v2/af9035.c | 40 ++-
drivers/media/usb/gspca/pac7302.c | 1 +
drivers/media/usb/hdpvr/hdpvr-video.c | 6 +-
drivers/media/v4l2-core/v4l2-dv-timings.c | 4 +-
drivers/mtd/chips/cfi_cmdset_0001.c | 43 ++
drivers/mtd/devices/elm.c | 2 +
drivers/mtd/nand/nand_base.c | 6 +-
drivers/mtd/ubi/fastmap.c | 4 +-
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/can/c_can/c_can_platform.c | 3 +-
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 3 +-
drivers/net/ethernet/broadcom/bcmsysport.c | 43 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 12 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 21 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 4 +-
drivers/net/ethernet/intel/igb/e1000_82575.c | 7 +
drivers/net/ethernet/intel/igb/e1000_defines.h | 18 +-
drivers/net/ethernet/intel/igb/e1000_hw.h | 3 +
drivers/net/ethernet/intel/igb/e1000_i210.c | 66 +++
drivers/net/ethernet/intel/igb/e1000_i210.h | 12 +
drivers/net/ethernet/intel/igb/e1000_regs.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 16 +
drivers/net/ethernet/marvell/mvneta.c | 4 +-
drivers/net/ethernet/mellanox/mlx4/cq.c | 2 -
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 8 +-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 7 +
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 3 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 17 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 34 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 69 +---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 4 +
drivers/net/ethernet/mellanox/mlx5/core/mr.c | 19 +-
drivers/net/ethernet/realtek/r8169.c | 27 +
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 5 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/sun/sunvnet.c | 42 ++-
drivers/net/fddi/defxx.c | 17 +-
drivers/net/hyperv/netvsc.c | 4 +-
drivers/net/phy/dp83640.c | 6 +-
drivers/net/phy/mdio_bus.c | 45 ++
drivers/net/phy/phy_device.c | 15 +-
drivers/net/ppp/ppp_generic.c | 30 +-
drivers/net/ppp/pppoe.c | 2 +-
drivers/net/usb/cdc_ether.c | 16 +
drivers/net/usb/hso.c | 50 +--
drivers/net/usb/huawei_cdc_ncm.c | 3 +
drivers/net/usb/qmi_wwan.c | 3 +
drivers/net/usb/r8152.c | 14 +-
drivers/net/usb/smsc95xx.c | 14 +-
drivers/net/vxlan.c | 2 +-
drivers/net/wan/farsync.c | 112 ++--
drivers/net/wan/x25_asy.c | 6 +-
drivers/net/wireless/ath/ath10k/core.c | 6 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 18 -
drivers/net/wireless/ath/ath9k/xmit.c | 9 +
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 5 +-
drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 -
drivers/net/wireless/iwlwifi/iwl-fw.h | 1 +
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 20 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +-
drivers/net/wireless/iwlwifi/mvm/scan.c | 65 +--
drivers/net/wireless/iwlwifi/pcie/drv.c | 3 +-
drivers/net/wireless/mwifiex/11n_aggr.c | 1 +
drivers/net/wireless/mwifiex/cfg80211.c | 1 +
drivers/net/wireless/mwifiex/cmdevt.c | 1 +
drivers/net/wireless/mwifiex/main.c | 1 +
drivers/net/wireless/mwifiex/sta_tx.c | 1 +
drivers/net/wireless/mwifiex/tdls.c | 2 +
drivers/net/wireless/mwifiex/txrx.c | 1 +
drivers/net/wireless/mwifiex/uap_txrx.c | 1 +
drivers/net/wireless/rt2x00/rt2800usb.c | 28 +-
drivers/net/xen-netback/netback.c | 86 +++-
drivers/net/xen-netfront.c | 27 +-
drivers/of/fdt.c | 66 +++-
drivers/of/of_mdio.c | 34 --
drivers/parport/Kconfig | 12 +-
drivers/pinctrl/pinctrl-st.c | 2 +-
drivers/pnp/pnpacpi/core.c | 3 +-
drivers/rapidio/devices/tsi721_dma.c | 8 +-
drivers/s390/char/raw3270.c | 1 -
drivers/s390/crypto/ap_bus.c | 9 +-
drivers/scsi/scsi_lib.c | 8 +
drivers/staging/media/omap4iss/Kconfig | 2 +-
drivers/staging/rtl8723au/os_dep/usb_intf.c | 4 +-
drivers/staging/vt6655/bssdb.c | 2 +-
drivers/staging/vt6655/device_main.c | 7 +-
drivers/usb/chipidea/udc.c | 4 +-
drivers/usb/core/hub.c | 19 +
drivers/xen/balloon.c | 12 +-
drivers/xen/grant-table.c | 9 +-
drivers/xen/manage.c | 5 +-
fs/afs/main.c | 4 +-
fs/aio.c | 7 +
fs/btrfs/ordered-data.c | 11 +
fs/btrfs/volumes.c | 8 +-
fs/cifs/cifs_spnego.c | 1 -
fs/cifs/cifsacl.c | 1 -
fs/coredump.c | 2 +-
fs/direct-io.c | 23 +-
fs/fuse/dev.c | 51 +-
fs/fuse/dir.c | 41 +-
fs/fuse/file.c | 8 +-
fs/fuse/inode.c | 27 +-
fs/gfs2/file.c | 4 +-
fs/gfs2/glock.c | 14 +-
fs/gfs2/glops.c | 4 +-
fs/gfs2/lock_dlm.c | 4 +-
fs/gfs2/rgrp.c | 4 +-
fs/namei.c | 5 +-
fs/nfs/direct.c | 2 -
fs/nfs/idmap.c | 2 -
fs/nfs/internal.h | 1 +
fs/nfs/nfs3acl.c | 43 ++
fs/nfs/nfs3proc.c | 4 +-
fs/nfs/pagelist.c | 20 +-
fs/nfs/write.c | 335 ++++++++++--
fs/nfsd/nfs4xdr.c | 4 +-
fs/nfsd/vfs.c | 2 +-
fs/open.c | 5 +-
fs/quota/dquot.c | 2 +
fs/xattr.c | 2 +-
fs/xfs/xfs_bmap.c | 7 +-
fs/xfs/xfs_bmap.h | 4 +-
fs/xfs/xfs_bmap_util.c | 53 --
fs/xfs/xfs_bmap_util.h | 4 -
fs/xfs/xfs_btree.c | 82 +++-
fs/xfs/xfs_iomap.c | 3 +-
fs/xfs/xfs_sb.c | 25 +-
include/crypto/public_key.h | 6 +-
include/dt-bindings/pinctrl/dra.h | 7 +-
include/keys/asymmetric-type.h | 41 ++
include/keys/user-type.h | 1 -
include/linux/cpufreq.h | 4 +-
include/linux/hugetlb.h | 1 +
include/linux/ima.h | 4 +-
include/linux/kernel.h | 1 +
include/linux/key-type.h | 34 +-
include/linux/libata.h | 1 +
include/linux/mlx4/device.h | 4 +-
include/linux/mutex.h | 4 +-
include/linux/of_fdt.h | 3 +
include/linux/of_mdio.h | 8 -
include/linux/osq_lock.h | 27 +
include/linux/pagemap.h | 12 +
include/linux/rcupdate.h | 46 +--
include/linux/rwsem-spinlock.h | 8 +-
include/linux/rwsem.h | 34 +-
include/linux/sched.h | 8 +-
include/linux/security.h | 2 +-
include/net/ip.h | 11 +-
include/net/neighbour.h | 1 -
include/net/netfilter/nf_tables.h | 6 +-
include/net/netns/ieee802154_6lowpan.h | 2 +-
include/net/netns/nftables.h | 2 +-
include/net/sock.h | 12 +-
include/uapi/linux/fuse.h | 3 +
include/xen/grant_table.h | 1 +
kernel/Kconfig.locks | 9 +-
kernel/events/core.c | 34 ++-
kernel/kexec.c | 4 +
kernel/kprobes.c | 14 +-
kernel/locking/mcs_spinlock.c | 64 ++-
kernel/locking/mcs_spinlock.h | 9 +-
kernel/locking/mutex.c | 2 +-
kernel/locking/rwsem-spinlock.c | 28 +-
kernel/locking/rwsem-xadd.c | 16 +-
kernel/locking/rwsem.c | 2 +-
kernel/power/process.c | 1 +
kernel/power/suspend.c | 4 +-
kernel/rcu/rcutorture.c | 4 +-
kernel/rcu/tree.c | 140 ++++-
kernel/rcu/tree.h | 6 +-
kernel/rcu/tree_plugin.h | 2 +-
kernel/rcu/update.c | 22 +-
kernel/sched/core.c | 7 +-
kernel/sched/debug.c | 2 +-
kernel/time/alarmtimer.c | 20 +-
kernel/time/clockevents.c | 10 +-
kernel/time/sched_clock.c | 4 +-
kernel/trace/ftrace.c | 4 +-
kernel/trace/ring_buffer.c | 4 -
kernel/trace/trace.c | 20 +-
kernel/trace/trace_clock.c | 9 +-
kernel/trace/trace_events.c | 1 +
lib/cpumask.c | 2 +-
lib/hexdump.c | 16 +
mm/filemap.c | 13 +-
mm/hugetlb.c | 3 +-
mm/memcontrol.c | 4 +
mm/memory-failure.c | 18 +-
mm/memory.c | 24 +-
mm/migrate.c | 5 +-
mm/page-writeback.c | 6 +-
mm/page_alloc.c | 31 +-
mm/rmap.c | 10 +-
mm/shmem.c | 102 +++--
mm/slab_common.c | 2 +-
mm/truncate.c | 11 +-
net/8021q/vlan_dev.c | 13 +-
net/appletalk/ddp.c | 3 -
net/batman-adv/bridge_loop_avoidance.c | 44 ++-
net/batman-adv/soft-interface.c | 60 ++-
net/batman-adv/translation-table.c | 26 +
net/batman-adv/types.h | 2 +
net/bluetooth/hci_conn.c | 12 +-
net/bluetooth/smp.c | 60 ++-
net/ceph/crypto.c | 1 -
net/compat.c | 9 +-
net/core/dev.c | 32 +-
net/core/iovec.c | 6 +-
net/core/neighbour.c | 11 +-
net/dns_resolver/dns_key.c | 18 +-
net/dns_resolver/dns_query.c | 2 +-
net/ipv4/af_inet.c | 3 +
net/ipv4/gre_demux.c | 1 +
net/ipv4/gre_offload.c | 3 +
net/ipv4/icmp.c | 2 -
net/ipv4/igmp.c | 10 +-
net/ipv4/ip_options.c | 4 +
net/ipv4/ip_tunnel.c | 12 +-
net/ipv4/route.c | 47 ++-
net/ipv4/tcp.c | 3 +-
net/ipv4/tcp_input.c | 8 +-
net/ipv4/tcp_offload.c | 2 +-
net/ipv4/tcp_output.c | 6 +-
net/ipv4/udp.c | 5 +-
net/ipv6/ip6_output.c | 2 +
net/ipv6/mcast.c | 13 +-
net/ipv6/tcpv6_offload.c | 2 +-
net/ipv6/udp.c | 6 +-
net/l2tp/l2tp_ppp.c | 4 +-
net/mac80211/cfg.c | 5 +-
net/mac80211/tx.c | 20 +-
net/mac80211/util.c | 5 +-
net/netfilter/ipvs/ip_vs_conn.c | 1 -
net/netfilter/nf_tables_api.c | 140 ++++--
net/netfilter/nf_tables_core.c | 10 +-
net/netlink/af_netlink.c | 4 +-
net/openvswitch/actions.c | 2 +
net/openvswitch/datapath.c | 27 +-
net/openvswitch/flow.c | 4 +-
net/openvswitch/flow.h | 5 +-
net/openvswitch/flow_table.c | 16 +
net/openvswitch/flow_table.h | 3 +-
net/openvswitch/vport-gre.c | 17 +
net/rxrpc/ar-key.c | 2 -
net/sched/cls_u32.c | 19 +-
net/sctp/associola.c | 1 +
net/sctp/ulpevent.c | 122 +----
net/tipc/bcast.c | 1 +
net/tipc/msg.c | 11 +-
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 11 +-
net/wireless/reg.c | 22 +-
net/wireless/trace.h | 3 +-
net/xfrm/xfrm_policy.c | 2 +
net/xfrm/xfrm_user.c | 7 +-
security/integrity/Kconfig | 46 ++-
security/integrity/Makefile | 6 +-
security/integrity/digsig_asymmetric.c | 7 +-
security/integrity/evm/Kconfig | 8 -
security/integrity/evm/evm_main.c | 17 +-
security/integrity/ima/Kconfig | 2 -
security/integrity/ima/ima.h | 24 +-
security/integrity/ima/ima_api.c | 10 +-
security/integrity/ima/ima_appraise.c | 17 +-
security/integrity/ima/ima_crypto.c | 20 +-
security/integrity/ima/ima_init.c | 25 +-
security/integrity/ima/ima_main.c | 123 +++--
security/integrity/ima/ima_policy.c | 23 +
security/integrity/ima/ima_template.c | 30 +-
security/integrity/integrity.h | 2 +-
security/keys/big_key.c | 2 -
security/keys/encrypted-keys/encrypted.c | 1 -
security/keys/internal.h | 21 +-
security/keys/key.c | 2 +-
security/keys/keyctl.c | 2 +
security/keys/keyring.c | 58 ++-
security/keys/proc.c | 8 +-
security/keys/process_keys.c | 13 +-
security/keys/request_key.c | 21 +-
security/keys/request_key_auth.c | 10 +-
security/keys/trusted.c | 1 -
security/keys/user_defined.c | 14 -
security/selinux/hooks.c | 135 +++--
security/selinux/include/netif.h | 4 +-
security/selinux/include/objsec.h | 2 +
security/selinux/netif.c | 43 +-
security/selinux/ss/services.c | 14 +-
security/smack/Kconfig | 16 +
security/smack/smack.h | 39 +-
security/smack/smack_access.c | 118 ++---
security/smack/smack_lsm.c | 545 ++++++++++++++------
security/smack/smackfs.c | 76 ++--
sound/firewire/bebob/bebob_maudio.c | 53 ++-
sound/pci/hda/hda_controller.c | 3 +-
sound/pci/hda/hda_intel.c | 12 +-
sound/pci/hda/hda_priv.h | 1 +
sound/pci/hda/hda_tegra.c | 2 +-
sound/pci/hda/patch_hdmi.c | 2 +
tools/lib/lockdep/include/liblockdep/mutex.h | 4 +-
tools/lib/lockdep/include/liblockdep/rwlock.h | 8 +-
tools/lib/lockdep/preload.c | 20 +-
tools/perf/ui/browsers/hists.c | 21 +-
tools/perf/util/machine.c | 54 +--
virt/kvm/arm/vgic.c | 24 +-
531 files changed, 5773 insertions(+), 3166 deletions(-)
create mode 100644 include/linux/osq_lock.h
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-10 8:23 [GIT] Security subsystem upate for 3.18 James Morris
@ 2014-10-12 14:12 ` Linus Torvalds
2014-10-12 14:32 ` Linus Torvalds
2014-10-12 15:04 ` Paul Moore
0 siblings, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2014-10-12 14:12 UTC (permalink / raw)
To: James Morris, Paul Moore
Cc: LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Fri, Oct 10, 2014 at 4:23 AM, James Morris <jmorris@namei.org> wrote:
>
> One of these is from merging with your v3.16, and the other from a merge
> of the keys tree. That's about all I understand of it.
Please don't do back-merges. What was the reason for that v3.16 merge?
It only caused problems, and the merge message is this worthless
oneliner:
"Merge commit 'v3.16' into next"
that's it. No reason why, and there doesn't seem to be any merge
conflicts fixed up either, so why was that merge done? The commit
message sure as hell doesn't explain it.
There's another one, by Paul Moore:
"Merge tag 'v3.16' into next
Linux 3.16"
and please tell me what that (now two-line) merge message adds to the
world, and why those merges were done at all?
People, stop doing these back-merges. You are doing them wrong, and
they cause problems. Just stop it. And if you have some seriously good
reason for why you are doing them, you should damn well *document*
that reason, rather than say "Merge v3.16" and leave it at that. If
you *don't* have a good reason for doing them, don't do them!
Also, James, *please* give a short description of what I'm merging,
and include both "git" and "pull" in the pull request. As it is, I see
the shortlog and the (completely incorrect, due to the back-merge)
diffstat, but I don't see *why* I should merge it at all. Give me a
synopsis of what has changed and why I should pull.
And finally - I didn't even find the pull request at all with my
normal "look for git pull requests" search that - not completely
randomly - looks for "in:inbox git pull". If I don't find a pull
request with that, it easily gets overlooked. So change your scripts
to add "Please pull" into the body of the message, or make the subject
line be "[GIT PULL]" or something.
These are all things I've ranted about many times before. Please.
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 14:12 ` Linus Torvalds
@ 2014-10-12 14:32 ` Linus Torvalds
2014-10-12 15:04 ` Paul Moore
1 sibling, 0 replies; 10+ messages in thread
From: Linus Torvalds @ 2014-10-12 14:32 UTC (permalink / raw)
To: James Morris, Paul Moore
Cc: LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Sun, Oct 12, 2014 at 10:12 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Give me a synopsis of what has changed and why I should pull.
Side note: this is not just for me personally (so that I have a better
overview of what is going on during the merge window), but also so
that I can make sure that my merge messages are informative and tell
people what I merged and why.
In a perfect world, people could just read my merge messages and get a
good overview of everything that has changed. But that depends on
maintainers giving me those nice summaries of what the big important
changes have been for that merge. I can, and occasionally do, try to
write something up myself, but quite frankly, subsystem maintainers
are just *so* much better positioned to give a good summary of what
has been going on, that I really want that.
Of course, sometimes the summary might just be "a few trivial fixes"
and then people who really want the details can just look at the
individual commits. At other times, maybe you'd want to go into more
detail about some subtle change. There's no fixed format, but it's
supposed to be a human-readable quick high-level overview of what the
merge brings in.
You can just do "git log --author=Torvalds --merges" to see examples
of what people send me. Some people explain more, some explain less, I
really don't have any hard requirements. But I do want to get *some*
overview.
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 14:12 ` Linus Torvalds
2014-10-12 14:32 ` Linus Torvalds
@ 2014-10-12 15:04 ` Paul Moore
2014-10-12 15:50 ` Linus Torvalds
1 sibling, 1 reply; 10+ messages in thread
From: Paul Moore @ 2014-10-12 15:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Morris, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Sunday, October 12, 2014 10:12:28 AM Linus Torvalds wrote:
> On Fri, Oct 10, 2014 at 4:23 AM, James Morris <jmorris@namei.org> wrote:
> > One of these is from merging with your v3.16, and the other from a merge
> > of the keys tree. That's about all I understand of it.
>
> Please don't do back-merges. What was the reason for that v3.16 merge?
> It only caused problems, and the merge message is this worthless
> oneliner:
>
> "Merge commit 'v3.16' into next"
>
> that's it. No reason why, and there doesn't seem to be any merge
> conflicts fixed up either, so why was that merge done? The commit
> message sure as hell doesn't explain it.
>
> There's another one, by Paul Moore:
>
> "Merge tag 'v3.16' into next
>
> Linux 3.16"
>
> and please tell me what that (now two-line) merge message adds to the
> world ...
Nothing other than that a merge was done. To be honest I wasn't sure any
additional comment was needed since it was a clean merge without any conflict;
my process has only been to add commentary when there were conflicts that
needed to be resolved by hand.
As far as the one vs two line commit message goes, the two line message was
just the default message generated by git when I did the 'git merge v3.16'
command. I didn't realize two lines were worse than one.
> ... and why those merges were done at all?
When I took over the care and feeding of the SELinux tree I talked with Eric,
the previous maintainer, read some of your mail on the subject, and came to
the conclusion that the proper tree process should be something like the
following:
1. Start with the latest stable release, e.g. v3.15
2. Apply patches as necessary
3. Send pull request upstream
4. Merge latest stable release with 'git merge v3.16'
5. Jump to step #2
Once again, I honestly thought this was the "Right Way". The result was a
current, reasonably stable tree, that was easy to patch and merged easily
upstream.
However, despite my best intentions, it sounds like I'm doing it wrong. Okay,
I'll accept that, I can change my process to whatever you want; just help me
out a little bit and explain, like I'm a distracted four year old if
necessary, what process you would like me to use. I appreciate that you
probably feel like you've repeated yourself a thousand times on this topic, so
if a pointer to a previous thread works, that's fine too.
Is the core issue that I'm merging each release into the SELinux tree? Do you
only want to see merges in the tree when there is a merge conflict or some
logic change that would require a merge?
> People, stop doing these back-merges. You are doing them wrong, and
> they cause problems. Just stop it. And if you have some seriously good
> reason for why you are doing them, you should damn well *document*
> that reason, rather than say "Merge v3.16" and leave it at that. If
> you *don't* have a good reason for doing them, don't do them!
--
paul moore
security and virtualization @ redhat
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 15:04 ` Paul Moore
@ 2014-10-12 15:50 ` Linus Torvalds
2014-10-12 16:01 ` Linus Torvalds
2014-10-12 21:19 ` Paul Moore
0 siblings, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2014-10-12 15:50 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Sun, Oct 12, 2014 at 11:04 AM, Paul Moore <pmoore@redhat.com> wrote:
>
> Nothing other than that a merge was done. To be honest I wasn't sure any
> additional comment was needed since it was a clean merge without any conflict;
> my process has only been to add commentary when there were conflicts that
> needed to be resolved by hand.
So in general, any merge should always have a reason for the merge, or
a summary of what the merge does.
Now, some reasons are pretty much "implicit" in the merge - when a
maintainer merges a downstream maintainer tree, the "reason" for the
merge is pretty obvious - the maintainer is obviously merging code.
Then, the merge doesn't need an explicit reason, but a summary of the
code being merged, so that the history shows at a glance what is going
on.
Now, "back-merges" - ie a submaintainer merging a tree from a
top-level maintainer - causes various problems. The most obvious is
that there is now no longer a single starting point for the
development branch - there's both the original point you started
developing, and there's the newly merged point. And because there is
no clear-cut starting point, you can't get a sane "diff" of the
developer tree.
(Well, you can, but it involves more than diffing two points - you
basically have to do another merge, and then looking at the result of
*that* merge, because "git merge" understands multiple base trees and
does some clever recursive merging to make it all DTRT automatically).
The end result of that is that the basic assumption should always be
that merges only go one way: a maintainer merges the submaintainer
tree. Anything else causes problems.
Now, that said, there *are* valid reasons for a submaintainer doing a
back merge and merging upstream. But they should be seen as being
exceptional events, and they really should be explained in the merge
commit message. If you don't have a good explanation for it, you
shouldn't do it. It's really that simple.
Examples of *good* reasons to do a back-merge:
- the code was developed on a really ancient tree, and is *so*
out-of-date that not only are there conflicts, they are complicated
and might be more than simple data conflicts - semantic changes etc
that you as a submaintainer might be better off handlng the merge of,
since you presumably know the code you are merging intimately.
Note: you may know your code intimately, but maybe you don't know
the other changes intimately, and maybe the top-level maintainer is
actually better at merging (possibly because that maintainer does 10+
merges a day at times). So "a few conflicts" is not necessarily a good
reason in itself, but there are certainly cases where things just get
so ugly that "break the rules" is a very valid approach.
- you actively need infrastructure from newer versions, so you need
to merge an upstream kernel for further development.
Even this is often questionable, but it's one of the best reasons
to do back-merges. However, if so, that back-merge should very much
spell out the exact reason why the merge was needed (not just "needed
upstream features" in general, but what particular features were
needed etc).
- and hey, as with so many (all) kernel development rules, I don't
actually want people to think that the rules are completely hard.
Mistakes happen, shit happens, things go wrong, whatever.
So the reason I spoke out was that there were not only two unnecessary
merges in there, they actually did cause problems. Not *huge*
problems, but the diffstat that James had doesn't match what I get
after the merge, and it's annoying when I cannot do the full
verification of "I got what the maintainer clearly meant to send" by
comparing diffstats etc.
And as mentioned, the fact that a plain "git diff" doesn't work can be
worked around - some submaintainers do a full test-merge,. generate
the diff from that (and tell me about any conflicts they encountered)
and then just ask me to pull (and do the merge again). And I certainly
don't mind it at all when submaintainers do that, but with clean
workflows that simply isn't even *needed*.
So it's not a disaster, and pulled and pushed out already, and
occasional back-merges are fine. But I definitely would want to
minimize them, and just on principle, I think all merges should have
descriptive commit messages, the same way regular code changes should
have them (in fact, it can arguably be *more* important for a merge
commit, because if bisection ends up pointing to a merge, you don't
have the same kind of obvious "this is the code that changed" that you
have for a regular commit - so I think having good merge explanations
just makes life less frustrating when things go wrong).
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 15:50 ` Linus Torvalds
@ 2014-10-12 16:01 ` Linus Torvalds
2014-10-13 4:06 ` James Morris
2014-10-12 21:19 ` Paul Moore
1 sibling, 1 reply; 10+ messages in thread
From: Linus Torvalds @ 2014-10-12 16:01 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, LSM List, Linux Kernel Mailing List, Stephen Rothwell
One more comment on this..
On Sun, Oct 12, 2014 at 11:50 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> - you actively need infrastructure from newer versions, so you need
> to merge an upstream kernel for further development.
>
> Even this is often questionable, but it's one of the best reasons
> to do back-merges. However, if so, that back-merge should very much
> spell out the exact reason why the merge was needed (not just "needed
> upstream features" in general, but what particular features were
> needed etc).
Btw, rather than merge from upstream, a better way is often to simply
start a new development branch. If you need a particular new feature,
you're *likely* to start doing new development rather than continuing
on some previous development, so it's often a good time to simply
create a new feature branch. I don't know how James feels about
merging multiple separate feature branches, but I know that *I* tend
to appreciate it when I get multiple well-defined pull requests rather
than one big one that does many different things.
And even if you then want to send just one pull-request, what you can
do if you have (say) three different feature branches is to create a
combined branch to be sent upstream, by just starting from one of the
feature branches and then merging the two other ones into that
combined one. Some submaintainers do this quite a lot, and use
"octopus merges" to combine their different feature branches into one
final "please pull" branch. See for example Mark Brown's ASoC merge
for upstreaming (to Takashi Iwai, and then to me): commit bdf20b4291e.
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 15:50 ` Linus Torvalds
2014-10-12 16:01 ` Linus Torvalds
@ 2014-10-12 21:19 ` Paul Moore
1 sibling, 0 replies; 10+ messages in thread
From: Paul Moore @ 2014-10-12 21:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Morris, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Sunday, October 12, 2014 11:50:41 AM Linus Torvalds wrote:
>
> Examples of *good* reasons to do a back-merge:
>
> - the code was developed on a really ancient tree, and is *so*
> out-of-date that not only are there conflicts, they are complicated
> and might be more than simple data conflicts - semantic changes etc
> that you as a submaintainer might be better off handlng the merge of,
> since you presumably know the code you are merging intimately.
>
> Note: you may know your code intimately, but maybe you don't know
> the other changes intimately, and maybe the top-level maintainer is
> actually better at merging (possibly because that maintainer does 10+
> merges a day at times). So "a few conflicts" is not necessarily a good
> reason in itself, but there are certainly cases where things just get
> so ugly that "break the rules" is a very valid approach.
>
> - you actively need infrastructure from newer versions, so you need
> to merge an upstream kernel for further development.
>
> Even this is often questionable, but it's one of the best reasons
> to do back-merges. However, if so, that back-merge should very much
> spell out the exact reason why the merge was needed (not just "needed
> upstream features" in general, but what particular features were
> needed etc).
>
> - and hey, as with so many (all) kernel development rules, I don't
> actually want people to think that the rules are completely hard.
> Mistakes happen, shit happens, things go wrong, whatever.
Okay, understood. I suppose I was hoping to see something a little less
subjective (?), if for no other reason than to avoid the "what the hell?!"
moments. However, like you said, development is messy, and it's probably
naive to try and force too rigid a process.
I'll stop back merging each new release without a valid reason. I suspect
there will be disagreements at points in the future about if the merge was
truly warranted, but at least that is a step in the right direction.
Regardless, sorry for the problems this time around, hopefully things will be
smoother in the future.
On Sunday, October 12, 2014 12:01:25 PM Linus Torvalds wrote:
> One more comment on this..
>
> On Sun, Oct 12, 2014 at 11:50 AM, Linus Torvalds
>
> <torvalds@linux-foundation.org> wrote:
> > - you actively need infrastructure from newer versions, so you need
> > to merge an upstream kernel for further development.
> >
> > Even this is often questionable, but it's one of the best reasons
> > to do back-merges. However, if so, that back-merge should very much
> > spell out the exact reason why the merge was needed (not just "needed
> > upstream features" in general, but what particular features were
> > needed etc).
>
> Btw, rather than merge from upstream, a better way is often to simply
> start a new development branch. If you need a particular new feature,
> you're *likely* to start doing new development rather than continuing
> on some previous development, so it's often a good time to simply
> create a new feature branch.
Aside from my own patches/work, I've tried to keep a single, continuous
development branch (next) that can be used by others for SELinux development,
in the linux-next tree, and by James via pull requests. Unless this becomes
to difficult to manage without regular back-merges (and I don't think this
would be the case), I'd just assume keep this approach.
-Paul
--
paul moore
security and virtualization @ redhat
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-12 16:01 ` Linus Torvalds
@ 2014-10-13 4:06 ` James Morris
2014-10-13 13:07 ` Paul Moore
0 siblings, 1 reply; 10+ messages in thread
From: James Morris @ 2014-10-13 4:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Moore, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Sun, 12 Oct 2014, Linus Torvalds wrote:
> on some previous development, so it's often a good time to simply
> create a new feature branch. I don't know how James feels about
> merging multiple separate feature branches, but I know that *I* tend
> to appreciate it when I get multiple well-defined pull requests rather
> than one big one that does many different things.
It's fine with me.
This is the first time I saw (or noticed) that Paul had back merged ahead
of me, but it seemed to merge into my tree ok so I didn't query it at the
time.
Paul: it's likey best if you consider my -next branch as your upstream.
I'll sync to Linus on point releases as previously discussed.
Linus: sorry about all of this, and I'll ensure there's always a summary
of the changes and a correct subject for you.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-13 4:06 ` James Morris
@ 2014-10-13 13:07 ` Paul Moore
2014-10-14 11:01 ` James Morris
0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2014-10-13 13:07 UTC (permalink / raw)
To: James Morris
Cc: Linus Torvalds, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Monday, October 13, 2014 03:06:34 PM James Morris wrote:
> On Sun, 12 Oct 2014, Linus Torvalds wrote:
> > on some previous development, so it's often a good time to simply
> > create a new feature branch. I don't know how James feels about
> > merging multiple separate feature branches, but I know that *I* tend
> > to appreciate it when I get multiple well-defined pull requests rather
> > than one big one that does many different things.
>
> It's fine with me.
>
> This is the first time I saw (or noticed) that Paul had back merged ahead
> of me, but it seemed to merge into my tree ok so I didn't query it at the
> time.
The management of the linux-security tree, the approach I was taking with the
SELinux tree, and the approach that the other LSM maintainers use has been
discussed many times on the LSM list. I'm also fairly certain that you were
on the To/CC line for many, if not all, of those threads.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [GIT] Security subsystem upate for 3.18
2014-10-13 13:07 ` Paul Moore
@ 2014-10-14 11:01 ` James Morris
0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2014-10-14 11:01 UTC (permalink / raw)
To: Paul Moore
Cc: Linus Torvalds, LSM List, Linux Kernel Mailing List, Stephen Rothwell
On Mon, 13 Oct 2014, Paul Moore wrote:
> On Monday, October 13, 2014 03:06:34 PM James Morris wrote:
> > On Sun, 12 Oct 2014, Linus Torvalds wrote:
> > > on some previous development, so it's often a good time to simply
> > > create a new feature branch. I don't know how James feels about
> > > merging multiple separate feature branches, but I know that *I* tend
> > > to appreciate it when I get multiple well-defined pull requests rather
> > > than one big one that does many different things.
> >
> > It's fine with me.
> >
> > This is the first time I saw (or noticed) that Paul had back merged ahead
> > of me, but it seemed to merge into my tree ok so I didn't query it at the
> > time.
>
> The management of the linux-security tree, the approach I was taking with the
> SELinux tree, and the approach that the other LSM maintainers use has been
> discussed many times on the LSM list. I'm also fairly certain that you were
> on the To/CC line for many, if not all, of those threads.
>
My expectation is that people develop against my next branch, per the
documentation here:
http://kernsec.org/wiki/index.php/Kernel_Repository
What we agreed to recently is that I'll sync to Linus' releases, as
several devlopers need/want to work with more recent kernels. I had been
only syncing to Linus as necessary (e.g. to get in sync with say the
mainline modules code for key subsystem updates).
It's possible I missed something in the threads and we have a
misunderstanding about this process.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-10-14 11:02 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-10 8:23 [GIT] Security subsystem upate for 3.18 James Morris
2014-10-12 14:12 ` Linus Torvalds
2014-10-12 14:32 ` Linus Torvalds
2014-10-12 15:04 ` Paul Moore
2014-10-12 15:50 ` Linus Torvalds
2014-10-12 16:01 ` Linus Torvalds
2014-10-13 4:06 ` James Morris
2014-10-13 13:07 ` Paul Moore
2014-10-14 11:01 ` James Morris
2014-10-12 21:19 ` Paul Moore
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.