* linux-next: Tree for Jun 3
From: Stephen Rothwell @ 2016-06-03 4:04 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Hi all,
Changes since 20160602:
My fixes tree contains:
of: silence warnings due to max() usage
The pstore tree lost its build failures.
The pm tree lost its build failure.
Non-merge commits (relative to Linus' tree): 1330
1135 files changed, 43583 insertions(+), 20406 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.
Below is a summary of the state of the merge.
I am currently merging 237 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (4340fa55298d Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (b31033aacbd0 of: silence warnings due to max() usage)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install)
Merging arc-current/for-curr (49acadff2a0c arc: Get rid of root core-frequency property)
Merging arm-current/fixes (e2dfb4b88014 ARM: fix PTRACE_SETVFPREGS on SMP systems)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic <linux/rtc.h>)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors)
Merging powerpc-fixes/fixes (7cc851039d64 powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (6b15d6650c53 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (ce25d66ad5f8 Possible problem with e6afc8ac ("udp: remove headers from UDP packets before queueing"))
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (de26859dcf36 rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01)
Merging mac80211/master (6fe04128f158 mac80211: fix fast_tx header alignment)
Merging sound-current/for-linus (0358ccc8ffd8 ALSA: uapi: Add three missing header files to Kbuild file)
Merging pci-current/for-linus (1a695a905c18 Linux 4.7-rc1)
Merging driver-core.current/driver-core-linus (1a695a905c18 Linux 4.7-rc1)
Merging tty.current/tty-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb.current/usb-linus (7b2c17f82954 usb: musb: Stop bulk endpoint while queue is rotated)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1a695a905c18 Linux 4.7-rc1)
Merging char-misc.current/char-misc-linus (1a695a905c18 Linux 4.7-rc1)
Merging input-current/for-linus (540c26087bfb Input: xpad - fix rumble on Xbox One controllers with 2015 firmware)
Merging crypto-current/master (ab6a11a7c8ef crypto: ccp - Fix AES XTS error for request sizes above 4096)
Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.)
Merging vfio-fixes/for-linus (ce7585f3c4d7 vfio/pci: Allow VPD short read)
Merging kselftest-fixes/fixes (1a77e2bd8c89 kselftests: timers: Add set-tz test case)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM)
Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (1b52e50f2a40 mfd: max77843: Fix max77843_chg_init() return on error)
Merging drm-intel-fixes/for-linux-next-fixes (1a695a905c18 Linux 4.7-rc1)
Merging asm-generic/master (b0da6d44157a asm-generic: Drop renameat syscall from default list)
Merging arc/for-next (776d7f1694a7 arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core)
Merging arm/for-next (6d525d418a22 Merge branches 'component' and 'fixes' into for-next)
Merging arm-perf/for-next/perf (4ba2578fa7b5 arm64: perf: don't expose CHAIN event in sysfs)
Merging arm-soc/for-next (d6be64b09dd1 Merge branch 'fixes' into for-next)
Merging at91/at91-next (5a0d7c6a48ae Merge branch 'at91-4.7-defconfig' into at91-next)
Merging bcm2835-dt/bcm2835-dt-next (6a93792774fc ARM: bcm2835: dt: Add the ethernet to the device trees)
Merging bcm2835-soc/bcm2835-soc-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-drivers/bcm2835-drivers-next (92e963f50fc7 Linux 4.5-rc1)
Merging bcm2835-defconfig/bcm2835-defconfig-next (1a695a905c18 Linux 4.7-rc1)
Merging berlin/berlin/for-next (9a7e06833249 Merge branch 'berlin/fixes' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (63b44471754b Merge branch 'imx/defconfig64' into for-next)
Merging keystone/next (02e15d234006 Merge branch 'for_4.7/kesytone' into next)
Merging mvebu/for-next (01316cded75b Merge branch 'mvebu/defconfig' into mvebu/for-next)
Merging omap/for-next (5c66191b5c76 Merge branch 'omap-for-v4.7/dt' into for-next)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (eb8e0105700b firmware: qcom_scm: Make core clock optional)
Merging renesas/next (1df83bd17bee Merge branches 'heads/arm64-dt-for-v4.8', 'heads/dt-for-v4.8', 'heads/soc-for-v4.8' and 'heads/sh-drivers-for-v4.8' into next)
Merging rockchip/for-next (bc64bf4164ed Merge branch 'v4.7-clk/fixes' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (92e963f50fc7 Linux 4.5-rc1)
Merging samsung-krzk/for-next (c13fb09cafe0 Merge branch 'next/dt' into for-next)
Merging tegra/for-next (5c282bc9d0a3 Merge branch for-4.7/defconfig into for-next)
Merging arm64/for-next/core (e6d9a5254333 arm64: do not enforce strict 16 byte alignment to stack pointer)
Merging blackfin/for-linus (391e74a51ea2 eth: bf609 eth clock: add pclk clock for stmmac driver probe)
CONFLICT (content): Merge conflict in arch/blackfin/mach-common/pm.c
Merging c6x/for-linux-next (ca3060d39ae7 c6x: Use generic clkdev.h header)
Merging cris/for-next (f9f3f864b5e8 cris: Fix section mismatches in architecture startup code)
Merging h8300/h8300-next (8cad489261c5 h8300: switch EARLYCON)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (787ca32dc704 ia64/unaligned: Silence another GCC warning about an uninitialised variable)
Merging m68k/for-next (9a6462763b17 m68k/mvme16x: Include generic <linux/rtc.h>)
Merging m68knommu/for-next (1a695a905c18 Linux 4.7-rc1)
Merging metag/for-next (592ddeeff8cb metag: Fix typos)
Merging microblaze/next (52e9e6e05617 microblaze: pci: export isa_io_base to fix link errors)
Merging mips/mips-for-linux-next (b02b1fbdd338 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging nios2/for-next (9fa78f63a892 nios2: Add order-only DTC dependency to %.dtb target)
Merging parisc-hd/for-next (57f3ea7a3d6e parisc: Fix backtrace on PA-RISC)
Merging powerpc/next (138a076496e6 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next)
Merging powerpc-mpe/next (bc0195aad0da Linux 4.2-rc2)
Merging fsl/next (1eef33bec12d powerpc/86xx: Fix PCI interrupt map definition)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (0b45bc53cb18 s390/kexec: fix crash on resize of reserved memory)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tile/master (bdf03e59f8c1 Fix typo)
Merging uml/linux-next (a78ff1112263 um: add extended processor state save/restore support)
Merging unicore32/unicore32 (c83d8b2fc986 unicore32: mm: Add missing parameter to arch_vma_access_permitted)
Merging xtensa/for_next (9da8320bb977 xtensa: add test_kc705_hifi variant)
Merging btrfs/next (c315ef8d9db7 Merge branch 'for-chris-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux into for-linus-4.7)
Merging btrfs-kdave/for-next (012a38ea4b0f Merge branch 'for-next-next-4.7-20160601' into for-next-20160601)
Merging ceph/master (f6973c09490c ceph: use i_version to check validity of fscache)
Merging cifs/for-next (3bdc426e2497 cifs: dynamic allocation of ntlmssp blob)
Merging configfs/for-next (96c22a329351 configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions)
Merging ecryptfs/next (933c32fe0e42 ecryptfs: drop null test before destroy functions)
Merging ext3/for_next (b9d8905e4a75 reiserfs: check kstrdup failure)
Merging ext4/dev (12735f881952 ext4: pre-zero allocated blocks for DAX IO)
Merging f2fs/dev (b02b1fbdd338 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscache/fscache (b00c2ae2ed3c FS-Cache: Don't override netfs's primary_index if registering failed)
Merging fuse/for-next (4441f63ab7e5 fuse: update mailing list in MAINTAINERS)
Merging gfs2/for-next (29567292c0b5 Merge tag 'for-linus-4.7-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip)
Merging jfs/jfs-next (6ed71e9819ac jfs: Coalesce some formats)
Merging nfs/linux-next (4340fa55298d Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging nfsd/nfsd-next (9e62f931dd07 rpc: share one xps between all backchannels)
Merging orangefs/for-next (2dcd0af568b0 Linux 4.6)
Merging overlayfs/overlayfs-next (7d43ba76af20 ovl: store ovl_entry in inode->i_private for all inodes)
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (1112018cefc5 ubifs: ubifs_dump_inode: Fix dumping field bulk_read)
Merging xfs/for-next (26f1fe858f27 xfs: reduce lock hold times in buffer writeback)
Merging file-locks/linux-next (5af9c2e19da6 Merge branch 'akpm' (patches from Andrew))
Merging vfs/for-next (1eb82bc8e712 Merge branch 'for-linus' into for-next)
Merging pci/next (1a695a905c18 Linux 4.7-rc1)
Merging pstore/for-next/pstore (8cfc8ddc99df pstore: add lzo/lz4 compression support)
Merging hid/for-next (6712bcbbbebf Merge branch 'for-4.8/uhid-offload-hid-device-add' into for-next)
Merging i2c/i2c/for-next (1a695a905c18 Linux 4.7-rc1)
Merging jdelvare-hwmon/master (18c358ac5e32 Documentation/hwmon: Update links in max34440)
Merging dmi/master (c3db05ecf8ac firmware: dmi_scan: Save SMBIOS Type 9 System Slots)
Merging hwmon-staging/hwmon-next (03bd75a88d6c hwmon: (max1668) Fix typo in documentation)
Merging v4l-dvb/master (73dfb701d254 Merge branch 'v4l_for_linus' into to_next)
Merging pm/linux-next (5731f6bf1726 Merge branch 'acpi-processor' into linux-next)
Merging idle/next (f55532a0c0b8 Linux 4.6-rc1)
Merging thermal/next (546afd1a3678 Merge branches 'for-rc' and 'thermal-sysfs-locking' into next)
Merging thermal-soc/next (ddc8fdc6e2f0 Merge branch 'work-fixes' into work-next)
CONFLICT (add/add): Merge conflict in drivers/thermal/tango_thermal.c
CONFLICT (content): Merge conflict in drivers/thermal/rockchip_thermal.c
Merging ieee1394/for-next (384fbb96f926 firewire: nosy: Replace timeval with timespec64)
Merging dlm/next (82c7d823cc31 dlm: config: Fix ENOMEM failures in make_cluster())
Merging swiotlb/linux-next (386744425e35 swiotlb: Make linux/swiotlb.h standalone includible)
Merging slave-dma/next (4f0382030b6d Merge branch 'topic/sh' into next)
Merging net-next/master (b87ab6b8e517 net: vrf: set operstate and mtu at link create)
Merging ipsec-next/master (cb866e3298cd xfrm: Increment statistic counter on inner mode error)
Merging ipvs-next/master (698e2a8dca98 ipvs: make drop_entry protection effective for SIP-pe)
Merging wireless-drivers-next/master (52776a700b53 Merge ath-next from ath.git)
Merging bluetooth/master (6b15d6650c53 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging mac80211-next/master (019ae3a91881 cfg80211: Advertise extended capabilities per interface type to userspace)
Merging rdma/for-next (7a226f9c32b0 staging/rdma: Remove the entire rdma subdirectory of staging)
Merging rdma-leon/rdma-next (1a695a905c18 Linux 4.7-rc1)
Merging rdma-leon-test/testing/rdma-next (1a695a905c18 Linux 4.7-rc1)
Merging mtd/master (becc7ae544c6 MAINTAINERS: Add file patterns for mtd device tree bindings)
Merging l2-mtd/master (95193796256c mtd: m25p80: read in spi_max_transfer_size chunks)
Merging nand/nand/next (cabfeaa67843 ARM: OMAP2+: Update GPMC and NAND DT binding documentation)
Merging crypto/master (0a7f330c12f2 crypto: sha1-mb - stylistic cleanup)
Merging drm/drm-next (66fd7a66e8b9 Merge branch 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel into drm-next)
Merging drm-panel/drm/panel/for-next (227e4f4079e1 drm/panel: simple: Add support for TPK U.S.A. LLC Fusion 7" and 10.1" panels)
Merging drm-intel/for-linux-next (df457245b5b7 drm/i915: Extract physical display dimensions from VBT)
Merging drm-tegra/drm/tegra/for-next (057eab2013ec MAINTAINERS: Remove Terje Bergström as Tegra DRM maintainer)
Merging drm-misc/topic/drm-misc (490d3d1b9120 drm: Store the plane's index)
Merging drm-exynos/exynos-drm/for-next (25364a9e54fb Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging drm-msm/msm-next (2b669875332f drm/msm: Drop load/unload drm_driver ops)
Merging hdlcd/for-upstream/hdlcd (f6c68b4bd4a9 drm: hdlcd: Add information about the underlying framebuffers in debugfs)
Merging drm-vc4/drm-vc4-next (1a4a4affa058 drm/vc4: clean up error exit path on failed dpi_connector allocation)
Merging sunxi/sunxi/for-next (30ce0df9ee51 Merge branches 'sunxi/defconfig-for-4.8', 'sunxi/drm-fixes-for-4.7' and 'sunxi/dt-for-4.8' into sunxi/for-next)
Merging kbuild/for-next (0c644e04ad1b Merge branch 'kbuild/misc' into kbuild/for-next)
Merging kconfig/for-next (5bcba792bb30 localmodconfig: Fix whitespace repeat count after "tristate")
Merging regmap/for-next (545c89f17046 Merge remote-tracking branches 'regmap/topic/irq' and 'regmap/topic/maintainers' into regmap-next)
Merging sound/for-next (1524c7191be2 ALSA: adlib: Utilize the module_isa_driver macro)
Merging sound-asoc/for-next (848a8aafec4e Merge remote-tracking branches 'asoc/topic/tas571x', 'asoc/topic/tlv320aic31xx' and 'asoc/topic/wm8985' into asoc-next)
Merging modules/modules-next (e2d1248432c4 module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled)
Merging input/next (1afca2b66aac Input: add Pegasus Notetaker tablet driver)
Merging block/for-next (661806a31989 Merge branch 'for-4.7/core' into for-next)
Merging lightnvm/for-next (2a65aee4011b lightnvm: reserved space calculation incorrect)
Merging device-mapper/for-next (b8ef07be98b4 dm mpath: add optional "queue_mode" feature)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc-uh/next (afefc102df1b mmc: sunxi: Re-enable eMMC HS-DDR modes on Allwinner A80)
Merging md/for-next (412575807427 right meaning of PARITY_ENABLE_RMW and PARITY_PREFER_RMW)
Merging mfd/for-mfd-next (b52207ef4ea5 mfd: hi655x: Add MFD driver for hi655x)
Merging backlight/for-backlight-next (60d613d6aef4 backlight: pwm_bl: Free PWM requested by legacy API on error path)
Merging battery/master (4a99fa06a8ca sbs-battery: fix power status when battery charging near dry)
Merging omap_dss2/for-next (ab366b40b851 fbdev: Use IS_ENABLED() instead of checking for built-in or module)
Merging regulator/for-next (afafb91512cf Merge remote-tracking branches 'regulator/topic/axp20x', 'regulator/topic/fixed', 'regulator/topic/headers', 'regulator/topic/max8973' and 'regulator/topic/mt6397' into regulator-next)
Merging security/next (b937190c40de LSM: LoadPin: provide enablement CONFIG)
Merging integrity/next (05d1a717ec04 ima: add support for creating files using the mknodat syscall)
Merging keys/keys-next (75aeddd12f20 MAINTAINERS: Update keyrings record and add asymmetric keys record)
Merging selinux/next (7ea59202db8d selinux: Only apply bounds checking to source types)
Merging tpmdd/next (e8f2f45a4402 tpm: Fix suspend regression)
Merging watchdog/master (1a695a905c18 Linux 4.7-rc1)
Merging iommu/next (6c0b43df74f9 Merge branches 'arm/io-pgtable', 'arm/rockchip', 'arm/omap', 'x86/vt-d', 'ppc/pamu', 'core' and 'x86/amd' into next)
Merging dwmw2-iommu/master (2566278551d3 Merge git://git.infradead.org/intel-iommu)
Merging vfio/next (f70552809419 vfio_pci: Test for extended capabilities if config space > 256 bytes)
Merging jc_docs/docs-next (9f8036643dd9 doc: self-protection: provide initial details)
Merging trivial/for-next (52bbe141f37f gitignore: fix wording)
Merging audit/next (2b4c7afe79a8 audit: fixup: log on errors from filter user rules)
Merging devicetree/devicetree/next (48a9b733e644 of/irq: Rename "intc_desc" to "of_intc_desc" to fix OF on sh)
Merging dt-rh/for-next (f2c27767af0a devicetree: Add Creative Technology vendor id)
Merging mailbox/mailbox-for-next (c430cf376fee mailbox: Fix devm_ioremap_resource error detection code)
Merging spi/for-next (e767713092de Merge remote-tracking branches 'spi/topic/maintainers', 'spi/topic/orion', 'spi/topic/pxa2xx' and 'spi/topic/rockchip' into spi-next)
Merging tip/auto-latest (49d235b07112 Merge branch 'WIP.futex')
Merging clockevents/clockevents/next (cee77c2c5b57 clocksource/drivers/tango-xtal: Fix incorrect test)
Merging edac/linux_next (12f0721c5a70 sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell)
Merging edac-amd/for-next (3f37a36b6282 EDAC, amd64_edac: Drop pci_register_driver() use)
Merging irqchip/irqchip/for-next (a66ce4b7d9d2 Merge branch 'irqchip/mvebu' into irqchip/for-next)
Merging ftrace/for-next (97f8827a8c79 ftracetest: Use proper logic to find process PID)
Merging rcu/rcu/next (0e7e2457e4e4 Merge commit 'dcd36d01fb3f99d1d5df01714f6ccbe3fbbaf81f' into HEAD)
Merging kvm/linux-next (d14bdb553f91 KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS)
Merging kvm-arm/next (35a2d58588f0 KVM: arm/arm64: vgic-new: Synchronize changes to active state)
Merging kvm-ppc/kvm-ppc-next (c63517c2e381 KVM: PPC: Book3S: correct width in XER handling)
Merging kvm-ppc-paulus/kvm-ppc-next (b1a4286b8f33 KVM: PPC: Book3S HV: Re-enable XICS fast path for irqfd-generated interrupts)
Merging kvms390/next (60a37709ce60 KVM: s390: Populate mask of non-hypervisor managed facility bits)
Merging xen-tip/linux-next (bdadcaf2a7c1 xen: remove incorrect forward declaration)
Merging percpu/for-next (6710e594f71c percpu: fix synchronization between synchronous map extension and chunk destruction)
Merging workqueues/for-next (f1e89a8f3358 Merge branch 'for-4.6-fixes' into for-next)
Merging drivers-x86/for-next (b740d2e9233c platform/x86: Add PMC Driver for Intel Core SoC)
Merging chrome-platform/for-next (31b764171cb5 Revert "platform/chrome: chromeos_laptop: Add Leon Touch")
Merging hsi/for-next (b32bd7e7d5c1 hsi: use kmemdup)
Merging leds/for-next (a534769305ec leds: core: Fix brightness setting upon hardware blinking enabled)
Merging ipmi/for-next (a1b4e31bfabb IPMI: reserve memio regions separately)
Merging driver-core/driver-core-next (1a695a905c18 Linux 4.7-rc1)
Merging tty/tty-next (1a695a905c18 Linux 4.7-rc1)
Merging usb/usb-next (1a695a905c18 Linux 4.7-rc1)
Merging usb-gadget/next (2a58f9c12bb3 usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP)
Merging usb-serial/usb-next (b923c6c62981 USB: serial: ti_usb_3410_5052: add MOXA UPORT 11x0 support)
Merging usb-chipidea-next/ci-for-usb-next (764763f0a0c8 doc: usb: chipidea: update the doc for OTG FSM)
Merging staging/staging-next (1a695a905c18 Linux 4.7-rc1)
Merging char-misc/char-misc-next (1a695a905c18 Linux 4.7-rc1)
Merging extcon/extcon-next (eb8652bd8d84 extcon: arizona: Update binding docs to mention new defines for GPSW)
Merging cgroup/for-next (332d8a2fd141 cgroup: set css->id to -1 during init)
Merging scsi/for-next (787ab6e97024 aacraid: do not activate events on non-SRC adapters)
Merging target-updates/for-next (8f0dfb3d8b11 iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race)
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging libata/for-next (5219d6530ef0 ata: Use IS_ENABLED() instead of checking for built-in or module)
Merging pinctrl/for-next (a02fcf38ade9 Merge branch 'devel' into for-next)
Merging vhost/linux-next (bb991288728e ringtest: pass buf != NULL)
Merging remoteproc/for-next (7a6271a80cae remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias)
Merging rpmsg/for-next (da5cb422f15d Merge branches 'rpmsg-next' and 'rproc-next' into for-next)
Merging gpio/for-next (63e213fc63c0 Merge branch 'devel' into for-next)
Merging dma-mapping/dma-mapping-next (d770e558e219 Linux 4.2-rc1)
Merging pwm/for-next (18c588786c08 Merge branch 'for-4.7/pwm-atomic' into for-next)
Merging dma-buf/for-next (b02da6f82361 dma-buf: use vma_pages())
Merging userns/for-next (f2ca379642d7 namei: permit linking with CAP_FOWNER in userns)
Merging ktest/for-next (2dcd0af568b0 Linux 4.6)
Merging clk/clk-next (ae4185cd13a3 MAINTAINERS: Add file patterns for clock device tree bindings)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (1a695a905c18 Linux 4.7-rc1)
Merging y2038/y2038 (4b277763c5b3 vfs: Add support to document max and min inode times)
Merging luto-misc/next (afd2ff9b7e1b Linux 4.4)
Merging borntraeger/linux-next (b562e44f507e Linux 4.5)
Merging livepatching/for-next (6d9122078097 Merge branch 'for-4.7/core' into for-next)
Merging coresight/next (c568ba901f27 coresight: Handle build path error)
Merging rtc/rtc-next (95df4c078bf3 char/genrtc: remove the rest of the driver)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (36092ee8ba69 Merge branch 'for-4.7/dax' into libnvdimm-for-next)
Merging dax-misc/dax-misc (4d9a2c874667 dax: Remove i_mmap_lock protection)
Merging akpm-current/current (f245c9aa3041 mm, page_alloc: recalculate the preferred zoneref if the context can ignore memory policies)
CONFLICT (content): Merge conflict in sound/soc/qcom/lpass-platform.c
CONFLICT (content): Merge conflict in net/9p/client.c
CONFLICT (content): Merge conflict in fs/binfmt_flat.c
CONFLICT (content): Merge conflict in drivers/mmc/core/mmc.c
$ git checkout -b akpm remotes/origin/akpm/master
Applying: mm: make optimistic check for swapin readahead fix
Applying: drivers/net/wireless/intel/iwlwifi/dvm/calib.c: simplfy min() expression
Applying: drivers/fpga/Kconfig: fix build failure
Merging akpm/master (e5471ddc86f0 drivers/fpga/Kconfig: fix build failure)
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Sergey Senozhatsky @ 2016-06-03 4:14 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Ebru Akagunduz, Vlastimil Babka, Andrew Morton, Michal Hocko,
Kirill A. Shutemov, Stephen Rothwell, Andrea Arcangeli,
Rik van Riel, linux-mm, linux-next, linux-kernel
In-Reply-To: <20160603012919.GB464@swordfish>
On (06/03/16 10:29), Sergey Senozhatsky wrote:
> > if (allocstall == curr_allocstall && swap != 0) {
> > if (!__collapse_huge_page_swapin(mm, vma, address, pmd)) {
> > {
> > : if (ret & VM_FAULT_RETRY) {
> > : down_read(&mm->mmap_sem);
> > : ^^^^^^^^^
>
> oh... it's in a loop
>
> for (_address = address; _address < address + HPAGE_PMD_NR*PAGE_SIZE;
> pte++, _address += PAGE_SIZE) {
> ret = do_swap_page()
> if (ret & VM_FAULT_RETRY) {
> down_read(&mm->mmap_sem);
> ^^^^^^^^^
> ...
> }
> }
>
> so there can be multiple sem->count++ in __collapse_huge_page_swapin(),
> and you don't know how many sem->count-- you need to do later? is this
> correct or am I hallucinating?
No, I was wrong, sorry for the noise.
it's getting unlocked in
__collapse_huge_page_swapin()
do_swap_page()
lock_page_or_retry()
if (flags & FAULT_FLAG_ALLOW_RETRY)
up_read(&mm->mmap_sem);
return VM_FAULT_RETRY
-ss
^ permalink raw reply
* Re: ath9k gpio request
From: Kalle Valo @ 2016-06-03 5:33 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Sudip Mukherjee, Stephen Rothwell, ath9k-devel,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
netdev@vger.kernel.org, Miaoqing Pan
In-Reply-To: <57501AE4.7080104@gmail.com>
Sudip Mukherjee <sudipm.mukherjee@gmail.com> writes:
> On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote:
>> Seems there are something wrong in the datasheet, try
>>
>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>> @@ -1122,8 +1122,8 @@ enum {
>> #define AR9300_NUM_GPIO 16
>> #define AR9330_NUM_GPIO 16
>> #define AR9340_NUM_GPIO 23
>> -#define AR9462_NUM_GPIO 10
>> -#define AR9485_NUM_GPIO 12
>> +#define AR9462_NUM_GPIO 14
>> +#define AR9485_NUM_GPIO 11
>> #define AR9531_NUM_GPIO 18
>> #define AR9550_NUM_GPIO 24
>> #define AR9561_NUM_GPIO 23
>> @@ -1139,8 +1139,8 @@ enum {
>> #define AR9300_GPIO_MASK 0x0000F4FF
>> #define AR9330_GPIO_MASK 0x0000F4FF
>> #define AR9340_GPIO_MASK 0x0000000F
>> -#define AR9462_GPIO_MASK 0x000003FF
>> -#define AR9485_GPIO_MASK 0x00000FFF
>> +#define AR9462_GPIO_MASK 0x00003FFF
>> +#define AR9485_GPIO_MASK 0x000007FF
>> #define AR9531_GPIO_MASK 0x0000000F
>> #define AR9550_GPIO_MASK 0x0000000F
>> #define AR9561_GPIO_MASK 0x0000000F
>
> solves the problem.
>
> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Great, thanks for testing everyone. Miaoqing, please send a proper patch
ASAP and I'll push it to 4.7.
--
Kalle Valo
^ permalink raw reply
* Re: ath9k gpio request
From: Pan, Miaoqing @ 2016-06-03 5:49 UTC (permalink / raw)
To: Kalle Valo
Cc: Sudip Mukherjee, Stephen Rothwell, ath9k-devel,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
netdev@vger.kernel.org, Miaoqing Pan
In-Reply-To: <8760tqn8fc.fsf@purkki.adurom.net>
Done, https://patchwork.kernel.org/patch/9151847/.
Thanks,
Miaoqing
________________________________________
From: Kalle Valo <kvalo@codeaurora.org>
Sent: Friday, June 3, 2016 1:33 PM
To: Pan, Miaoqing
Cc: Sudip Mukherjee; Stephen Rothwell; ath9k-devel; linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; netdev@vger.kernel.org; Miaoqing Pan
Subject: Re: ath9k gpio request
Sudip Mukherjee <sudipm.mukherjee@gmail.com> writes:
> On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote:
>> Seems there are something wrong in the datasheet, try
>>
>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>> @@ -1122,8 +1122,8 @@ enum {
>> #define AR9300_NUM_GPIO 16
>> #define AR9330_NUM_GPIO 16
>> #define AR9340_NUM_GPIO 23
>> -#define AR9462_NUM_GPIO 10
>> -#define AR9485_NUM_GPIO 12
>> +#define AR9462_NUM_GPIO 14
>> +#define AR9485_NUM_GPIO 11
>> #define AR9531_NUM_GPIO 18
>> #define AR9550_NUM_GPIO 24
>> #define AR9561_NUM_GPIO 23
>> @@ -1139,8 +1139,8 @@ enum {
>> #define AR9300_GPIO_MASK 0x0000F4FF
>> #define AR9330_GPIO_MASK 0x0000F4FF
>> #define AR9340_GPIO_MASK 0x0000000F
>> -#define AR9462_GPIO_MASK 0x000003FF
>> -#define AR9485_GPIO_MASK 0x00000FFF
>> +#define AR9462_GPIO_MASK 0x00003FFF
>> +#define AR9485_GPIO_MASK 0x000007FF
>> #define AR9531_GPIO_MASK 0x0000000F
>> #define AR9550_GPIO_MASK 0x0000000F
>> #define AR9561_GPIO_MASK 0x0000000F
>
> solves the problem.
>
> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Great, thanks for testing everyone. Miaoqing, please send a proper patch
ASAP and I'll push it to 4.7.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next/linux memleak after IO on dax mountpoint
From: Xiong Zhou @ 2016-06-03 6:35 UTC (permalink / raw)
To: David Drysdale, hch
Cc: Xiong Zhou, Stephen Rothwell, axboe, linux-next, linux-nvdimm,
linux-kernel@vger.kernel.org
In-Reply-To: <CAHse=S-H_yMhZKNmMZpb41M+o+2tMRyxiUG9wQoemewBXXYTPw@mail.gmail.com>
On Thu, Jun 02, 2016 at 04:22:37PM +0100, David Drysdale wrote:
> On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou <xzhou@redhat.com> wrote:
> > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
> > ...
> >> Still working on to id which commit in this merge causes this issuer,
> >
> > Narrowed down to:
> >
> > 37e5823 block: add offset in blk_add_request_payload()
...
> > 0bf77e9 nvme: switch to RCU freeing the namespace
> > 9082e87 block: remove struct bio_batch
>
> FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> a different scenario (just normal desktop use). Not done much
> digging so far, but this commit (9082e87bf) looks like it might be
> relevant
<snip..>
Thanks for the tip, accelerated my searching in the block merge.
On top of v4.7-rc1 , in order to revert this commit cleanly:
9082e87 block: remove struct bio_batch
, have to revert these two:
bbd848e0f block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard
38f2525 block: add __blkdev_issue_discard
, then have to revert these two dependances:
202bae5 dm thin: unroll issue_discard() to create longer discard bio chains
3dba53a9 dm thin: use __blkdev_issue_discard for async discard support
With all these five commits reverted, NO memleak happens.
Reverting other four commits while not reverting 9082e87, memleak
happens.
Thanks,
Xiong
^ permalink raw reply
* next-20160603 build: 0 failures 2 warnings (next-20160603)
From: Build bot for Mark Brown @ 2016-06-03 6:55 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20160603
Git describe: next-20160603
Commit: 64289ca05e Add linux-next specific files for 20160603
Build Time: 79 min 41 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 2
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : arm-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 2
2 ../drivers/dma-buf/sync_file.c:85:53: warning: format '%d' expects argument of type 'int', but argument 6 has type 'u64 {aka long long unsigned int}' [-Wformat=]
1 ../drivers/staging/iio/adc/ad7606_spi.c:24:18: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../drivers/dma-buf/sync_file.c:85:53: warning: format '%d' expects argument of type 'int', but argument 6 has type 'u64 {aka long long unsigned int}' [-Wformat=]
../drivers/staging/iio/adc/ad7606_spi.c:24:18: warning: 'data' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/dma-buf/sync_file.c:85:53: warning: format '%d' expects argument of type 'int', but argument 6 has type 'u64 {aka long long unsigned int}' [-Wformat=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allnoconfig
x86_64-allnoconfig
arm64-defconfig
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Sergey Senozhatsky @ 2016-06-03 7:15 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Kirill A. Shutemov, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Andrea Arcangeli
In-Reply-To: <20160602092113.GH1995@dhcp22.suse.cz>
Hello,
On (06/02/16 11:21), Michal Hocko wrote:
[..]
> @@ -2863,6 +2854,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
>
> collect_mm_slot(mm_slot);
> }
> + mmput(mm);
>
> return progress;
> }
this possibly sleeping mmput() is called from
under the spin_lock(&khugepaged_mm_lock).
there is also a trivial build fixup needed
(move collect_mm_slot() before __khugepaged_exit()).
it's quite hard to trigger the bug (somehow), so I can't
follow up with more information as of now.
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 7:25 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Kirill A. Shutemov,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Andrea Arcangeli
In-Reply-To: <20160603071551.GA453@swordfish>
On Fri 03-06-16 16:15:51, Sergey Senozhatsky wrote:
> Hello,
>
> On (06/02/16 11:21), Michal Hocko wrote:
> [..]
> > @@ -2863,6 +2854,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
> >
> > collect_mm_slot(mm_slot);
> > }
> > + mmput(mm);
> >
> > return progress;
> > }
>
> this possibly sleeping mmput() is called from
> under the spin_lock(&khugepaged_mm_lock).
You are right. khugepaged_scan_mm_slot returns with the lock held.
mmput_async would deal with it.
> there is also a trivial build fixup needed
> (move collect_mm_slot() before __khugepaged_exit()).
will fix that. Thanks!
> it's quite hard to trigger the bug (somehow), so I can't
> follow up with more information as of now.
Thanks anyway!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Sergey Senozhatsky @ 2016-06-03 8:43 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Kirill A. Shutemov, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Andrea Arcangeli
In-Reply-To: <20160603072536.GB20676@dhcp22.suse.cz>
On (06/03/16 09:25), Michal Hocko wrote:
> > it's quite hard to trigger the bug (somehow), so I can't
> > follow up with more information as of now.
either I did something very silly fixing up the patch, or the
patch may be causing general protection faults on my system.
RIP collect_mm_slot() + 0x42/0x84
khugepaged
prepare_to_wait_event
maybe_pmd_mkwrite
kthread
_raw_sin_unlock_irq
ret_from_fork
kthread_create_on_node
collect_mm_slot() + 0x42/0x84 is
0000000000000328 <collect_mm_slot>:
328: 55 push %rbp
329: 48 89 e5 mov %rsp,%rbp
32c: 53 push %rbx
32d: 48 8b 5f 20 mov 0x20(%rdi),%rbx
331: 8b 43 48 mov 0x48(%rbx),%eax
334: ff c8 dec %eax
336: 7f 71 jg 3a9 <collect_mm_slot+0x81>
338: 48 8b 57 08 mov 0x8(%rdi),%rdx
33c: 48 85 d2 test %rdx,%rdx
33f: 74 1e je 35f <collect_mm_slot+0x37>
341: 48 8b 07 mov (%rdi),%rax
344: 48 85 c0 test %rax,%rax
347: 48 89 02 mov %rax,(%rdx)
34a: 74 04 je 350 <collect_mm_slot+0x28>
34c: 48 89 50 08 mov %rdx,0x8(%rax)
350: 48 c7 07 00 00 00 00 movq $0x0,(%rdi)
357: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi)
35e: 00
35f: 48 8b 57 10 mov 0x10(%rdi),%rdx
363: 48 8b 47 18 mov 0x18(%rdi),%rax
367: 48 89 fe mov %rdi,%rsi
36a: 48 89 42 08 mov %rax,0x8(%rdx)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
36e: 48 89 10 mov %rdx,(%rax)
371: 48 b8 00 01 00 00 00 movabs $0xdead000000000100,%rax
378: 00 ad de
37b: 48 89 47 10 mov %rax,0x10(%rdi)
37f: 48 b8 00 02 00 00 00 movabs $0xdead000000000200,%rax
386: 00 ad de
389: 48 89 47 18 mov %rax,0x18(%rdi)
38d: 48 8b 3d 00 00 00 00 mov 0x0(%rip),%rdi # 394 <collect_mm_slot+0x6c>
394: e8 00 00 00 00 callq 399 <collect_mm_slot+0x71>
399: f0 ff 4b 4c lock decl 0x4c(%rbx)
39d: 74 02 je 3a1 <collect_mm_slot+0x79>
39f: eb 08 jmp 3a9 <collect_mm_slot+0x81>
3a1: 48 89 df mov %rbx,%rdi
3a4: e8 00 00 00 00 callq 3a9 <collect_mm_slot+0x81>
3a9: 5b pop %rbx
3aa: 5d pop %rbp
3ab: c3 retq
which is list_del(&mm_slot->mm_node), I believe.
I attached the patch (just in case).
---
mm/huge_memory.c | 87 +++++++++++++++++++++++++-------------------------------
1 file changed, 39 insertions(+), 48 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 292cedd..1c82fa4 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1938,7 +1938,8 @@ static void insert_to_mm_slots_hash(struct mm_struct *mm,
static inline int khugepaged_test_exit(struct mm_struct *mm)
{
- return atomic_read(&mm->mm_users) == 0;
+ /* the only pin is from khugepaged_scan_mm_slot */
+ return atomic_read(&mm->mm_users) <= 1;
}
int __khugepaged_enter(struct mm_struct *mm)
@@ -1950,8 +1951,6 @@ int __khugepaged_enter(struct mm_struct *mm)
if (!mm_slot)
return -ENOMEM;
- /* __khugepaged_exit() must not run from under us */
- VM_BUG_ON_MM(khugepaged_test_exit(mm), mm);
if (unlikely(test_and_set_bit(MMF_VM_HUGEPAGE, &mm->flags))) {
free_mm_slot(mm_slot);
return 0;
@@ -1994,36 +1993,40 @@ int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
return 0;
}
-void __khugepaged_exit(struct mm_struct *mm)
+static void collect_mm_slot(struct mm_slot *mm_slot)
{
- struct mm_slot *mm_slot;
- int free = 0;
+ struct mm_struct *mm = mm_slot->mm;
- spin_lock(&khugepaged_mm_lock);
- mm_slot = get_mm_slot(mm);
- if (mm_slot && khugepaged_scan.mm_slot != mm_slot) {
+ VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
+
+ if (khugepaged_test_exit(mm)) {
+ /* free mm_slot */
hash_del(&mm_slot->hash);
list_del(&mm_slot->mm_node);
- free = 1;
- }
- spin_unlock(&khugepaged_mm_lock);
- if (free) {
- clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
- free_mm_slot(mm_slot);
- mmdrop(mm);
- } else if (mm_slot) {
/*
- * This is required to serialize against
- * khugepaged_test_exit() (which is guaranteed to run
- * under mmap sem read mode). Stop here (after we
- * return all pagetables will be destroyed) until
- * khugepaged has finished working on the pagetables
- * under the mmap_sem.
+ * Not strictly needed because the mm exited already.
+ *
+ * clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
*/
- down_write(&mm->mmap_sem);
- up_write(&mm->mmap_sem);
+
+ /* khugepaged_mm_lock actually not necessary for the below */
+ free_mm_slot(mm_slot);
+ mmdrop(mm);
+ }
+}
+
+void __khugepaged_exit(struct mm_struct *mm)
+{
+ struct mm_slot *mm_slot;
+
+ spin_lock(&khugepaged_mm_lock);
+ mm_slot = get_mm_slot(mm);
+ if (mm_slot) {
+ collect_mm_slot(mm_slot);
+ clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
}
+ spin_unlock(&khugepaged_mm_lock);
}
static void release_pte_page(struct page *page)
@@ -2738,29 +2741,6 @@ out:
return ret;
}
-static void collect_mm_slot(struct mm_slot *mm_slot)
-{
- struct mm_struct *mm = mm_slot->mm;
-
- VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
-
- if (khugepaged_test_exit(mm)) {
- /* free mm_slot */
- hash_del(&mm_slot->hash);
- list_del(&mm_slot->mm_node);
-
- /*
- * Not strictly needed because the mm exited already.
- *
- * clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
- */
-
- /* khugepaged_mm_lock actually not necessary for the below */
- free_mm_slot(mm_slot);
- mmdrop(mm);
- }
-}
-
static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
struct page **hpage)
__releases(&khugepaged_mm_lock)
@@ -2782,6 +2762,16 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
khugepaged_scan.address = 0;
khugepaged_scan.mm_slot = mm_slot;
}
+
+ /*
+ * Do not even try to do anything if the current mm is already
+ * dead. khugepaged_mm_lock will make sure only this or
+ * __khugepaged_exit does the unhasing.
+ */
+ if (!atomic_inc_not_zero(&mm_slot->mm->mm_users)) {
+ collect_mm_slot(mm_slot);
+ return progress;
+ }
spin_unlock(&khugepaged_mm_lock);
mm = mm_slot->mm;
@@ -2865,6 +2855,7 @@ breakouterloop_mmap_sem:
collect_mm_slot(mm_slot);
}
+ mmput_async(mm);
return progress;
}
--
2.9.0.rc1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 9:55 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Kirill A. Shutemov,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Andrea Arcangeli
In-Reply-To: <20160603084347.GA502@swordfish>
On Fri 03-06-16 17:43:47, Sergey Senozhatsky wrote:
> On (06/03/16 09:25), Michal Hocko wrote:
> > > it's quite hard to trigger the bug (somehow), so I can't
> > > follow up with more information as of now.
>
> either I did something very silly fixing up the patch, or the
> patch may be causing general protection faults on my system.
>
> RIP collect_mm_slot() + 0x42/0x84
> khugepaged
So is this really collect_mm_slot called directly from khugepaged or is
some inlining going on there?
> prepare_to_wait_event
> maybe_pmd_mkwrite
> kthread
> _raw_sin_unlock_irq
> ret_from_fork
> kthread_create_on_node
>
> collect_mm_slot() + 0x42/0x84 is
I guess that the problem is that I have missed that __khugepaged_exit
doesn't clear the cached khugepaged_scan.mm_slot. Does the following on
top fixes that?
---
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6574c62ca4a3..e6f4e6fd587a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2021,6 +2021,8 @@ void __khugepaged_exit(struct mm_struct *mm)
spin_lock(&khugepaged_mm_lock);
mm_slot = get_mm_slot(mm);
if (mm_slot) {
+ if (khugepaged_scan.mm_slot == mm_slot)
+ khugepaged_scan.mm_slot = NULL;
collect_mm_slot(mm_slot);
clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
}
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 10:05 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Kirill A. Shutemov,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Andrea Arcangeli
In-Reply-To: <20160603095549.GD20676@dhcp22.suse.cz>
On Fri 03-06-16 11:55:49, Michal Hocko wrote:
> On Fri 03-06-16 17:43:47, Sergey Senozhatsky wrote:
> > On (06/03/16 09:25), Michal Hocko wrote:
> > > > it's quite hard to trigger the bug (somehow), so I can't
> > > > follow up with more information as of now.
> >
> > either I did something very silly fixing up the patch, or the
> > patch may be causing general protection faults on my system.
> >
> > RIP collect_mm_slot() + 0x42/0x84
> > khugepaged
>
> So is this really collect_mm_slot called directly from khugepaged or is
> some inlining going on there?
>
> > prepare_to_wait_event
> > maybe_pmd_mkwrite
> > kthread
> > _raw_sin_unlock_irq
> > ret_from_fork
> > kthread_create_on_node
> >
> > collect_mm_slot() + 0x42/0x84 is
>
> I guess that the problem is that I have missed that __khugepaged_exit
> doesn't clear the cached khugepaged_scan.mm_slot. Does the following on
> top fixes that?
That wouldn't be sufficient after a closer look. We need to do the same
from khugepaged_scan_mm_slot when atomic_inc_not_zero fails. So I guess
it would be better to stick it into collect_mm_slot.
Thanks for your testing!
---
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6574c62ca4a3..0432581fb87c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2011,6 +2011,9 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
/* khugepaged_mm_lock actually not necessary for the below */
free_mm_slot(mm_slot);
mmdrop(mm);
+
+ if (khugepaged_scan.mm_slot == mm_slot)
+ khugepaged_scan.mm_slot = NULL;
}
}
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* [PATCH] mm, thp: fix locking inconsistency in collapse_huge_page
From: Ebru Akagunduz @ 2016-06-03 12:28 UTC (permalink / raw)
To: akpm
Cc: vbabka, sergey.senozhatsky.work, mhocko, kirill.shutemov, sfr,
linux-mm, linux-next, linux-kernel, riel, aarcange,
Ebru Akagunduz
In-Reply-To: <0c47a3a0-5530-b257-1c1f-28ed44ba97e6@suse.cz>
After creating revalidate vma function, locking inconsistency occured
due to directing the code path to wrong label. This patch directs
to correct label and fix the inconsistency.
Related commit that caused inconsistency:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=da4360877094368f6dfe75bbe804b0f0a5d575b0
Signed-off-by: Ebru Akagunduz <ebru.akagunduz@gmail.com>
---
mm/huge_memory.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 292cedd..8043d91 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2493,13 +2493,18 @@ static void collapse_huge_page(struct mm_struct *mm,
curr_allocstall = sum_vm_event(ALLOCSTALL);
down_read(&mm->mmap_sem);
result = hugepage_vma_revalidate(mm, vma, address);
- if (result)
- goto out;
+ if (result) {
+ mem_cgroup_cancel_charge(new_page, memcg, true);
+ up_read(&mm->mmap_sem);
+ goto out_nolock;
+ }
pmd = mm_find_pmd(mm, address);
if (!pmd) {
result = SCAN_PMD_NULL;
- goto out;
+ mem_cgroup_cancel_charge(new_page, memcg, true);
+ up_read(&mm->mmap_sem);
+ goto out_nolock;
}
/*
@@ -2513,8 +2518,9 @@ static void collapse_huge_page(struct mm_struct *mm,
* label out. Continuing to collapse causes inconsistency.
*/
if (!__collapse_huge_page_swapin(mm, vma, address, pmd)) {
+ mem_cgroup_cancel_charge(new_page, memcg, true);
up_read(&mm->mmap_sem);
- goto out;
+ goto out_nolock;
}
}
--
1.9.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Sergey Senozhatsky @ 2016-06-03 13:38 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Kirill A. Shutemov, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Andrea Arcangeli
In-Reply-To: <20160603100505.GE20676@dhcp22.suse.cz>
On (06/03/16 12:05), Michal Hocko wrote:
> > > RIP collect_mm_slot() + 0x42/0x84
> > > khugepaged
> >
> > So is this really collect_mm_slot called directly from khugepaged or is
> > some inlining going on there?
inlining I suppose.
> > > prepare_to_wait_event
> > > maybe_pmd_mkwrite
> > > kthread
> > > _raw_sin_unlock_irq
> > > ret_from_fork
> > > kthread_create_on_node
> > >
> > > collect_mm_slot() + 0x42/0x84 is
> >
> > I guess that the problem is that I have missed that __khugepaged_exit
> > doesn't clear the cached khugepaged_scan.mm_slot. Does the following on
> > top fixes that?
>
> That wouldn't be sufficient after a closer look. We need to do the same
> from khugepaged_scan_mm_slot when atomic_inc_not_zero fails. So I guess
> it would be better to stick it into collect_mm_slot.
Michal, I'll try to test during the weekend (away from the affected box
now), but in the worst case it can as late as next Thursday (gonna travel
next week).
-ss
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 13:45 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Kirill A. Shutemov, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Andrea Arcangeli
In-Reply-To: <20160603133813.GA578@swordfish>
On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote:
[...]
> Michal, I'll try to test during the weekend (away from the affected box
> now), but in the worst case it can as late as next Thursday (gonna travel
> next week).
No problem. I would really like to hear from Andrea before we give this
a serious try anyway.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 13:49 UTC (permalink / raw)
To: Sergey Senozhatsky, Andrea Arcangeli
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Kirill A. Shutemov, Stephen Rothwell, linux-mm, linux-next,
linux-kernel
In-Reply-To: <20160603134509.GI20676@dhcp22.suse.cz>
On Fri 03-06-16 15:45:09, Michal Hocko wrote:
> On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote:
> [...]
> > Michal, I'll try to test during the weekend (away from the affected box
> > now), but in the worst case it can as late as next Thursday (gonna travel
> > next week).
>
> No problem. I would really like to hear from Andrea before we give this
> a serious try anyway.
And just for an easier review, here is what I have right now:
---
>From 1fa9428b215cea4a48737fc9650009616a5bcd4e Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Thu, 2 Jun 2016 10:38:37 +0200
Subject: [PATCH] khugepaged: simplify khugepaged vs. __mmput
__khugepaged_exit is called during the final __mmput and it employs a
complex synchronization dances to make sure it doesn't race with the
khugepaged which might be scanning this mm at the same time. This is
all caused by the fact that khugepaged doesn't pin mm_users. Things
would simplify considerably if we simply check the mm at
khugepaged_scan_mm_slot and if mm_users was already 0 then we know it
is dead and we can unhash the mm_slot and move on to another one. This
will also guarantee that __khugepaged_exit cannot race with khugepaged
and so we can free up the slot if it is still hashed.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/huge_memory.c | 90 ++++++++++++++++++++++++++------------------------------
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index de62bd991827..0432581fb87c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1936,7 +1936,8 @@ static void insert_to_mm_slots_hash(struct mm_struct *mm,
static inline int khugepaged_test_exit(struct mm_struct *mm)
{
- return atomic_read(&mm->mm_users) == 0;
+ /* the only pin is from khugepaged_scan_mm_slot */
+ return atomic_read(&mm->mm_users) <= 1;
}
int __khugepaged_enter(struct mm_struct *mm)
@@ -1948,8 +1949,6 @@ int __khugepaged_enter(struct mm_struct *mm)
if (!mm_slot)
return -ENOMEM;
- /* __khugepaged_exit() must not run from under us */
- VM_BUG_ON_MM(khugepaged_test_exit(mm), mm);
if (unlikely(test_and_set_bit(MMF_VM_HUGEPAGE, &mm->flags))) {
free_mm_slot(mm_slot);
return 0;
@@ -1992,36 +1991,43 @@ int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
return 0;
}
-void __khugepaged_exit(struct mm_struct *mm)
+static void collect_mm_slot(struct mm_slot *mm_slot)
{
- struct mm_slot *mm_slot;
- int free = 0;
+ struct mm_struct *mm = mm_slot->mm;
- spin_lock(&khugepaged_mm_lock);
- mm_slot = get_mm_slot(mm);
- if (mm_slot && khugepaged_scan.mm_slot != mm_slot) {
+ VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
+
+ if (khugepaged_test_exit(mm)) {
+ /* free mm_slot */
hash_del(&mm_slot->hash);
list_del(&mm_slot->mm_node);
- free = 1;
- }
- spin_unlock(&khugepaged_mm_lock);
- if (free) {
- clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
- free_mm_slot(mm_slot);
- mmdrop(mm);
- } else if (mm_slot) {
/*
- * This is required to serialize against
- * khugepaged_test_exit() (which is guaranteed to run
- * under mmap sem read mode). Stop here (after we
- * return all pagetables will be destroyed) until
- * khugepaged has finished working on the pagetables
- * under the mmap_sem.
+ * Not strictly needed because the mm exited already.
+ *
+ * clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
*/
- down_write(&mm->mmap_sem);
- up_write(&mm->mmap_sem);
+
+ /* khugepaged_mm_lock actually not necessary for the below */
+ free_mm_slot(mm_slot);
+ mmdrop(mm);
+
+ if (khugepaged_scan.mm_slot == mm_slot)
+ khugepaged_scan.mm_slot = NULL;
+ }
+}
+
+void __khugepaged_exit(struct mm_struct *mm)
+{
+ struct mm_slot *mm_slot;
+
+ spin_lock(&khugepaged_mm_lock);
+ mm_slot = get_mm_slot(mm);
+ if (mm_slot) {
+ collect_mm_slot(mm_slot);
+ clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
}
+ spin_unlock(&khugepaged_mm_lock);
}
static void release_pte_page(struct page *page)
@@ -2736,29 +2742,6 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
return ret;
}
-static void collect_mm_slot(struct mm_slot *mm_slot)
-{
- struct mm_struct *mm = mm_slot->mm;
-
- VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
-
- if (khugepaged_test_exit(mm)) {
- /* free mm_slot */
- hash_del(&mm_slot->hash);
- list_del(&mm_slot->mm_node);
-
- /*
- * Not strictly needed because the mm exited already.
- *
- * clear_bit(MMF_VM_HUGEPAGE, &mm->flags);
- */
-
- /* khugepaged_mm_lock actually not necessary for the below */
- free_mm_slot(mm_slot);
- mmdrop(mm);
- }
-}
-
static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
struct page **hpage)
__releases(&khugepaged_mm_lock)
@@ -2780,6 +2763,16 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
khugepaged_scan.address = 0;
khugepaged_scan.mm_slot = mm_slot;
}
+
+ /*
+ * Do not even try to do anything if the current mm is already
+ * dead. khugepaged_mm_lock will make sure only this or
+ * __khugepaged_exit does the unhasing.
+ */
+ if (!atomic_inc_not_zero(&mm_slot->mm->mm_users)) {
+ collect_mm_slot(mm_slot);
+ return progress;
+ }
spin_unlock(&khugepaged_mm_lock);
mm = mm_slot->mm;
@@ -2863,6 +2856,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages,
collect_mm_slot(mm_slot);
}
+ mmput_async(mm);
return progress;
}
--
2.8.1
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Andrea Arcangeli @ 2016-06-03 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Sergey Senozhatsky, Andrew Morton,
Vlastimil Babka, Kirill A. Shutemov, Stephen Rothwell, linux-mm,
linux-next, linux-kernel
In-Reply-To: <20160602122109.GM1995@dhcp22.suse.cz>
On Thu, Jun 02, 2016 at 02:21:10PM +0200, Michal Hocko wrote:
> Testing with the patch makes some sense as well, but I would like to
> hear from Andrea whether the approach is good because I am wondering why
> he hasn't done that before - it feels so much simpler than the current
> code.
The down_write in the exit path comes from __ksm_exit. If you don't
like it there I'd suggest to also remove it from __ksm_exit.
This is a proposed cleanup correct?
The first thing that I can notice is that khugepaged_test_exit() then
can only be called and provide the expected retval, after
atomic_inc_not_zero(mm_users). Also note mmget_not_zero() should be
used instead.
However the code still uses khugepaged_test_exit in __khugepage_enter
that won't increase the mm_users, so then the patch relaxes that check
too much, albeit only for a debug check not strictly a bug.
The cons of this change purely that it'll decrease the responsiveness
in releasing the RAM of a killed task a bit.
To me the fewer time we hold the mm_users the better and I don't see
an obvious runtime improvement coming from this change. It's a bit
simpler yes, but the down_write in the exit path is well understood,
ksm does the same thing and it's in a slow path (it only happens if
the mm that exited is the current one under scan by either ksmd or
khugepaged, so normally the down_write is not executed in the exit
path and the "mm" is collected right away both as a mm_users and
mm_count).
In short I think it's a tradeoff: pros) removes down_write in a slow
path of the the mm exit which may simplify the code a bit, cons) it
could increase the latency in freeing memory as result of a task
exiting or being killed during the khugepaged scan, for example while
the THP is being allocated. While compaction runs to allocate the THP
in collapse_huge_page, if the task is killed currently the memory is
released right away, without waiting for the allocation to succeed or
fail.
I don't see a big enough problem with the down_write in a slow path of
khugepaged_exit to justify the increased latency in releasing memory.
I was very happy by Oleg's patch reducing the mm_users holding of
userfaultfd too. That was controlled by userland so it would only be
an issue for non-cooperative usage which isn't upstream yet, and it
was also much wider than this one would become with the patch applied,
but I liked the direction.
If prefer instead to remove the down_write, you probably could move
the test_exit before the down_read/write to bail out before taking the
lock: you don't need the mmap_sem to do test_exit anymore. The only
reason the text_exit would remain in fact is just to reduce the
latency of the memory freeing, it then becomes a voluntary preempt
cond_resched() to release the memory to make a parallel ;), but unable
to let the kernel free the memory while the THP allocation runs.
Thanks,
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Michal Hocko @ 2016-06-03 14:46 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Sergey Senozhatsky, Sergey Senozhatsky, Andrew Morton,
Vlastimil Babka, Kirill A. Shutemov, Stephen Rothwell, linux-mm,
linux-next, linux-kernel
In-Reply-To: <20160603135154.GD29930@redhat.com>
On Fri 03-06-16 15:51:54, Andrea Arcangeli wrote:
> On Thu, Jun 02, 2016 at 02:21:10PM +0200, Michal Hocko wrote:
> > Testing with the patch makes some sense as well, but I would like to
> > hear from Andrea whether the approach is good because I am wondering why
> > he hasn't done that before - it feels so much simpler than the current
> > code.
>
> The down_write in the exit path comes from __ksm_exit. If you don't
> like it there I'd suggest to also remove it from __ksm_exit.
I see
> This is a proposed cleanup correct?
yes this is a cleanup but also a robustness thing, see below.
> The first thing that I can notice is that khugepaged_test_exit() then
> can only be called and provide the expected retval, after
> atomic_inc_not_zero(mm_users). Also note mmget_not_zero() should be
> used instead.
I didn't get used to mmget_not_zero yet, but true a helper would be
better.
[...]
> To me the fewer time we hold the mm_users the better and I don't see
> an obvious runtime improvement coming from this change. It's a bit
> simpler yes, but the down_write in the exit path is well understood,
> ksm does the same thing and it's in a slow path (it only happens if
> the mm that exited is the current one under scan by either ksmd or
> khugepaged, so normally the down_write is not executed in the exit
> path and the "mm" is collected right away both as a mm_users and
> mm_count).
OK, I see your point. I wasn't aware that the mmap_sem is dropped
before the allocation request. Then the original code indeed might
get into exit_mmap earlier wrt. to the patch.
The reason I dislike taking write lock in the __mmput is basically
for the same reason you have pointed out. exit_mmap might be delayed
for an unbounded amount of time. khugepaged resp. ksmd might be well
behaved and release their read lock for costly operations or when they
detect the mm is dead but it is hard to guarantee that all potential
kernel users/drivers are behaving the same way. It is not really trivial
to check whether we have such users (there are 100+ users outside of mm/
as per my quick git grep).
The exit path should be as simple as possible with the amount of
external dependencies reduced to the bare minimum.
> In short I think it's a tradeoff: pros) removes down_write in a slow
> path of the the mm exit which may simplify the code a bit, cons) it
> could increase the latency in freeing memory as result of a task
> exiting or being killed during the khugepaged scan, for example while
> the THP is being allocated. While compaction runs to allocate the THP
> in collapse_huge_page, if the task is killed currently the memory is
> released right away, without waiting for the allocation to succeed or
> fail.
Are those latencies a real problem. The allocation itself shouldn't
really take a long time.
> I don't see a big enough problem with the down_write in a slow path of
> khugepaged_exit to justify the increased latency in releasing memory.
What do you think about the external dependencies mentioned above. Do
you think this is a sufficient argument wrt. occasional higher
latencies?
[...]
> If prefer instead to remove the down_write, you probably could move
> the test_exit before the down_read/write to bail out before taking the
> lock: you don't need the mmap_sem to do test_exit anymore. The only
> reason the text_exit would remain in fact is just to reduce the
> latency of the memory freeing, it then becomes a voluntary preempt
> cond_resched() to release the memory to make a parallel ;), but unable
> to let the kernel free the memory while the THP allocation runs.
OK, I will think about that as well.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Andrea Arcangeli @ 2016-06-03 15:10 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Sergey Senozhatsky, Andrew Morton,
Vlastimil Babka, Kirill A. Shutemov, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Hugh Dickins
In-Reply-To: <20160603144600.GK20676@dhcp22.suse.cz>
Hello Michal,
CC'ed Hugh,
On Fri, Jun 03, 2016 at 04:46:00PM +0200, Michal Hocko wrote:
> What do you think about the external dependencies mentioned above. Do
> you think this is a sufficient argument wrt. occasional higher
> latencies?
It's a tradeoff and both latencies would be short and uncommon so it's
hard to tell.
There's also mmput_async for paths that may care about mmput
latencies. Exit itself cannot use it, it's mostly for people taking
the mm_users pin that may not want to wait for mmput to run. It also
shouldn't happen that often, it's a slow path.
The whole model inherited from KSM is to deliberately depend only on
the mmap_sem + test_exit + mm_count, and never on mm_users, which to
me in principle doesn't sound bad. I consider KSM version a
"finegrined" implementation but I never thought it would be a problem
to wait a bit in exit() in case the slow path hits. I thought it was
more of a problem if exit() runs, the parent then start a new task but
the memory wasn't freed yet.
So I would suggest Hugh to share his view on the down_write/up_write
that may temporarily block mmput (until the next test_exit bailout
point) vs higher latency in reaching exit_mmap for a real exit(2) that
would happen with the proposed change.
Thanks!
Andrea
^ permalink raw reply
* Re: Re: linux-next memleak after IO on dax mountpoint
From: Bart Van Assche @ 2016-06-03 16:48 UTC (permalink / raw)
To: David Drysdale, Xiong Zhou
Cc: Stephen Rothwell, axboe, linux-next, linux-nvdimm,
linux-kernel@vger.kernel.org, Christoph Hellwig
In-Reply-To: <CAHse=S-H_yMhZKNmMZpb41M+o+2tMRyxiUG9wQoemewBXXYTPw@mail.gmail.com>
On 06/02/2016 08:22 AM, David Drysdale wrote:
> FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in
> a different scenario (just normal desktop use). Not done much
> digging so far, but this commit (9082e87bf) looks like it might be
> relevant -- lots of the following:
>
> unreferenced object 0xffff8800c288e900 (size 256):
> comm "dconf-service", pid 1461, jiffies 4294895636 (age 48.028s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 c0 a4 c0 c6 00 88 ff ff ................
> 02 20 00 20 00 00 00 00 11 00 00 00 00 00 00 00 . . ............
> backtrace:
> [<ffffffff81955228>] kmemleak_alloc+0x28/0x50
> [<ffffffff81268bdc>] kmem_cache_alloc+0xfc/0x360
> [<ffffffff81203275>] mempool_alloc_slab+0x15/0x20
> [<ffffffff812030de>] mempool_alloc+0x6e/0x170
> [<ffffffff815014e8>] bio_alloc_bioset+0xb8/0x230
> [<ffffffff81514174>] next_bio+0x24/0x50
> [<ffffffff815145ef>] blkdev_issue_zeroout+0xdf/0x1d0
> [<ffffffff8132ce79>] ext4_issue_zeroout+0x39/0x50
> [<ffffffff81357abf>] ext4_ext_zeroout+0x2f/0x40
> [<ffffffff8135ece0>] ext4_ext_map_blocks+0x1870/0x2190
> [<ffffffff8132cfa1>] ext4_map_blocks+0x111/0x620
> [<ffffffff81330dc8>] ext4_writepages+0x7c8/0x10a0
> [<ffffffff81211851>] do_writepages+0x21/0x30
> [<ffffffff812012ba>] __filemap_fdatawrite_range+0xaa/0xf0
> [<ffffffff812013fd>] filemap_write_and_wait_range+0x2d/0x70
> [<ffffffff81326f6d>] ext4_sync_file+0x18d/0x500
(+Christoph)
With kernel v4.7-rc1 and XFS I see that the blkdev_issue_zeroout() calls
triggered by xfstests make kmemleak complain. I hadn't seen this with
any previous kernel version.
Bart.
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64
From: Pavel Machek @ 2016-06-03 20:57 UTC (permalink / raw)
To: William Breathitt Gray
Cc: gregkh, akpm, x86, linux-next, linux-gpio, linux-iio,
linux-kernel, linux-watchdog, Guenter Roeck, Linus Walleij
In-Reply-To: <d7320150373a0a04ba44b12c5c56d92370853316.1464029828.git.vilhelm.gray@gmail.com>
Hi!
> With the introduction of the ISA_BUS_API Kconfig option, ISA-style
> drivers may be built for X86_64 architectures. This patch changes the
> ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
> allowing them to build for X86_64 as they are expected to.
>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> ---
> drivers/gpio/Kconfig | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 48da857..dc6da77 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
>
> config GPIO_104_DIO_48E
> tristate "ACCES 104-DIO-48E GPIO support"
> - depends on ISA
> + depends on ISA_BUS_API
> select GPIOLIB_IRQCHIP
> help
> Enables GPIO support for the ACCES 104-DIO-48E series
Should we do "depends on PC104" here, because that is what it really
means, and have PC104 enabled when ISA_BUS_API is enabled or something
like that?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64
From: William Breathitt Gray @ 2016-06-03 21:12 UTC (permalink / raw)
To: Pavel Machek
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck,
Linus Walleij
In-Reply-To: <20160603205703.GC11253@amd>
On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
>Hi!
>
>> With the introduction of the ISA_BUS_API Kconfig option, ISA-style
>> drivers may be built for X86_64 architectures. This patch changes the
>> ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
>> allowing them to build for X86_64 as they are expected to.
>>
>> Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: William Breathitt Gray <vilhelm.gray-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> drivers/gpio/Kconfig | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 48da857..dc6da77 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
>>
>> config GPIO_104_DIO_48E
>> tristate "ACCES 104-DIO-48E GPIO support"
>> - depends on ISA
>> + depends on ISA_BUS_API
>> select GPIOLIB_IRQCHIP
>> help
>> Enables GPIO support for the ACCES 104-DIO-48E series
>
>Should we do "depends on PC104" here, because that is what it really
>means, and have PC104 enabled when ISA_BUS_API is enabled or something
>like that?
Since the functionality remains the same, I'm a bit indifferent to that
change; as long as the driver builds for systems in which it's intended
to be used, I'm satisfied.
Differentiating between PC/104 and ISA may be a pointless endeavor
though since both buses appear the same to software. But if it is better
to differentiate between devices as such, then I see little harm in
adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig
option.
William Breathitt Gray
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* mmotm 2016-06-03-15-55 uploaded
From: akpm @ 2016-06-03 22:55 UTC (permalink / raw)
To: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next,
sfr, mhocko, broonie
The mm-of-the-moment snapshot 2016-06-03-15-55 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series
The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE-yyyy-mm-dd-hh-mm-ss. Both contain the string yyyy-mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.
This tree is partially included in linux-next. To see which patches are
included in linux-next, consult the `series' file. Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.
A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko. It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.
A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release. Individual mmotm releases are tagged. The master branch always
points to the latest release, so it's constantly rebasing.
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
To develop on top of mmotm git:
$ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
$ git remote update mmotm
$ git checkout -b topic mmotm/master
<make changes, commit>
$ git send-email mmotm/master.. [...]
To rebase a branch with older patches to a new mmotm release:
$ git remote update mmotm
$ git rebase --onto mmotm/master <topic base> topic
The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree. It is updated more frequently
than mmotm, and is untested.
A git copy of this tree is available at
http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
This mmotm tree contains the following patches against 4.7-rc1:
(patches marked "*" will be included in linux-next)
origin.patch
* mm-fix-overflow-in-vm_map_ram.patch
* kdump-fix-dmesg-gdbmacro-to-work-with-record-based-printk.patch
* mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites.patch
* reiserfs-avoid-uninitialized-variable-use.patch
* memcg-add-rcu-locking-around-css_for_each_descendant_pre-in-memcg_offline_kmem.patch
* z3fold-avoid-modifying-headless-page-and-minor-cleanup.patch
* checkpatch-reduce-git-commit-description-style-false-positives.patch
* mm-page_alloc-prevent-infinite-loop-in-buffered_rmqueue.patch
* mm-oom_reaper-do-not-use-siglock-in-try_oom_reaper.patch
* mm-page_alloc-reset-zonelist-iterator-after-resetting-fair-zone-allocation-policy.patch
* mm-page_alloc-recalculate-the-preferred-zoneref-if-the-context-can-ignore-memory-policies.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
* tree-wide-get-rid-of-__gfp_repeat-for-order-0-allocations-part-i.patch
* x86-get-rid-of-superfluous-__gfp_repeat.patch
* x86-efi-get-rid-of-superfluous-__gfp_repeat.patch
* arm-get-rid-of-superfluous-__gfp_repeat.patch
* arm64-get-rid-of-superfluous-__gfp_repeat.patch
* arc-get-rid-of-superfluous-__gfp_repeat.patch
* mips-get-rid-of-superfluous-__gfp_repeat.patch
* nios2-get-rid-of-superfluous-__gfp_repeat.patch
* parisc-get-rid-of-superfluous-__gfp_repeat.patch
* score-get-rid-of-superfluous-__gfp_repeat.patch
* powerpc-get-rid-of-superfluous-__gfp_repeat.patch
* sparc-get-rid-of-superfluous-__gfp_repeat.patch
* s390-get-rid-of-superfluous-__gfp_repeat.patch
* sh-get-rid-of-superfluous-__gfp_repeat.patch
* tile-get-rid-of-superfluous-__gfp_repeat.patch
* unicore32-get-rid-of-superfluous-__gfp_repeat.patch
* jbd2-get-rid-of-superfluous-__gfp_repeat.patch
* mm-hugetlb-fix-huge-page-reserve-accounting-for-private-mappings.patch
* kasan-change-memory-hot-add-error-messages-to-info-messages.patch
* mmoom_reaper-dont-call-mmput_async-without-atomic_inc_not_zero.patch
* revert-mm-memcontrol-fix-possible-css-ref-leak-on-oom.patch
* thp-broken-page-count-after-commit-aa88b68c.patch
* relay-fix-potential-memory-leak.patch
* mm-introduce-dedicated-wq_mem_reclaim-workqueue-to-do-lru_add_drain_all.patch
* mm-do-not-discard-partial-pages-with-posix_fadv_dontneed.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch
* ocfs2-fix-a-redundant-re-initialization.patch
* ocfs2-insure-dlm-lockspace-is-created-by-kernel-module.patch
* block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
mm.patch
* mm-reorganize-slab-freelist-randomization.patch
* mm-slub-freelist-randomization.patch
* mm-memcontrol-remove-the-useless-parameter-for-mc_handle_swap_pte.patch
* mm-init-fix-zone-boundary-creation.patch
* memory-hotplug-add-move_pfn_range.patch
* memory-hotplug-more-general-validation-of-zone-during-online.patch
* memory-hotplug-use-zone_can_shift-for-sysfs-valid_zones-attribute.patch
* mm-zap-zone_oom_locked.patch
* mm-oom-add-memcg-to-oom_control.patch
* mm-debug-add-vm_warn-which-maps-to-warn.patch
* powerpc-mm-check-for-irq-disabled-only-if-debug_vm-is-enabled.patch
* zram-rename-zstrm-find-release-functions.patch
* zram-switch-to-crypto-compress-api.patch
* zram-use-crypto-api-to-check-alg-availability.patch
* zram-cosmetic-cleanup-documentation.patch
* zram-delete-custom-lzo-lz4.patch
* zram-add-more-compression-algorithms.patch
* zram-drop-gfp_t-from-zcomp_strm_alloc.patch
* mm-use-put_page-to-free-page-instead-of-putback_lru_page.patch
* mm-migrate-support-non-lru-movable-page-migration.patch
* mm-balloon-use-general-non-lru-movable-page-feature.patch
* zsmalloc-keep-max_object-in-size_class.patch
* zsmalloc-use-bit_spin_lock.patch
* zsmalloc-use-accessor.patch
* zsmalloc-factor-page-chain-functionality-out.patch
* zsmalloc-introduce-zspage-structure.patch
* zsmalloc-separate-free_zspage-from-putback_zspage.patch
* zsmalloc-use-freeobj-for-index.patch
* zsmalloc-page-migration-support.patch
* zsmalloc-page-migration-support-fix.patch
* zram-use-__gfp_movable-for-memory-allocation.patch
* mm-compaction-split-freepages-without-holding-the-zone-lock.patch
* mm-page_owner-initialize-page-owner-without-holding-the-zone-lock.patch
* mm-page_owner-copy-last_migrate_reason-in-copy_page_owner.patch
* mm-page_owner-introduce-split_page_owner-and-replace-manual-handling.patch
* tools-vm-page_owner-increase-temporary-buffer-size.patch
* mm-page_owner-use-stackdepot-to-store-stacktrace.patch
* mm-page_alloc-introduce-post-allocation-processing-on-page-allocator.patch
* mm-thp-check-pmd_trans_unstable-after-split_huge_pmd.patch
* mm-hugetlb-simplify-hugetlb-unmap.patch
* mm-change-the-interface-for-__tlb_remove_page.patch
* mm-mmu_gather-track-page-size-with-mmu-gather-and-force-flush-if-page-size-change.patch
* mm-remove-pointless-struct-in-struct-page-definition.patch
* mm-clean-up-non-standard-page-_mapcount-users.patch
* mm-memcontrol-cleanup-kmem-charge-functions.patch
* mm-charge-uncharge-kmemcg-from-generic-page-allocator-paths.patch
* mm-memcontrol-teach-uncharge_list-to-deal-with-kmem-pages.patch
* arch-x86-charge-page-tables-to-kmemcg.patch
* pipe-account-to-kmemcg.patch
* af_unix-charge-buffers-to-kmemcg.patch
* mmoom-remove-unused-argument-from-oom_scan_process_thread.patch
* mm-frontswap-convert-frontswap_enabled-to-static-key.patch
* mm-frontswap-convert-frontswap_enabled-to-static-key-checkpatch-fixes.patch
* mm-add-nr_zsmalloc-to-vmstat.patch
* mm-add-nr_zsmalloc-to-vmstat-fix.patch
* include-linux-memblockh-clean-up-code-for-several-trivial-details.patch
* mm-memblock-if-nr_new-is-0-just-return.patch
* mm-make-optimistic-check-for-swapin-readahead.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-2.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-3.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate-fix.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate-fix-2.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate-fix-3.patch
* mm-vmstat-calculate-particular-vm-event.patch
* mm-thp-avoid-unnecessary-swapin-in-khugepaged.patch
* mm-thp-avoid-unnecessary-swapin-in-khugepaged-fix.patch
* mm-thp-avoid-unnecessary-swapin-in-khugepaged-fix-2.patch
* mm-thp-make-swapin-readahead-under-down_read-of-mmap_sem.patch
* mm-thp-make-swapin-readahead-under-down_read-of-mmap_sem-fix.patch
* mm-thp-make-swapin-readahead-under-down_read-of-mmap_sem-fix-2.patch
* mm-thp-make-swapin-readahead-under-down_read-of-mmap_sem-fix-2-fix.patch
* memstick-dont-allocate-unused-major-for-ms_block.patch
* nvme-dont-allocate-unused-nvme_major.patch
* nvme-dont-allocate-unused-nvme_major-fix.patch
* jump_label-remove-bugh-atomich-dependencies-for-have_jump_label.patch
* powerpc-add-explicit-include-asm-asm-compath-for-jump-label.patch
* s390-add-explicit-linux-stringifyh-for-jump-label.patch
* dynamic_debug-add-jump-label-support.patch
* lib-switch-config_printk_time-to-int.patch
* printk-allow-different-timestamps-for-printktime.patch
* lib-add-crc64-ecma-module.patch
* samples-kprobe-convert-the-printk-to-pr_info-pr_err.patch
* samples-jprobe-convert-the-printk-to-pr_info-pr_err.patch
* samples-kretprobe-convert-the-printk-to-pr_info-pr_err.patch
* samples-kretprobe-fix-the-wrong-type.patch
* fs-befs-move-useless-assignment.patch
* fs-befs-check-silent-flag-before-logging-errors.patch
* fs-befs-remove-useless-pr_err.patch
* fs-befs-remove-useless-befs_error.patch
* fs-befs-remove-useless-pr_err-in-befs_init_inodecache.patch
* nilfs2-hide-function-name-argument-from-nilfs_error.patch
* nilfs2-add-nilfs_msg-message-interface.patch
* nilfs2-embed-a-back-pointer-to-super-block-instance-in-nilfs-object.patch
* nilfs2-reduce-bare-use-of-printk-with-nilfs_msg.patch
* nilfs2-replace-nilfs_warning-with-nilfs_msg.patch
* nilfs2-emit-error-message-when-i-o-error-is-detected.patch
* nilfs2-do-not-use-yield.patch
* nilfs2-refactor-parser-of-snapshot-mount-option.patch
* kexec-return-error-number-directly.patch
* arm-kdump-advertise-boot-aliased-crash-kernel-resource.patch
* arm-kexec-advertise-location-of-bootable-ram.patch
* kexec-dont-invoke-oom-killer-for-control-page-allocation.patch
* kexec-ensure-user-memory-sizes-do-not-wrap.patch
* kexec-ensure-user-memory-sizes-do-not-wrap-fix.patch
* kdump-arrange-for-paddr_vmcoreinfo_note-to-return-phys_addr_t.patch
* kexec-allow-architectures-to-override-boot-mapping.patch
* arm-keystone-dts-add-psci-command-definition.patch
* arm-kexec-fix-kexec-for-keystone-2.patch
* kdump-vmcoreinfo-report-actual-value-of-phys_base.patch
* futex-fix-shared-futex-operations-on-nommu.patch
* dma-mapping-constify-attrs-passed-to-dma_get_attr.patch
* arm-dma-mapping-constify-attrs-passed-to-internal-functions.patch
* arm64-dma-mapping-constify-attrs-passed-to-internal-functions.patch
* w1-remove-need-for-ida-and-use-platform_devid_auto.patch
* w1-add-helper-macro-module_w1_family.patch
* kcov-allow-more-fine-grained-coverage-instrumentation.patch
* ipc-semc-fix-complex_count-vs-simple-op-race.patch
* ipc-msgc-msgsnd-use-freezable-blocking-call.patch
* msgrcv-use-freezable-blocking-call.patch
linux-next.patch
* mm-make-optimistic-check-for-swapin-readahead-fix.patch
* drivers-net-wireless-intel-iwlwifi-dvm-calibc-fix-min-warning.patch
* fpga-zynq-fpga-fix-build-failure.patch
mm-add-strictlimit-knob-v2.patch
make-sure-nobodys-leaking-resources.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
kernel-forkc-export-kernel_thread-to-modules.patch
mutex-subsystem-synchro-test-module.patch
slab-leaks3-default-y.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64
From: Pavel Machek @ 2016-06-04 7:14 UTC (permalink / raw)
To: William Breathitt Gray
Cc: gregkh, akpm, x86, linux-next, linux-gpio, linux-iio,
linux-kernel, linux-watchdog, Guenter Roeck, Linus Walleij
In-Reply-To: <20160603211244.GA6831@sophia>
On Fri 2016-06-03 17:12:44, William Breathitt Gray wrote:
> On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
> >Hi!
> >
> >> With the introduction of the ISA_BUS_API Kconfig option, ISA-style
> >> drivers may be built for X86_64 architectures. This patch changes the
> >> ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
> >> allowing them to build for X86_64 as they are expected to.
> >>
> >> Cc: Guenter Roeck <linux@roeck-us.net>
> >> Cc: Linus Walleij <linus.walleij@linaro.org>
> >> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> >> ---
> >> drivers/gpio/Kconfig | 8 ++++----
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index 48da857..dc6da77 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
> >>
> >> config GPIO_104_DIO_48E
> >> tristate "ACCES 104-DIO-48E GPIO support"
> >> - depends on ISA
> >> + depends on ISA_BUS_API
> >> select GPIOLIB_IRQCHIP
> >> help
> >> Enables GPIO support for the ACCES 104-DIO-48E series
> >
> >Should we do "depends on PC104" here, because that is what it really
> >means, and have PC104 enabled when ISA_BUS_API is enabled or something
> >like that?
>
> Since the functionality remains the same, I'm a bit indifferent to that
> change; as long as the driver builds for systems in which it's intended
> to be used, I'm satisfied.
>
> Differentiating between PC/104 and ISA may be a pointless endeavor
> though since both buses appear the same to software. But if it is better
> to differentiate between devices as such, then I see little harm in
> adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig
> option.
Well, they are same to the software, but not at the hardware. If I
have a development board that has PC104 (but not isa), I'd like to see
prompts for PC104 extensions, not for isa. If PC105 comes out, still
ISA compatible, I will want to see prompts for PC104 boards or PC105
boards, but not neccessarily both...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup
From: Sergey Senozhatsky @ 2016-06-04 7:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrea Arcangeli, Sergey Senozhatsky,
Andrew Morton, Vlastimil Babka, Kirill A. Shutemov,
Stephen Rothwell, linux-mm, linux-next, linux-kernel
In-Reply-To: <20160603134934.GJ20676@dhcp22.suse.cz>
Hello,
On (06/03/16 15:49), Michal Hocko wrote:
> __khugepaged_exit is called during the final __mmput and it employs a
> complex synchronization dances to make sure it doesn't race with the
> khugepaged which might be scanning this mm at the same time. This is
> all caused by the fact that khugepaged doesn't pin mm_users. Things
> would simplify considerably if we simply check the mm at
> khugepaged_scan_mm_slot and if mm_users was already 0 then we know it
> is dead and we can unhash the mm_slot and move on to another one. This
> will also guarantee that __khugepaged_exit cannot race with khugepaged
> and so we can free up the slot if it is still hashed.
>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
with this patch and
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-make-swapin-readahead-under-down_read-of-mmap_sem-fix-2.patch
I saw no problems during my tests (well, may be didn't test hard
enough).
-ss
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio: Allow PC/104 devices on X86_64
From: William Breathitt Gray @ 2016-06-04 11:12 UTC (permalink / raw)
To: Pavel Machek
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Guenter Roeck,
Linus Walleij
In-Reply-To: <20160604071408.GA22045@amd>
On Sat, Jun 04, 2016 at 09:14:08AM +0200, Pavel Machek wrote:
>On Fri 2016-06-03 17:12:44, William Breathitt Gray wrote:
>> On Fri, Jun 03, 2016 at 10:57:03PM +0200, Pavel Machek wrote:
>> >Should we do "depends on PC104" here, because that is what it really
>> >means, and have PC104 enabled when ISA_BUS_API is enabled or something
>> >like that?
>>
>> Since the functionality remains the same, I'm a bit indifferent to that
>> change; as long as the driver builds for systems in which it's intended
>> to be used, I'm satisfied.
>>
>> Differentiating between PC/104 and ISA may be a pointless endeavor
>> though since both buses appear the same to software. But if it is better
>> to differentiate between devices as such, then I see little harm in
>> adding a PC104 Kconfig option which follows the ISA_BUS_API Kconfig
>> option.
>
>Well, they are same to the software, but not at the hardware. If I
>have a development board that has PC104 (but not isa), I'd like to see
>prompts for PC104 extensions, not for isa. If PC105 comes out, still
>ISA compatible, I will want to see prompts for PC104 boards or PC105
>boards, but not neccessarily both...
I think I see the merit of a prompt for PC104 devices. I've encountered
a use case recently which I'm curious about in this scenario. Given the
compatibility with ISA, manufacturers may occasionally develop variants
of existing ISA devices by duplicating the firmware on a PC/104 form
factor.
I'm working on an IIO DAC driver for the Measurement Computing CIO-DAC
family (CIO-DAC08, CIO-DAC16, and PC104-DAC06); while not a GPIO driver,
I believe it can serve as a decent example. Interestingly, while the
CIO-DAC08 and CIO-DAC16 are true ISA devices, the PC104-DAC06 is a
PC/104 variant compatible with the others in the family. The IIO DAC
driver works just as well with the PC104-DAC06, as it does with the true
ISA devices in the family.
What would the Kconfig depends line look in this scenario? I imagine
simply "depends on PC104" would be inappropriate since there are a
number of true ISA devices supported by the driver, but "depends on
ISA_BUS_API || PC104" seems somewhat redundant when the PC104 Kconfig
option implies ISA_BUS_API. This situation isn't that much of an issue
overall, but I anticipate encountering it occassionally as I develop
future PC/104 drivers.
William Breathitt Gray
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox