* cron job: media_tree daily build: ERRORS
From: Hans Verkuil @ 2016-11-09 4:40 UTC (permalink / raw)
To: linux-media
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Wed Nov 9 05:00:18 CET 2016
media-tree git hash: bd676c0c04ec94bd830b9192e2c33f2c4532278d
media_build git hash: dac8db4dd7fa3cc87715cb19ace554e080690b39
v4l-utils git hash: 788b674f3827607c09c31be11c91638f816aa6ae
gcc version: i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware: x86_64
host os: 4.7.0-164
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9-rc1-i686: WARNINGS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2
The Media Infrastructure API from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/index.html
^ permalink raw reply
* linux-next: Tree for Nov 9
From: Stephen Rothwell @ 2016-11-09 4:40 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Hi all,
Changes since 20161108:
The drm-misc tree gained a build failure, so I used the version from
next-20161108.
The sound-asoc tree still had its build failure, so I used the version
from next-20161028.
The scsi-mkp tree gained conflicts against the block and scsi trees.
The rtc tree lost its build failure.
The akpm tree gained a conflict against the jc_docs tree.
Non-merge commits (relative to Linus' tree): 4645
5193 files changed, 293049 insertions(+), 97254 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 246 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 (e3a00f68e426 Merge tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (4efca4ed05cb kbuild: modversions for EXPORT_SYMBOL() for asm)
Merging arc-current/for-curr (0a0a047def15 ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core)
Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls)
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (fb479e44a9e2 powerpc/64s: relocation, register save fixes for system reset interrupt)
Merging sparc/master (0c183d92b20b Merge tag 'spi-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi)
Merging net/master (fd0285a39b1c fib_trie: Correct /proc/net/route off by one error)
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti interface is removed)
Merging netfilter/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if the user doesn't specify it)
Merging ipvs/master (b73b8a1ba598 netfilter: nft_dup: do not use sreg_dev if the user doesn't specify it)
Merging wireless-drivers/master (d3532ea6ce4e brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap)
Merging mac80211/master (269ebce4531b xen-netfront: cast grant table reference first to type int)
Merging sound-current/for-linus (6809cd682b82 ALSA: info: Return error for invalid read/write)
Merging pci-current/for-linus (16d917b130d7 PCI: Don't attempt to claim shadow copies of ROM)
Merging driver-core.current/driver-core-linus (bdacd1b426db driver core: fix smatch warning on dev->bus check)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (7309aa847ead cdc-acm: fix uninitialized variable)
Merging usb-gadget-fixes/fixes (fd9afd3cbe40 usb: gadget: u_ether: remove interrupt throttling)
Merging usb-serial-fixes/usb-linus (9bfef729a3d1 USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad)
Merging usb-chipidea-fixes/ci-for-usb-stable (991d5add50a5 usb: chipidea: host: fix NULL ptr dereference during shutdown)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking unknown bit of pmu)
Merging staging.current/staging-linus (68fae2f3df45 staging: nvec: remove managed resource from PS2 driver)
Merging char-misc.current/char-misc-linus (f6b2db084b65 vmbus: make sysfs names consistent with PCI)
Merging input-current/for-linus (324ae0958cab Input: psmouse - cleanup Focaltech code)
Merging crypto-current/master (6d4952d9d9d4 hwrng: core - Don't use a stack buffer in add_early_randomness())
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.)
Merging vfio-fixes/for-linus (05692d7005a3 vfio/pci: Fix integer overflows, bitmask check)
Merging kselftest-fixes/fixes (1001354ca341 Linux 4.9-rc1)
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 (51717929d835 mfd: intel_soc_pmic_bxtwc: Fix usbc interrupt)
Merging drm-intel-fixes/for-linux-next-fixes (54905ab5fe7a drm/i915: Limit Valleyview and earlier to only using mappable scanout)
Merging kbuild/for-next (fbcbee25745d Merge branches 'kbuild/kbuild' and 'kbuild/misc' into kbuild/for-next)
Merging asm-generic/master (de4be6b87b6b asm-generic: page.h: fix comment typo)
CONFLICT (content): Merge conflict in include/asm-generic/percpu.h
Merging arc/for-next (1001354ca341 Linux 4.9-rc1)
Merging arm/for-next (f167e1f561ae Merge branches 'fixes', 'misc', 'sa1100-base' and 'syscalls' into for-next)
Merging arm-perf/for-next/perf (1001354ca341 Linux 4.9-rc1)
Merging arm-soc/for-next (1e1ce567d3a6 ARM: SoC: Document merges)
Merging pinctrl/for-next (71891d6cdb66 Merge branch 'devel' into for-next)
Merging amlogic/for-next (8c8a1078e8a3 Merge branch 'v4.10/defconfig' into tmp/aml-rebuild)
Merging at91/at91-next (0f59c948faed Merge tag 'at91-ab-4.8-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into at91-next)
Merging bcm2835/for-next (391823c4373c Merge branch anholt/bcm2835-dt-64-next into for-next)
Merging berlin/berlin/for-next (5153351425c9 Merge branch 'berlin/dt' into berlin/for-next)
Merging cortex-m/for-next (f719a0d6a854 ARM: efm32: switch to vendor,device compatible strings)
Merging imx-mxs/for-next (e6e1aa531aa6 Merge branch 'zte/dt64' into for-next)
Merging keystone/next (fb2a68db621a Merge branch 'for_4.9/keystone_dts' into next)
Merging mvebu/for-next (2fb556b700c6 Merge branch 'mvebu/dt64-fix' into mvebu/for-next)
Merging omap/for-next (6e32e0eda2c9 Merge branch 'omap-for-v4.10/cpuidle' into for-next)
Merging omap-pending/for-next (c20c8f750d9f ARM: OMAP2+: hwmod: fix _idle() hwmod state sanity check sequence)
Merging qcom/for-next (c49806e0fa1e Merge branch 'arm64-for-5.0' into all-for-5.0)
Merging renesas/next (d31c50e214d9 Merge branch 'dt-for-v4.10' into next)
Merging rockchip/for-next (f9e4dfbd058c Merge branch 'v4.10-armsoc/dts32' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (1a695a905c18 Linux 4.7-rc1)
Merging samsung-krzk/for-next (b33c7bb9d59c Merge branch 'next/dt' into for-next)
Merging tegra/for-next (817d74019bab Merge branch for-4.10/arm/defconfig into for-next)
Merging arm64/for-next/core (db68f3e7594a arm64: tlbflush.h: add __tlbi() macro)
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 (c78874f116be tty: serial: make crisv10 explicitly non-modular)
Merging h8300/h8300-next (58c57526711f h8300: Add missing include file to asm/io.h)
Merging hexagon/linux-next (02cc2ccfe771 Revert "Hexagon: fix signal.c compile error")
Merging ia64/next (fbb0e4da96f4 ia64: salinfo: use a waitqueue instead a sema down/up combo)
Merging m68k/for-next (25ba49085c4f m68k/atari: Use seq_puts() in atari_get_hardware_list())
Merging m68knommu/for-next (98a87d21afd5 m68knommu: AMCORE board, add iMX i2c support)
Merging metag/for-next (f5d163aad31e metag: perf: fix build on Meta1)
Merging microblaze/next (52e9e6e05617 microblaze: pci: export isa_io_base to fix link errors)
Merging mips/mips-for-linux-next (3f56647d2d68 Merge branch '4.9-fixes' into mips-for-linux-next)
Merging nios2/for-next (476080a79367 nios2: use of_property_read_bool)
Merging parisc-hd/for-next (c8d2bc9bc39e Linux 4.8)
Merging powerpc/next (08bf75ba852e powerpc/mm/hash64: Fix might_have_hea() check)
Merging fsl/next (e0b80f00bb96 arch/powerpc: Add CONFIG_FSL_DPAA to corenetXX_smp_defconfig)
Merging mpc5xxx/next (39e69f55f857 powerpc: Introduce the use of the managed version of kzalloc)
Merging s390/features (847e0700121b s390: remove unneeded dependency for gen_facilities)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging sh/for-next (e61c10e468a4 sh: add device tree source for J2 FPGA on Mimas v2 board)
Merging tile/master (bf55d575234b tile: migrate exception table users off module.h and onto extable.h)
Merging uml/linux-next (dad223284407 um: Don't discard .text.exit section)
Merging unicore32/unicore32 (1ace5d1e3d4b unicore32-oldabi: add oldabi syscall interface)
Merging xtensa/xtensa-for-next (d4eccafcaf33 xtensa: clean up printk usage for boot/crash logging)
Merging befs/for-next (3c8a965ad630 befs: remove signatures from comments)
Merging btrfs/next (8b8b08cbfb90 Btrfs: fix delalloc accounting after copy_from_user faults)
Merging btrfs-kdave/for-next (2a782f537899 Merge branch 'for-next-next-4.9-20161108' into for-next-20161108)
Merging ceph/master (5130ccea7cf4 ceph: fix non static symbol warning)
Merging cifs/for-next (faad81c4f581 CIFS: iterate over posix acl xattr entry correctly in ACL_to_cifs_posix())
Merging configfs/for-next (42857cf512cb configfs: Return -EFBIG from configfs_write_bin_file.)
Merging ecryptfs/next (be280b25c328 ecryptfs: remove private bin2hex implementation)
Merging ext3/for_next (e952813e210b ext2: avoid bogus -Wmaybe-uninitialized warning)
Merging ext4/dev (d74f3d25289a ext4: add missing KERN_CONT to a few more debugging uses)
Merging f2fs/dev (751e1d334e73 f2fs: return directly if block has been removed from the victim)
Merging freevxfs/for-next (bf1bb4b460c8 freevxfs: update Kconfig information)
Merging fscache/fscache (d52bd54db8be Merge branch 'akpm' (patches from Andrew))
Merging fuse/for-next (0ce267ff95a0 fuse: fix root dentry initialization)
Merging gfs2/for-next (a3443cda5588 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging jfs/jfs-next (240c5185c52d jfs: Simplify code)
Merging nfs/linux-next (14155cafeadd btrfs: assign error values to the correct bio structs)
Merging nfsd/nfsd-next (56094edd1797 sunrpc: GFP_KERNEL should be GFP_NOFS in crypto code)
Merging orangefs/for-next (dc0336214eb0 orangefs: clean up debugfs)
Merging overlayfs/overlayfs-next (b454c10e53ca ovl: split super.c)
Merging v9fs/for-next (a333e4bf2556 fs/9p: use fscache mutex rather than spinlock)
Merging ubifs/linux-next (a00052a296e5 ubifs: Fix regression in ubifs_readdir())
Merging xfs/for-next (84716639acc3 Merge branch 'xfs-4.10-misc-fixes-1' into for-next)
Merging file-locks/linux-next (07d9a380680d Linux 4.9-rc2)
Merging vfs/for-next (b26b5ef5ec7e Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging vfs-jk/vfs (030b533c4fd4 fs: Avoid premature clearing of capabilities)
Merging vfs-miklos/next (c8d2bc9bc39e Linux 4.8)
Merging pci/next (1001354ca341 Linux 4.9-rc1)
Merging pstore/for-next/pstore (07d9a380680d Linux 4.9-rc2)
Merging hid/for-next (003ba7361116 Merge branch 'for-4.10/upstream' into for-next)
Merging i2c/i2c/for-next (bc33b0ca11e3 Linux 4.9-rc4)
Merging jdelvare-hwmon/master (08d27eb20666 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging dmi/master (c8d2bc9bc39e Linux 4.8)
Merging hwmon-staging/hwmon-next (c2d95c252f65 hwmon: (adm1275) Enable adm1278 VOUT sampling)
Merging jc_docs/docs-next (d55003d86e0c USB: fix typo in documentation)
Merging v4l-dvb/master (778de0140232 Merge branch 'v4l_for_linus' into to_next)
Merging pm/linux-next (d6555d53674f Merge branch 'pm-cpufreq' into linux-next)
Merging idle/next (f55532a0c0b8 Linux 4.6-rc1)
Merging thermal/next (3105f234e0ab thermal/powerclamp: correct cpu support check)
Merging thermal-soc/next (c6935931c189 Linux 4.8-rc5)
Merging ieee1394/for-next (e9300a4b7bba firewire: net: fix fragmented datagram_size off-by-one)
Merging dlm/next (aa9f1012858b dlm: don't specify WQ_UNBOUND for the ast callback workqueue)
Merging swiotlb/linux-next (386744425e35 swiotlb: Make linux/swiotlb.h standalone includible)
Merging net-next/master (f5f99309fa74 sock: do not set sk_err in sock_dequeue_err_skb)
CONFLICT (content): Merge conflict in net/netlink/genetlink.c
Merging ipsec-next/master (2258d927a691 xfrm: remove unused helper)
Merging netfilter-next/master (08733a0cb7de netfilter: handle NF_REPEAT from nf_conntrack_in())
Merging ipvs-next/master (75a608d8d3b2 ipvs: Decrement ttl)
Merging wireless-drivers-next/master (3f8247c8c480 Merge tag 'iwlwifi-next-for-kalle-2016-10-25-2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next)
Merging bluetooth/master (52069883235a Bluetooth: hci_qca: Use setup_timer Kernel API instead of init_timer)
Merging mac80211-next/master (17197236d62c enic: set skb->hash type properly)
Merging rdma/for-next (e37a79e5d4ca net/mlx5e: Add tc support for FWD rule with counter)
Merging rdma-leon/rdma-next (a909d3e63699 Linux 4.9-rc3)
Merging rdma-leon-test/testing/rdma-next (33b4f7c41bae Merge branch 'testing/queue-next' into testing/rdma-next)
CONFLICT (content): Merge conflict in drivers/infiniband/core/roce_gid_mgmt.c
Merging mtd/master (0e2ce9d3fcba Merge tag 'nand/fixes-for-4.9-rc3' of github.com:linux-nand/linux)
Merging l2-mtd/master (64ad46379fcf mtd: bcm47xxsflash: use uncached MMIO access for BCM53573)
Merging nand/nand/next (83f48f80de8a mtd: nand: socrates: use nand_scan() for nand_scan_ident/tail() combo)
Merging crypto/master (89277a7d0ed4 crypto: cryptd - Remove unused but set variable 'tfm')
Merging drm/drm-next (afdd548f742c Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-next)
Merging drm-panel/drm/panel/for-next (c96f566273bf drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel)
Merging drm-intel/for-linux-next (71d5895aac0c drm/i915: avoid harmless empty-body warning)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c
Merging drm-tegra/drm/tegra/for-next (cc09cb6da9b0 drm/tegra: gem: Remove some dead code)
Merging drm-misc/topic/drm-misc (06d9f56f1d9a drm/msm: module param to dump state on error irq)
$ git reset --hard HEAD^
Merging next-20161108 version of drm-misc
Merging drm-exynos/exynos-drm/for-next (7d1e04231461 Merge tag 'usercopy-v4.8-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging drm-msm/msm-next (7a3bcc0a8e2a drm/msm: bump kernel api version for explicit fencing)
Merging hdlcd/for-upstream/hdlcd (523d939ef98f Linux 4.7)
Merging mali-dp/for-upstream/mali-dp (e64053f05eb9 drm: mali-dp: Clear CVAL when leaving config mode)
Merging sunxi/sunxi/for-next (bc5952be2d42 Merge branch 'sunxi/dt64-for-4.10' into sunxi/for-next)
Merging kspp/for-next/kspp (07d9a380680d Linux 4.9-rc2)
Merging kconfig/for-next (5bcba792bb30 localmodconfig: Fix whitespace repeat count after "tristate")
Merging regmap/for-next (74e3368de87d Merge remote-tracking branches 'regmap/fix/header' and 'regmap/fix/macro' into regmap-linus)
Merging sound/for-next (4ce8e6a51abf ALSA: hda - Fix typo)
Merging sound-asoc/for-next (2fd876810ed6 Merge remote-tracking branch 'asoc/topic/wm9713' into asoc-next)
$ git reset --hard HEAD^
Merging next-20161028 version of sound-asoc
CONFLICT (content): Merge conflict in sound/soc/samsung/s3c24xx-i2s.c
[master 76d515f08f6e] next-20161028/sound-asoc
Merging modules/modules-next (a467a672cf09 MAINTAINERS: Begin module maintainer transition)
Merging input/next (8dd5e0b364e5 Input: da9063 - fix module autoload when registered via OF)
Merging block/for-next (abb87e497e06 Merge branch 'for-4.10/block' into for-next)
Merging lightnvm/for-next (b759d3ddb52f lightnvm: rrpc: split bios of size > 256kb)
Merging device-mapper/for-next (5c5eb3db2893 dm cache metadata: DM_CACHE_FEATURE_INCOMPAT_SEP_DIRTY_BITS)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc/next (22c55ad7026c mmc: sh_mobile_sdhi: Add r7s72100 support)
Merging kgdb/kgdb-next (7a6653fca500 kdb: Fix handling of kallsyms_symbol_next() return value)
Merging md/for-next (85c9ccd4f026 md/bitmap: Don't write bitmap while earlier writes might be in-flight)
Merging mfd/for-mfd-next (77f298a18ff8 mfd: sun4i-gpadc: Fix 'cast from pointer to integer of different size' warning)
Merging backlight/for-backlight-next (0c9501f823a4 backlight: pwm_bl: Handle gpio that can sleep)
Merging battery/for-next (44fccac4ff17 power: supply: lp8788: remove an unneeded NULL check)
Merging omap_dss2/for-next (c456a2f30de5 video: smscufx: remove unused variable)
Merging regulator/for-next (121c4e997cee Merge remote-tracking branches 'regulator/topic/arizona', 'regulator/topic/fixed' and 'regulator/topic/tps6507x' into regulator-next)
Merging security/next (07d9a380680d Linux 4.9-rc2)
Merging integrity/next (56078b570983 module: Fully remove the kernel_module_from_file hook)
Merging keys/keys-next (ed51e44e914c Merge branch 'keys-asym-keyctl' into keys-next)
Merging selinux/next (07d9a380680d Linux 4.9-rc2)
Merging tpmdd/next (7839a496de6d char: tpm: fix kerneldoc tpm2_unseal_trusted name typo)
Merging watchdog/master (39487f6688a5 watchdog: imx2_wdt: add pretimeout function support)
Merging iommu/next (bea64033dd7b iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path)
Merging dwmw2-iommu/master (5b3c5c539eac iommu/vt-d: Fix PASID table allocation)
Merging vfio/next (61771468e0a5 vfio_pci: use pci_alloc_irq_vectors)
Merging trivial/for-next (380cc42d5a6c nvme: add missing \n to end of dev_warn message)
Merging audit/next (b4eb4f7f1a97 audit: less stack usage for /proc/*/loginuid)
Merging devicetree/for-next (87e5fc99b028 DT: irqchip: renesas-irqc: document R8A7743/5 support)
Merging mailbox/mailbox-for-next (a649244de727 dt-bindings: mailbox: Add Amlogic Meson MHU Bindings)
Merging spi/for-next (3ab554413ec4 Merge remote-tracking branches 'spi/topic/omap', 'spi/topic/rspi', 'spi/topic/spidev' and 'spi/topic/sunxi' into spi-next)
Merging tip/auto-latest (7f5aea355653 Merge branch 'x86/urgent')
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_shrinker.c
Merging clockevents/clockevents/next (1d661bf5327a clocksource/drivers/time-armada-370-xp: Fix return value check)
Merging edac/linux_next (12f0721c5a70 sb_edac: correctly fetch DIMM width on Ivy Bridge and Haswell)
Merging edac-amd/for-next (90e493d7d51c EDAC, altera: Disable IRQs while injecting SDRAM errors)
Merging irqchip/irqchip/for-next (0ccb54a7dba0 Merge branch 'irqchip/core' into irqchip/for-next)
Merging ftrace/for-next (f971cc9aabc2 tracing: Have max_latency be defined for HWLAT_TRACER as well)
Merging rcu/rcu/next (d011087a0402 torture: Update RCU test scenario documentation)
Merging kvm/linux-next (ad3610919e6f kvm: x86: avoid atomic operations on APICv vmentry)
Merging kvm-arm/next (0099b7701f52 KVM: arm/arm64: vgic: Don't flush/sync without a working vgic)
Merging kvm-mips/next (07d9a380680d Linux 4.9-rc2)
Merging kvm-ppc/kvm-ppc-next (c63517c2e381 KVM: PPC: Book3S: correct width in XER handling)
Merging kvm-ppc-paulus/kvm-ppc-next (fa73c3b25bd8 KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register)
Merging kvms390/next (b0eb91ae630a Merge remote-tracking branch 'kvms390/s390forkvm' into kvms390next)
Merging xen-tip/linux-next (999c9af9e3a2 xen: make use of xenbus_read_unsigned() in xenbus)
Merging percpu/for-next (3ca45a46f8af percpu: ensure the requested alignment is power of two)
Merging workqueues/for-next (8bc4a0445596 Merge branch 'for-4.9' into for-4.10)
Merging drivers-x86/for-next (401df5ace9d6 intel_pmc_core: Add KBL CPUID support)
Merging chrome-platform/for-next (31b764171cb5 Revert "platform/chrome: chromeos_laptop: Add Leon Touch")
Merging hsi/for-next (7ac5d7b1a125 HSI: hsi_char.h: use __u32 from linux/types.h)
Merging leds/for-next (883d32ce3385 leds: core: Add support for poll()ing the sysfs brightness attr for changes.)
Merging ipmi/for-next (6f48ef64097b ipmi: Pick up slave address from SMBIOS on an ACPI device)
Merging driver-core/driver-core-next (baa8809f6097 PM / runtime: Optimize the use of device links)
Merging tty/tty-next (5131dcd78108 Merge 4.9-rc3 into tty-next)
CONFLICT (modify/delete): Documentation/VGA-softcursor.txt deleted in HEAD and modified in tty/tty-next. Version tty/tty-next of Documentation/VGA-softcursor.txt left in tree.
$ git rm -f Documentation/VGA-softcursor.txt
Merging usb/usb-next (11f107f708fd usb: storage: drop freezer.h usage)
Merging usb-gadget/next (a909d3e63699 Linux 4.9-rc3)
Merging usb-serial/usb-next (a98b69002a16 USB: serial: ch341: add debug output for chip version)
Merging usb-chipidea-next/ci-for-usb-next (c6900310b6cc usb: chipidea: imx: Disable internal 60Mhz clock with ULPI PHY)
Merging phy-next/next (7809cd2ce6ab phy: meson: add USB2 PHY support for Meson8b and GXBB)
Merging staging/staging-next (993403b97981 staging: lustre: fixed shadowed variable in socklnd_cb.c)
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211netdev.c
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/i2c/trivial-devices.txt
Merging char-misc/char-misc-next (3372592a140d Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host)
Merging extcon/extcon-next (56182a830cbf extcon: usb-gpio: Add VBUS detection support)
Merging slave-dma/next (8d197083fd9f Merge branch 'topic/qcom' into next)
Merging cgroup/for-next (4221d2ce6e57 Merge branch 'for-4.9' into for-next)
Merging scsi/for-next (ce769f7be3c4 Merge branch 'misc' into for-next)
CONFLICT (content): Merge conflict in drivers/scsi/ufs/ufshcd.c
Merging scsi-mkp/for-next (4861ee15f2b7 scsi: ufs: Use the resource-managed function to add devfreq device)
CONFLICT (content): Merge conflict in drivers/scsi/ufs/ufshcd.c
CONFLICT (content): Merge conflict in drivers/scsi/ufs/ufs-qcom.c
Merging target-updates/for-next (291e3e51a34d target: fix spelling mistake: "limitiation" -> "limitation")
Merging target-merge/for-next-merge (2994a7518317 cxgb4: update Kconfig and Makefile)
Merging libata/for-next (a9d72eeb1308 Merge branch 'for-4.9-fixes' into for-next)
CONFLICT (content): Merge conflict in block/blk-core.c
Merging binfmt_misc/for-next (4af75df6a410 binfmt_misc: add F option description to documentation)
Merging vhost/linux-next (75bfa81bf089 virtio_ring: mark vring_dma_dev inline)
Merging remoteproc/for-next (7a6271a80cae remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias)
CONFLICT (content): Merge conflict in drivers/remoteproc/remoteproc_core.c
Merging rpmsg/for-next (9641800e7ea2 Merge branches 'hwspinlock-next', 'rpmsg-next' and 'rproc-next' into for-next)
Merging gpio/for-next (b38b2dfcf2a3 Merge branch 'devel' into for-next)
Merging dma-mapping/dma-mapping-next (1001354ca341 Linux 4.9-rc1)
Merging pwm/for-next (dc8e6e1e8f2d Merge branch 'for-4.9/drivers' into for-next)
Merging dma-buf/for-next (194cad44c4e1 dma-buf/sync_file: improve Kconfig description for Sync Files)
CONFLICT (content): Merge conflict in drivers/dma-buf/Kconfig
Merging userns/for-next (2e41414828bb mm: Add a user_ns owner to mm_struct and fix ptrace permission checks)
Merging ktest/for-next (2dcd0af568b0 Linux 4.6)
Merging clk/clk-next (172ff5a22d4c clk: ti: make clk-dra7-atl explicitly non-modular)
Merging random/dev (59b8d4f1f5d2 random: use for_each_online_node() to iterate over NUMA nodes)
Merging aio/master (b562e44f507e Linux 4.5)
Merging kselftest/next (1001354ca341 Linux 4.9-rc1)
Merging y2038/y2038 (549eb7b22e24 AFS: Correctly use 64-bit time for UUID)
CONFLICT (content): Merge conflict in fs/afs/main.c
Merging luto-misc/next (2dcd0af568b0 Linux 4.6)
Merging borntraeger/linux-next (dcc37f904443 processor.h: remove cpu_relax_lowlatency)
Merging livepatching/for-next (2992ef29ae01 livepatch/module: make TAINT_LIVEPATCH module-specific)
Merging coresight/next (7f73c6f7d72a coresight: Add support for ARM Coresight STM-500)
Merging rtc/rtc-next (72d3d79f8da9 rtc: fix typos in Kconfig)
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (52e73eb2872c device-dax: fix percpu_ref_exit ordering)
Merging dax-misc/dax-misc (4d9a2c874667 dax: Remove i_mmap_lock protection)
Merging akpm-current/current (1b399f45323f ipc/shm.c: coding style fixes)
$ git checkout -b akpm remotes/origin/akpm/master
Applying: drivers/net/wireless/intel/iwlwifi/dvm/calib.c: simplfy min() expression
Applying: kexec_file: allow arch-specific memory walking for kexec_add_buffer
Applying: kexec_file: change kexec_add_buffer to take kexec_buf as argument
Applying: kexec_file: factor out kexec_locate_mem_hole from kexec_add_buffer
Applying: powerpc: change places using CONFIG_KEXEC to use CONFIG_KEXEC_CORE instead
Applying: powerpc: factor out relocation code in module_64.c
Applying: powerpc: implement kexec_file_load
Applying: powerpc: add functions to read ELF files of any endianness
Applying: powerpc: add support for loading ELF kernels with kexec_file_load
Applying: powerpc: add purgatory for kexec_file_load implementation
Applying: powerpc: enable CONFIG_KEXEC_FILE in powerpc server defconfigs
Applying: powerpc: ima: get the kexec buffer passed by the previous kernel
Applying: ima: on soft reboot, restore the measurement list
Applying: ima: permit duplicate measurement list entries
Applying: ima: maintain memory size needed for serializing the measurement list
Applying: powerpc: ima: send the kexec buffer to the next kernel
Applying: ima: on soft reboot, save the measurement list
Applying: ima: store the builtin/custom template definitions in a list
Applying: ima: support restoring multiple template formats
Applying: ima: define a canonical binary_runtime_measurements list format
CONFLICT (content): Merge conflict in Documentation/admin-guide/kernel-parameters.rst
Applying: ima: platform-independent hash value
Applying: ktest.pl: fix english
Applying: kernel/watchdog.c: move shared definitions to nmi.h
Applying: kernel/watchdog.c: move hardlockup detector to separate file
Applying: sparc: implement watchdog_nmi_enable and watchdog_nmi_disable
Merging akpm/master (96fdefe1fe93 sparc: implement watchdog_nmi_enable and watchdog_nmi_disable)
^ permalink raw reply
* [PATCH v3] btrfs-progs: send-test: add checking of clone-src option
From: Tsutomu Itoh @ 2016-11-09 4:44 UTC (permalink / raw)
To: dsterba, quwenruo; +Cc: linux-btrfs
In-Reply-To: <201611040835.AA00012@WIN-5MHF4RKU941.jp.fujitsu.com>
Sending stream size of clone-src(-c) option is checked.
Fixed by "btrfs-progs: send: fix handling of -c option".
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
V2: old sending stream image is used
V3: image file has been compressed by gzip
---
.../016-send-clone-src/send-stream-v4.8.2.img.gz | Bin 0 -> 11826 bytes
tests/misc-tests/016-send-clone-src/test.sh | 50 +++++++++++++++++++++
2 files changed, 50 insertions(+)
create mode 100644 tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img.gz
create mode 100755 tests/misc-tests/016-send-clone-src/test.sh
diff --git a/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img.gz b/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img.gz
new file mode 100644
index 0000000000000000000000000000000000000000..f49c5cba1a8307f99732530ab8613f4a22902b9d
GIT binary patch
literal 11826
zcmeI2ZBSEJ8plz$(rwqq-EN!dR!O%VWvxh5gzzS5*KJv)lBuZZfP_^MD@uR}F_7d+
zU1eM>8KH^_N!r!QD3T~xUJQ9@sUlSpkU~Tt;VlG62!xP?yxqGuAtku(EKTyQ17Da6
zcb+-tx&L#X|MNQsmH+a~*ABnC$7=~ODfQqw;_-~6e;iwvwaGu&f203r$CACqx{tN2
zQhew$oD;FBXZ-OV`cKJ&=MU$8_{#lft$RYP1^b(B-opF&vgI*Z7r*>nl<3F4O`$C&
z;d_sgeiTmp-fzdr^dtKo`L{0hjrsV}&d#NOEe*cI-4S$ad2sdVHRu$=SGPB?y*hSR
zELr52A!P<UQEqJqg*zFRTJ}x0He6AMGxYQ*4BFAWgf><fQT?^VZ@dnjSJ?e+#A^yP
z$dat|54lX_P<0K-q8>neO8XJ%FR^l+Y`VojwFC&JmO*BYWr{=@(hGuoq8W_%<41U)
zh!mdQR)WpeM#-oqaI_$jog)ua>WWHqRWU<#kb(!1_R^zo2?S~5%Shv#da#WZl4%iA
z3>Ac<B>xiDC0ZNM%qm@X;|b?XQq3hi7o7Y%AM(ZW{o@q5>JB8MZtU^8$c}+6dHxAg
zQ>Ld)Xnwx}98T=N*}P^b--wiqmPlB!@*9HbQ;0xi8$M%f6aUDcij&dbLMJ1%1<(W?
zG|B++BiZo=4W6rKhXFazqJ5@5BI^rgL|U~qt~M0v-zC#v5T(lD+^Fu_h(mQmT_0w}
z%PYdt&Wu)81sa*YK4fL?#2ZTC>E_qD2eRK0fYlh<^as7YMDnNBo-#T<NLF{0rnzq^
zLO~MLvv7Tvs2hG<0e+4ons4B!>csv|WE(XdeSM_?WhGb`V#W!*|GiV=hcBL6<mJ-O
zNoeWa13NON6$tCjtruv4eu{kdR>nExlB(p7T?*vob$j2~r7tZH$2VsZosmkhn_fE9
zRNH>W)nKg!Tbs(%Yk~M3-{6-$GX6Vdhi^_^nb7a8nrF*hj1}~3!<srsUpDS%6NQ}8
z8hAqz6?xqjYp<)Z{6A~FHrRs-0}ndqcn*$rbn~+#TU;F1)5CBqImgt1^`9MBkv7u(
zNs?7csaCx0=2ZDVLh#48j~*QV*P8WF4=RFw<J!nhev$RbHkv69FqAoi>7LxN1v~bp
ztHGk+^pmH%aIC*LXQ_Gm$4eEFamQYEZD3w+!xE#=3<hbeQx=MH_b2INtfuqsUfU-4
z(?#t^l55fWQTJmNbWd8KowMWO6lZxLv8yQXZ}{0*z5^l;^7U`4H^6buQG{YGt~%K5
zmRzrKCz}RV?J~9BE=Av4omolR|H|XS^zvmc?mCHAR~8lGfwoTM#hoLu4H^95D?cf}
zDT+zFc&^LORZSGb8`u*mmS5wX;sZETwa>9{|Lmf?j>4fPUq>@hXs1-Q;>&KQYfvoH
zeMkRtc8*Qb3${7Br~7(!40<GLc5$l!9>KkI<!o&_KmexRcE&pB2M<g2V!qag@FLiv
z;&`exEwSk2RddO225+uOJD|tBGCf#<&6ej1@2pAtG&8Xts9udSepki{UC!UXvNmma
ze{X><{r!Ad_E?+uV&9C7NHwodZ568HWKVqrNBP7~3Z%W#9T*M{m!q<`1M0_hc?nhZ
z3cd>8&(@^}BjU}+A|II|6$$3iJaH)(VtOm`d$uUe<jE8~S-u3a>hNY}Tr{sg4+pj(
zRwQ7;_%~?txrg#Icq7Bw{Q7IVY1T3<aWqk0g11~$jKv3GH(0MjSFj;DBYf_C%QIbZ
z<fIjA)HEbfzxKWthd(}49Z<7kFCDQmTTfOGBJmm`aD07wdjLHZy#K9fXk;B$hXf|R
z9uh{?>xEr_eqFNx)sigLpukovWF99QOHzZu6p1ubK^Vt=6@{g!t6JNNt*h7~!HIT~
zrFn_M#DNk?><G)5CAkoUeQF5TJd8v96H;QIas*>vpdywBPsb<h1Pmhs#m%tI!BaLs
zgN=|bFNki1#|A&<33~5$(?(-hVV6$m?;po^=YQ5{jfCC?6hvQt*}Ve?7OcVl*bEk|
zfveSg!5aJz8U3F>*}c?)HTXXndj4Mv*5LVk%==`s#J?(QV7aGLoUd1T^P%ExS(6`-
zlw-+5HKld(ho;cTAW2;oRW*2>MV;yrypz!$fb7{E7HGWL7fVY90{(gGjRa^!TpGHk
zZwM)nlf#OeyV3!|X*#Ww0Jc^c?sTm<@rSB|mbH}a^QQIr7bc23;C}SHptdi^;hI!I
zH;Od-6ZMZ>wX4<Tu=kCmshjY2Mj@x%>ADszLS1p+WESCRF)=f}!v31A4An}e`>}HK
zA~e;7?^}=T5h1zTM|DrmyWjK~V+mwX=IHutvwZNL2e!NhN4>pf#+J`yjN$$)lM&WI
znWO2p1=F)HxgV?ocTN^Jn|@wGXpoI~G=KiQg64fn+Zwid6({GrPVD>6Sw1-6LB<p^
zb1q@dEJd;IHy@UVT1b`bpaC}R^RnIV{2F9L%I-NCduH#j4t+Rpj-G#^_8PpBWYdi}
zDA569dRAv{RDY7&nSIwi;M54IyQFiLQYkjVeR`#4;HcFzJ?Z__qR`H;4erO{Sh;OD
zM<4n0*bYu{bad|Cjj2`dJfD$ypW>gu+gNe;G*`A`Hvf!szGd$7t7cA0gj4;DQUE3u
zs|I$zy?EZSJokd|V_5wxNQ<R>>im|KB)R*+5ZEj$!hsjylqEw-Doj1x5Lr*uHol>|
zDQwQhf9I3jy_GdDXiPXbWvUI887v48=N<Ih;Cq6tAF!`1#vB5!o|Is%YBY9vaL`Ns
zH(xtv5O)mX`HJhB52pW>+57$1`MF^ojW@!x`=_zt%Y)As)!FH`cPdR2$0S*VmRwBy
z38^SaYZa$tNG7JQa%jVW*17<NPj>Sp(_9Ih<#sgoQHFDv5O6_97xDD%2v!IQ+KkA`
zSGSmGB2nsQioOD6Gy!J1KsOZy$@0Xg1Wb<Ty6J|_6eiRBu$=%7H>0VB5p#K%Po4UL
z<dy`N+98g<j8M@)k-cjMMQF3?3-7gn9F0Lgg$Z?!N&9!c9*3uqnxcJ%Q+Z>LDFz!{
zM+VoEH%ZuZMmRWKfr37NxT{2Qmwy_~{%e?;;GI6cwm`O<xjBj0D{n5;pmiu0wQ^Fh
z-{yG?3><c57fFSQt_Q_94!f6a2R=zPFo$X~ZgGE`tRKxSlg@BE`=EFY?#H4G7HpXj
zaAh0}b3H1>A*MK%dCXqdv+RK16J#yse?tcBtCVYFrXrLFmG~!2y~@{KRyx<&f#QAl
zSG)vj(a|s1V4EXh9sp}&yL?<WS6!X}Yn|mD%5flN7uXT^OJ|iemKy8Ky(hd{DzOfE
z&!%3N{aLbYSS2sH$Z~rN;lqO6IO)W8I~P{HxvwbnEs_T(B1|RU%y&xFqZ&+S)sN_%
zu~ZBXd>)skI*WFGMvr*)WI#g{?Uvmf^w^HJ2AbBakE2(+ceFK9jgThT%ej5e@dQ{O
z97hfbW(?5G{<YSF)2RNo0gQ7wdc><s2oy<zQ}z!w!d6Q9qRA*~Qx1&A8@e$(NVs}Y
zqyh8Whr42WAE*d_Oq=osttj{qwq!AKm-hp6a>`^M>fX3|N#ELz+*kAbm#X)m$|^~Z
zPN75Q)L;H&aS3t-c0IlWQ=h1)G=hr2x|9=^)>!P+6|nm<5y3k|7E?O~KkQQuq`~LN
z5moOiQH-3ia#RFS4d(c$-sI+W7_{~H6P;pU5TBr_q4mW@Oz{cScEHlxmszzI(~hf<
z$czQPsoB~{0&Rqgli_<b4>LLShj_G%Dq7Z$;p45Z;?x9Y+U-datuvVrzQ@R{L7=<m
z)L%YreHi&GuC6*j+hYUO_}+=3)_872*5vd+4bAfEyRn<irTp4g#%cvCf8cR~X<hQJ
z505@xsJ+iw(4QadXN(KA_vduX``d2a7i#akd2+m92f_=r_m`&2%YI8@q4xgbe0kZ<
zw8+1{+MB5qzekP*)t3ty;VnJc=F7%Td#zJE916AdnwBS$`l$o><#nT%^VLko6-V7X
zlXm-iN8Rjm)J<uDIcM!HHURoEdGwwkVG#^0@O>#RccFJ-<0~~7aTMx|GqF*gx6n%u
ziO>D=k7a)|kqdva5OWpAs&IH!7-VIDE$+8MB-zAZteqEC#@T6|2YqO`abg+4PF|C0
z?ChxkrXTLIr#B!aA>q>*v+6MtE)z3=kDR#=0gk)hSfvzD%qe!n)449I<fkU-8y<A-
zBLiroY4%g<vPa<Van(T3t1e1RxC-VR;TqXy&Dq&tnHzmd7FX#GyLab?hp9iY%b9&o
zh;X+_LI=@~o)11MILPtf*nuZA)S(>=#;!3>?oLUeftDFsH}ffL1713$Y<;m?m}iyR
zeGR0Arf)_%x@4O!j05iLqJE_OQR7^Vopt}Vna>IU!a2v~SvOkEsRgBTB*rXtUt$3q
zYXiM_hQipk9#7iQ!E#n=ft}$xwlNRdQDb`zq@E*-PAFUE-VIPgVPP>eQVi^KZar^3
zf){wsi}$)diRRGDwP%ntB}Dq~8&ond4{IiQFK)ap{HQ%w19o1q^b5!`p7-~$x0WDZ
v+xNTfI}y?Hq}T-WM6U2`>EqKmgxVZznz$<u`CoUafJGAYg)^VOlj!vy0fdTo
literal 0
HcmV?d00001
diff --git a/tests/misc-tests/016-send-clone-src/test.sh b/tests/misc-tests/016-send-clone-src/test.sh
new file mode 100755
index 0000000..3a61db7
--- /dev/null
+++ b/tests/misc-tests/016-send-clone-src/test.sh
@@ -0,0 +1,50 @@
+#!/bin/bash
+#
+# test for sending stream size of clone-src option
+
+source $TOP/tests/common
+
+check_prereq mkfs.btrfs
+check_prereq btrfs
+
+setup_root_helper
+prepare_test_dev 1g
+
+run_check $TOP/mkfs.btrfs -f $IMAGE
+run_check_mount_test_dev
+
+here=`pwd`
+cd "$TEST_MNT" || _fail "cannot chdir to TEST_MNT"
+
+run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent1
+for i in 1 2 3; do
+ run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent1/file1_$i bs=1M count=1
+ run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent1 subv-snap1_$i
+done
+
+run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent2
+for i in 1 2 3; do
+ run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent2/file2_$i bs=1M count=1
+ run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent2 subv-snap2_$i
+done
+
+truncate -s0 "$here"/send-stream.img
+chmod a+w "$here"/send-stream.img
+run_check $SUDO_HELPER $TOP/btrfs send -f "$here"/send-stream.img \
+ -c subv-snap1_1 -c subv-snap2_1 subv-snap1_[23] subv-snap2_[23]
+
+gunzip -c "$here"/send-stream-v4.8.2.img.gz > "$here"/old-send-stream.img
+old_stream_size=`stat --format=%s "$here"/old-send-stream.img`
+stream_size=`stat --format=%s "$here"/send-stream.img`
+
+if [ $old_stream_size -lt $stream_size ]; then
+ run_check ls -l "$here"/old-send-stream.img "$here"/send-stream.img
+ _fail "sending stream size is bigger than old stream"
+fi
+
+run_check rm -f "$here"/old-send-stream.img "$here"/send-stream.img
+
+cd "$here" || _fail "cannot chdir back to test directory"
+
+run_check_umount_test_dev
+
--
2.9.3
^ permalink raw reply related
* Re: status of spdk
From: Haomai Wang @ 2016-11-09 4:45 UTC (permalink / raw)
To: Yehuda Sadeh-Weinraub; +Cc: Weil, Sage, ceph-devel
In-Reply-To: <CADRKj5R+kwpr+_D+bx48gw_BHzX0jcQG-52C_kiLuTeqeEV+Qw@mail.gmail.com>
On Wed, Nov 9, 2016 at 7:31 AM, Yehuda Sadeh-Weinraub <yehuda@redhat.com> wrote:
> I just started looking at spdk, and have a few comments and questions.
>
> First, it's not clear to me how we should handle build. At the moment
> the spdk code resides as a submodule in the ceph tree, but it depends
> on dpdk, which currently needs to be downloaded separately. We can add
> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> said, getting it to build was a bit tricky and I think it might be
> broken with cmake. In order to get it working I resorted to building a
> system library and use that.
yes, because we expect dpdk submodule will merge soon. we left this aside..
now the eaisest way is yum install dpdk-devel to complete the build
instead of git clone dpdk repo separated.
>
> The way to currently configure an osd to use bluestore with spdk is by
> creating a symbolic link that replaces the bluestore 'block' device to
> point to a file that has a name that is prefixed with 'spdk:'.
> Originally I assumed that the suffix would be the nvme device id, but
> it seems that it's not really needed, however, the file itself needs
> to contain the device id (see
> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
> minor fixes).
hmm, I commented in config_opt.h.
// If you want to use spdk driver, you need to specify NVMe serial number here
// with "spdk:" prefix.
// Users can use 'lspci -vvv -d 8086:0953 | grep "Device Serial Number"' to
// get the serial number of Intel(R) Fultondale NVMe controllers.
// Example:
// bluestore_block_path = spdk:55cd2e404bd73932
we don't need to create symbolic link by hand, it could be done in
bluestore codes.
>
> As I understand it, in order to support multiple osds on the same NVMe
> device we have a few options. We can leverage NVMe namespaces, but
> that's not supported on all devices. We can configure bluestore to
> only use part of the device (device sharding? not sure if it supports
> it). I think it's best if we could keep bluestore out of the loop
> there and have the NVMe driver abstract multiple partitions of the
> NVMe device. The idea is to be able to define multiple partitions on
> the device (e.g., each partition will be defined by the offset, size,
> and namespace), and have the osd set to use a specific partition.
> We'll probably need a special tool to manage it, and potentially keep
> the partition table information on the device itself. The tool could
> also manage the creation of the block link. We should probably rethink
> how the link is structure and what it points at.
I discussed multi namespace with intel, spdk will embedded multi
namespace management.
But before ceph-osd single process can support multi OSD instance, I
think we need to do offset/length in application side.
Besides these problems, the most important thing is getting ride of
spdk dependence on dpdk. before multi-osd within single process
feature is done, we can't bear the multi polling threads occur 100%
cpu times.
>
> Any thoughts?
>
> Yehuda
--
Best Regards,
Wheat
^ permalink raw reply
* [Ocfs2-devel] [RFC] Should we revert commit "ocfs2: take inode lock in ocfs2_iop_set/get_acl()"? or other ideas?
From: Eric Ren @ 2016-11-09 4:47 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <1476854382-28101-1-git-send-email-zren@suse.com>
Hi all,
On 10/19/2016 01:19 PM, Eric Ren wrote:
> ocfs2_permission() and ocfs2_iop_get/set_acl() both call ocfs2_inode_lock().
> The problem is that the call chain of ocfs2_permission() includes *_acl().
>
> Possibly, there are three solutions I can think of. The first one is to
> implement the inode permission routine for ocfs2 itself, replacing the
> existing generic_permission(); this will bring lots of changes and
> involve too many trivial vfs functions into ocfs2 code. Frown on this.
>
> The second one is, what I am trying now, to keep track of the processes who
> lock/unlock a cluster lock by the following draft patches. But, I quickly
> find out that a cluster locking which has been taken by processA can be unlocked
> by processB. For example, systemfiles like journal:0000 is locked during mout, and
> unlocked during umount.
We can avoid the problem above by:
1) not keeping track of system file inode:
if (!(OCFS2_I(inode)->ip_flags & OCFS2_INODE_SYSTEM_FILE)) {
....
}
2) only keeping track of inode metadata lockres:
OCFS2_I(inode)->ip_inode_lockres;
because inode open lockres can also be get/release by different processes.
Eric
>
> The thrid one is to revert that problematic commit! It looks like get/set_acl()
> are always been called by other vfs callback like ocfs2_permission(). I think
> we can do this if it's true, right? Anyway, I'll try to work out if it's true;-)
>
> Hope for your input to solve this problem;-)
>
> Thanks,
> Eric
>
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20161109/df737ced/attachment.html
^ permalink raw reply
* [U-Boot] [PATCH] board: am335x/mux: Do not hang when encountering a bad EEPROM
From: Alexandru Gagniuc @ 2016-11-09 4:48 UTC (permalink / raw)
To: u-boot
In most cases, the SPL and u-boot.img will be on the same boot media.
Since the SPL was loaded by the boot rom, the pinmux will already have
been configured for this media. This, the board will still be able to
boot successfully, or at least reach the u-boot console, where more
recovery options are available.
I've encountered this on a beaglebone black with a corrupted EEPROM.
Removing this check allowed the board to boot successfully. I've also
seen this on EVM-based boards with an unprogrammed EEPROM. On those
boards, for some reason there were no UART messages. This made it look
as if the SOC was dead.
Remove the hang(), as it is not a fatal error. Also reformat the error
message to be clearer as to the cause. The original message made it
appear as if the wrong binary was being loaded.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
---
board/ti/am335x/mux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 8afa5f9..ad85b3a 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -397,7 +397,7 @@ void enable_board_pin_mux(void)
configure_module_pin_mux(rmii1_pin_mux);
configure_module_pin_mux(spi0_pin_mux);
} else {
- puts("Unknown board, cannot configure pinmux.");
- hang();
+ /* Unknown board. We might still be able to boot. */
+ puts("Bad EEPROM or unknown board, cannot configure pinmux.");
}
}
--
2.7.4
^ permalink raw reply related
* Re: status of spdk
From: Haomai Wang @ 2016-11-09 4:49 UTC (permalink / raw)
To: Sage Weil; +Cc: Yehuda Sadeh-Weinraub, ceph-devel
In-Reply-To: <alpine.DEB.2.11.1611082334390.32512@piezo.us.to>
On Wed, Nov 9, 2016 at 7:40 AM, Sage Weil <sweil@redhat.com> wrote:
> On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
>> I just started looking at spdk, and have a few comments and questions.
>>
>> First, it's not clear to me how we should handle build. At the moment
>> the spdk code resides as a submodule in the ceph tree, but it depends
>> on dpdk, which currently needs to be downloaded separately. We can add
>> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
>> said, getting it to build was a bit tricky and I think it might be
>> broken with cmake. In order to get it working I resorted to building a
>> system library and use that.
>
> Note that this PR is about to merge
>
> https://github.com/ceph/ceph/pull/10748
>
> which adds the DPDK submodule, so hopefully this issue will go away when
> that merged or with a follow-on cleanup.
I rebased and I think we can merge now.
>
>> The way to currently configure an osd to use bluestore with spdk is by
>> creating a symbolic link that replaces the bluestore 'block' device to
>> point to a file that has a name that is prefixed with 'spdk:'.
>> Originally I assumed that the suffix would be the nvme device id, but
>> it seems that it's not really needed, however, the file itself needs
>> to contain the device id (see
>> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
>> minor fixes).
>
> Open a PR for those?
yep!
>
>> As I understand it, in order to support multiple osds on the same NVMe
>> device we have a few options. We can leverage NVMe namespaces, but
>> that's not supported on all devices. We can configure bluestore to
>> only use part of the device (device sharding? not sure if it supports
>> it). I think it's best if we could keep bluestore out of the loop
>> there and have the NVMe driver abstract multiple partitions of the
>> NVMe device. The idea is to be able to define multiple partitions on
>> the device (e.g., each partition will be defined by the offset, size,
>> and namespace), and have the osd set to use a specific partition.
>> We'll probably need a special tool to manage it, and potentially keep
>> the partition table information on the device itself. The tool could
>> also manage the creation of the block link. We should probably rethink
>> how the link is structure and what it points at.
>
> I agree that bluestore shouldn't get involved.
>
> Is the NVMe namespaces meant to support multiple processes sharing the
> same hardware device?
sure
>
> Also, if you do that, is it possible to give one of the namespaces to the
> kernel? That might solve the bootstrapping problem we currently have
> where we have nowhere to put the $osd_data filesystem with the device
> metadata. (This is admittedly not necessarily a blocking issue. Putting
> those dirs on / wouldn't be the end of the world; it just means cards
> can't be easily moved between boxes.)
the spdk community is make nvme-cli support spdk backend. by default
nvmecli only can operate kernel nvme module, but intel is working on
making spdk can be operated by nvmecli. so it will make users much
convenient.
>
> sage
--
Best Regards,
Wheat
^ permalink raw reply
* Re: [PATCH 0/3] add ION driver for STIh4xx SoC
From: Laura Abbott @ 2016-11-09 4:49 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Sumit Semwal, Greg Kroah-Hartman, yudongbin, Chen Feng, LKML,
linaro-kernel@lists.linaro.org, kernel
In-Reply-To: <CA+M3ks6+HZCov3ALrgXjxnxxWdf+8S2aXaO80du68p0=Zugk4w@mail.gmail.com>
On 11/08/2016 01:18 AM, Benjamin Gaignard wrote:
> Ok so no more dev on ION but can we add ION drivers like hisilicon does ?
>
If we can agree upon bindings, yes I think it would make sense
to have more platform support. Ideally, it would translate over
to newer features as well.
Thanks,
Laura
^ permalink raw reply
* [Ocfs2-devel] [DRAFT 2/2] ocfs2: fix deadlock caused by recursive cluster locking
From: Eric Ren @ 2016-11-09 4:55 UTC (permalink / raw)
To: ocfs2-devel
In-Reply-To: <1476854382-28101-3-git-send-email-zren@suse.com>
Hi all,
On 10/19/2016 01:19 PM, Eric Ren wrote:
> diff --git a/fs/ocfs2/acl.c b/fs/ocfs2/acl.c
> index bed1fcb..7e3544e 100644
> --- a/fs/ocfs2/acl.c
> +++ b/fs/ocfs2/acl.c
> @@ -283,16 +283,24 @@ int ocfs2_set_acl(handle_t *handle,
> int ocfs2_iop_set_acl(struct inode *inode, struct posix_acl *acl, int type)
> {
> struct buffer_head *bh = NULL;
> + struct ocfs2_holder *oh;
> + struct ocfs2_lock_res *lockres = &OCFS2_I(inode)->ip_inode_lockres;
> int status = 0;
>
> - status = ocfs2_inode_lock(inode, &bh, 1);
> - if (status < 0) {
> - if (status != -ENOENT)
> - mlog_errno(status);
> - return status;
> + oh = ocfs2_is_locked_by_me(lockres);
> + if (!oh) {
> + status = ocfs2_inode_lock(inode, &bh, 1);
> + if (status < 0) {
> + if (status != -ENOENT)
> + mlog_errno(status);
> + return status;
> + }
> }
This is wrong. We also depend ocfs2_inode_lock() pass out "bh" for later use.
So, we may need another function something like ocfs2_inode_getbh():
if (!oh)
ocfs2_inode_lock();
else
ocfs2_inode_getbh();
Eric
> +
> status = ocfs2_set_acl(NULL, inode, bh, type, acl, NULL, NULL);
> - ocfs2_inode_unlock(inode, 1);
> +
> + if (!oh)
> + ocfs2_inode_unlock(inode, 1);
> brelse(bh);
> return status;
> }
> @@ -302,21 +310,28 @@ struct posix_acl *ocfs2_iop_get_acl(struct inode *inode, int type)
> struct ocfs2_super *osb;
> struct buffer_head *di_bh = NULL;
> struct posix_acl *acl;
> + struct ocfs2_holder *oh;
> + struct ocfs2_lock_res *lockres = &OCFS2_I(inode)->ip_inode_lockres;
> int ret;
>
> osb = OCFS2_SB(inode->i_sb);
> if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
> return NULL;
> - ret = ocfs2_inode_lock(inode, &di_bh, 0);
> - if (ret < 0) {
> - if (ret != -ENOENT)
> - mlog_errno(ret);
> - return ERR_PTR(ret);
> +
> + oh = ocfs2_is_locked_by_me(lockres);
> + if (!oh) {
> + ret = ocfs2_inode_lock(inode, &di_bh, 0);
> + if (ret < 0) {
> + if (ret != -ENOENT)
> + mlog_errno(ret);
> + return ERR_PTR(ret);
> + }
> }
>
> acl = ocfs2_get_acl_nolock(inode, type, di_bh);
>
> - ocfs2_inode_unlock(inode, 0);
> + if (!oh)
> + ocfs2_inode_unlock(inode, 0);
> brelse(di_bh);
> return acl;
> }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20161109/ddb6d0e4/attachment.html
^ permalink raw reply
* Re: status of spdk
From: Haomai Wang @ 2016-11-09 4:59 UTC (permalink / raw)
To: LIU, Fei; +Cc: Yehuda Sadeh-Weinraub, Sage Weil, ceph-devel
In-Reply-To: <41F4566A-4573-4CB9-81F4-1688ED2534C1@alibaba-inc.com>
On Wed, Nov 9, 2016 at 8:21 AM, LIU, Fei <james.liu@alibaba-inc.com> wrote:
> Hi Yehuda and Haomai,
> The issue of drives driven by SPDK is not able to be shared by multiple OSDs as kernel NVMe drive since SPDK as a process so far can not be shared across multiple processes like OSDs, right?
spdk nvme supports multi process is a undergoing spdk feature now, it
will be implemented via shared memory among multi process.
>
> Regards,
> James
>
>
>
> On 11/8/16, 4:06 PM, "Yehuda Sadeh-Weinraub" <ceph-devel-owner@vger.kernel.org on behalf of yehuda@redhat.com> wrote:
>
> On Tue, Nov 8, 2016 at 3:40 PM, Sage Weil <sweil@redhat.com> wrote:
> > On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
> >> I just started looking at spdk, and have a few comments and questions.
> >>
> >> First, it's not clear to me how we should handle build. At the moment
> >> the spdk code resides as a submodule in the ceph tree, but it depends
> >> on dpdk, which currently needs to be downloaded separately. We can add
> >> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> >> said, getting it to build was a bit tricky and I think it might be
> >> broken with cmake. In order to get it working I resorted to building a
> >> system library and use that.
> >
> > Note that this PR is about to merge
> >
> > https://github.com/ceph/ceph/pull/10748
> >
> > which adds the DPDK submodule, so hopefully this issue will go away when
> > that merged or with a follow-on cleanup.
> >
> >> The way to currently configure an osd to use bluestore with spdk is by
> >> creating a symbolic link that replaces the bluestore 'block' device to
> >> point to a file that has a name that is prefixed with 'spdk:'.
> >> Originally I assumed that the suffix would be the nvme device id, but
> >> it seems that it's not really needed, however, the file itself needs
> >> to contain the device id (see
> >> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
> >> minor fixes).
> >
> > Open a PR for those?
>
> Sure
>
> >
> >> As I understand it, in order to support multiple osds on the same NVMe
> >> device we have a few options. We can leverage NVMe namespaces, but
> >> that's not supported on all devices. We can configure bluestore to
> >> only use part of the device (device sharding? not sure if it supports
> >> it). I think it's best if we could keep bluestore out of the loop
> >> there and have the NVMe driver abstract multiple partitions of the
> >> NVMe device. The idea is to be able to define multiple partitions on
> >> the device (e.g., each partition will be defined by the offset, size,
> >> and namespace), and have the osd set to use a specific partition.
> >> We'll probably need a special tool to manage it, and potentially keep
> >> the partition table information on the device itself. The tool could
> >> also manage the creation of the block link. We should probably rethink
> >> how the link is structure and what it points at.
> >
> > I agree that bluestore shouldn't get involved.
> >
> > Is the NVMe namespaces meant to support multiple processes sharing the
> > same hardware device?
>
> More of a partitioning solution, but yes (as far as I undestand).
>
> >
> > Also, if you do that, is it possible to give one of the namespaces to the
> > kernel? That might solve the bootstrapping problem we currently have
>
> Theoretically, but not right now (or ever?). See here:
>
> https://lists.01.org/pipermail/spdk/2016-July/000073.html
>
> > where we have nowhere to put the $osd_data filesystem with the device
> > metadata. (This is admittedly not necessarily a blocking issue. Putting
> > those dirs on / wouldn't be the end of the world; it just means cards
> > can't be easily moved between boxes.)
> >
>
> Maybe we can use bluestore for these too ;) that been said, there
> might be some kind of a loopback solution that could work, but not
> sure if it won't create major bottlenecks that we'd want to avoid.
>
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Best Regards,
Wheat
^ permalink raw reply
* Re: [PATCH v2 00/12] mm: page migration enhancement for thp
From: Naoya Horiguchi @ 2016-11-09 4:59 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-mm@kvack.org, Kirill A. Shutemov, Hugh Dickins,
Andrew Morton, Dave Hansen, Andrea Arcangeli, Mel Gorman,
Michal Hocko, Vlastimil Babka, Pavel Emelyanov, Zi Yan,
linux-kernel@vger.kernel.org, Naoya Horiguchi
In-Reply-To: <ee20300d-0367-5b2c-71f2-f86bce3d6b90@gmail.com>
On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> >
> > General description (no change since ver.1)
> > ===========================================
> >
> > This patchset enhances page migration functionality to handle thp migration
> > for various page migration's callers:
> > - mbind(2)
> > - move_pages(2)
> > - migrate_pages(2)
> > - cgroup/cpuset migration
> > - memory hotremove
> > - soft offline
> >
> > The main benefit is that we can avoid unnecessary thp splits, which helps us
> > avoid performance decrease when your applications handles NUMA optimization on
> > their own.
> >
> > The implementation is similar to that of normal page migration, the key point
> > is that we modify a pmd to a pmd migration entry in swap-entry like format.
> >
> > Changes / Notes
> > ===============
> >
> > - pmd_present() in x86 checks _PAGE_PRESENT, _PAGE_PROTNONE and _PAGE_PSE
> > bits together, which makes implementing thp migration a bit hard because
> > _PAGE_PSE bit is currently used by soft-dirty in swap-entry format.
> > I was advised to dropping _PAGE_PSE in pmd_present(), but I don't think
> > of the justification, so I keep it in this version. Instead, my approach
> > is to move _PAGE_SWP_SOFT_DIRTY to bit 6 (unused) and reserve bit 7 for
> > pmd non-present cases.
>
> Thanks, IIRC
>
> pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
>
> AutoNUMA balancing would change it to
>
> pmd_present = _PAGE_PROTNONE | _PAGE_PSE
>
> and PMD_SWP_SOFT_DIRTY would make it
>
> pmd_present = _PAGE_PSE
>
> What you seem to be suggesting in your comment is that
>
> pmd_present should be _PAGE_PRESENT | _PAGE_PROTNONE
This (no _PAGE_PSE) was a possibile solution, and as I described I gave up
this solution, because I noticed that what I actually wanted was that
pmd_present() certainly returns false during thp migration and that's done
by moving _PAGE_SWP_SOFT_DIRTY. So
pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
is still correct in this patchset.
>
> Isn't that good enough?
>
> For THP migration I guess we use
>
> _PAGE_PRESENT | _PAGE_PROTNONE | is_migration_entry(pmd)
Though I might misread your notations, I hope that the following code
seems describe itself well.
static inline int is_pmd_migration_entry(pmd_t pmd)
{
return !pmd_present(pmd) && is_migration_entry(pmd_to_swp_entry(pmd));
}
Thanks,
Naoya Horiguchi
>
>
> >
> > - this patchset still covers only x86_64. Zi Yan posted a patch for ppc64
> > and I think it's favorably received so that's fine. But there's unsolved
> > minor suggestion by Aneesh, so I don't include it in this set, expecting
> > that it will be updated/reposted.
> >
> > - pte-mapped thp and doubly-mapped thp were not supported in ver.1, but
> > this version should work for such kinds of thp.
> >
> > - thp page cache is not tested yet, and it's at the head of my todo list
> > for future version.
> >
> > Any comments or advices are welcomed.
>
> Balbir Singh
>
^ permalink raw reply
* Re: [PATCH v2 00/12] mm: page migration enhancement for thp
From: Naoya Horiguchi @ 2016-11-09 4:59 UTC (permalink / raw)
To: Balbir Singh
Cc: linux-mm@kvack.org, Kirill A. Shutemov, Hugh Dickins,
Andrew Morton, Dave Hansen, Andrea Arcangeli, Mel Gorman,
Michal Hocko, Vlastimil Babka, Pavel Emelyanov, Zi Yan,
linux-kernel@vger.kernel.org, Naoya Horiguchi
In-Reply-To: <ee20300d-0367-5b2c-71f2-f86bce3d6b90@gmail.com>
On Wed, Nov 09, 2016 at 01:32:04PM +1100, Balbir Singh wrote:
> On 08/11/16 10:31, Naoya Horiguchi wrote:
> > Hi everyone,
> >
> > I've updated thp migration patches for v4.9-rc2-mmotm-2016-10-27-18-27
> > with feedbacks for ver.1.
> >
> > General description (no change since ver.1)
> > ===========================================
> >
> > This patchset enhances page migration functionality to handle thp migration
> > for various page migration's callers:
> > - mbind(2)
> > - move_pages(2)
> > - migrate_pages(2)
> > - cgroup/cpuset migration
> > - memory hotremove
> > - soft offline
> >
> > The main benefit is that we can avoid unnecessary thp splits, which helps us
> > avoid performance decrease when your applications handles NUMA optimization on
> > their own.
> >
> > The implementation is similar to that of normal page migration, the key point
> > is that we modify a pmd to a pmd migration entry in swap-entry like format.
> >
> > Changes / Notes
> > ===============
> >
> > - pmd_present() in x86 checks _PAGE_PRESENT, _PAGE_PROTNONE and _PAGE_PSE
> > bits together, which makes implementing thp migration a bit hard because
> > _PAGE_PSE bit is currently used by soft-dirty in swap-entry format.
> > I was advised to dropping _PAGE_PSE in pmd_present(), but I don't think
> > of the justification, so I keep it in this version. Instead, my approach
> > is to move _PAGE_SWP_SOFT_DIRTY to bit 6 (unused) and reserve bit 7 for
> > pmd non-present cases.
>
> Thanks, IIRC
>
> pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
>
> AutoNUMA balancing would change it to
>
> pmd_present = _PAGE_PROTNONE | _PAGE_PSE
>
> and PMD_SWP_SOFT_DIRTY would make it
>
> pmd_present = _PAGE_PSE
>
> What you seem to be suggesting in your comment is that
>
> pmd_present should be _PAGE_PRESENT | _PAGE_PROTNONE
This (no _PAGE_PSE) was a possibile solution, and as I described I gave up
this solution, because I noticed that what I actually wanted was that
pmd_present() certainly returns false during thp migration and that's done
by moving _PAGE_SWP_SOFT_DIRTY. So
pmd_present = _PAGE_PRESENT | _PAGE_PROTNONE | _PAGE_PSE
is still correct in this patchset.
>
> Isn't that good enough?
>
> For THP migration I guess we use
>
> _PAGE_PRESENT | _PAGE_PROTNONE | is_migration_entry(pmd)
Though I might misread your notations, I hope that the following code
seems describe itself well.
static inline int is_pmd_migration_entry(pmd_t pmd)
{
return !pmd_present(pmd) && is_migration_entry(pmd_to_swp_entry(pmd));
}
Thanks,
Naoya Horiguchi
>
>
> >
> > - this patchset still covers only x86_64. Zi Yan posted a patch for ppc64
> > and I think it's favorably received so that's fine. But there's unsolved
> > minor suggestion by Aneesh, so I don't include it in this set, expecting
> > that it will be updated/reposted.
> >
> > - pte-mapped thp and doubly-mapped thp were not supported in ver.1, but
> > this version should work for such kinds of thp.
> >
> > - thp page cache is not tested yet, and it's at the head of my todo list
> > for future version.
> >
> > Any comments or advices are welcomed.
>
> Balbir Singh
>
--
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: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Dave Young @ 2016-11-09 5:02 UTC (permalink / raw)
To: Wen Congyang, anderson; +Cc: lersek, qemu-devel, bhe
In-Reply-To: <962ee966-641a-2f74-3e26-7c7967fa8f7e@cn.fujitsu.com>
On 11/09/16 at 11:58am, Wen Congyang wrote:
> On 11/09/2016 11:17 AM, Dave Young wrote:
> > Drop qiaonuohan, seems the mail address is wrong..
> >
> > On 11/09/16 at 11:01am, Dave Young wrote:
> >> Hi,
> >>
> >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> >> addresses, we had some effort to support kexec/kdump so that crash
> >> utility can still works in case crashed kernel has kaslr enabled.
> >>
> >> But according to Dave Anderson virsh dump does not work, quoted messages
> >> from Dave below:
> >>
> >> """
> >> with virsh dump, there's no way of even knowing that KASLR
> >> has randomized the kernel __START_KERNEL_map region, because there is no
> >> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> >> vmcoreinfo data to compare against the vmlinux file symbol value.
> >> Unless virsh dump can export some basic virtual memory data, which
> >> they say it can't, I don't see how KASLR can ever be supported.
> >> """
> >>
> >> I assume virsh dump is using qemu guest memory dump facility so it
> >> should be first addressed in qemu. Thus post this query to qemu devel
> >> list. If this is not correct please let me know.
>
> IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump'
> uses migration to dump.
Do they need different fixes? Dave, I guess you mean --memory-only, but
could you clarify and confirm it?
>
> I think I should study kaslr first...
Thanks for taking care of it.
>
> Thanks
> Wen Congyang
>
> >>
> >> Could you qemu dump people make it work? Or we can not support virt dump
> >> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
> >>
> >> Thanks
> >> Dave
> >
> >
> >
>
>
>
^ permalink raw reply
* Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration
From: David Gibson @ 2016-11-09 4:24 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <ec1c8f0e-b820-0477-2513-464017e3e2ed@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 4480 bytes --]
On Tue, Nov 08, 2016 at 05:03:49PM +1100, Alexey Kardashevskiy wrote:
> On 08/11/16 16:29, David Gibson wrote:
> > On Fri, Nov 04, 2016 at 06:54:48PM +1100, Alexey Kardashevskiy wrote:
> >> On 30/10/16 22:12, David Gibson wrote:
> >>> When a vmstate for the ppc cpu was first introduced (a90db15 "target-ppc:
> >>> Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used
> >>> to ensure that identical CPU models were used at source and destination
> >>> as based on the PVR (Processor Version Register).
> >>>
> >>> However this was a problem for HV KVM, where due to hardware limitations
> >>> we always need to use the real PVR of the host CPU. So, to allow
> >>> migration between hosts with "similar enough" CPUs, the PVR check was
> >>> removed in 569be9f0 "target-ppc: Remove PVR check from migration". This
> >>> left the onus on user / management to only attempt migration between
> >>> compatible CPUs.
> >>>
> >>> Now that we've reworked the handling of compatiblity modes, we have the
> >>> information to actually determine if we're making a compatible migration.
> >>> So this patch partially restores the PVR check. If the source was running
> >>> in a compatibility mode, we just make sure that the destination cpu can
> >>> also run in that compatibility mode. However, if the source was running
> >>> in "raw" mode, we verify that the destination has the same PVR value.
> >>>
> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>> ---
> >>> target-ppc/machine.c | 15 +++++++++++----
> >>> 1 file changed, 11 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c
> >>> index 5d87ff6..62b9e94 100644
> >>> --- a/target-ppc/machine.c
> >>> +++ b/target-ppc/machine.c
> >>> @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int version_id)
> >>> target_ulong msr;
> >>>
> >>> /*
> >>> - * We always ignore the source PVR. The user or management
> >>> - * software has to take care of running QEMU in a compatible mode.
> >>> + * If we're operating in compat mode, we should be ok as long as
> >>> + * the destination supports the same compatiblity mode.
> >>> + *
> >>> + * Otherwise, however, we require that the destination has exactly
> >>> + * the same CPU model as the source.
> >>> */
> >>> - env->spr[SPR_PVR] = env->spr_cb[SPR_PVR].default_value;
> >>>
> >>> #if defined(TARGET_PPC64)
> >>> if (cpu->compat_pvr) {
> >>> @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int version_id)
> >>> error_free(local_err);
> >>> return -1;
> >>> }
> >>> - }
> >>> + } else
> >>> #endif
> >>> + {
> >>> + if (env->spr[SPR_PVR] != env->spr_cb[SPR_PVR].default_value) {
> >>> + return -1;
> >>> + }
> >>> + }
> >>
> >> This should break migration from host with PVR=004d0200 to host with
> >> PVR=004d0201, what is the benefit of such limitation?
> >
> > There probably isn't one. But the point is it also blocks migration
> > from a host with PVR=004B0201 (POWER8) to one with PVR=00201400
> > (403GCX) and *that* has a clear benefit. I don't see a way to block
> > the second without the first, except by creating a huge compatibility
> > matrix table, which would require inordinate amounts of time to
> > research carefully.
>
>
> This is pcc->pvr_match() for this purpose.
Hmm.. thinking about this. Obviously requiring an exactly matching
PVR is the architecturally "safest" approach. For TCG and PR KVM, it
really should be sufficient - if you can select "close" PVRs at each
end, you should be able to select exactly matching ones just as well.
For HV KVM, we should generally be using compatibility modes to allow
migration between a relatively wide range of CPUs. My intention was
basically to require moving to that model, rather than "approximate
matching" real PVRs.
I'm still convinced using compat modes is the right way to go medium
to long term. However, allowing the approximate matches could make
for a more forgiving transition, if people have existing hosts in
"raw" mode.
Ok, I'll add pvr_match checking to this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [RFC 11/17] ppc: Add ppc_set_compat_all()
From: David Gibson @ 2016-11-09 3:52 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <40dfd693-9f80-4492-4c96-8e608d3527d7@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 7278 bytes --]
On Wed, Nov 09, 2016 at 12:27:47PM +1100, Alexey Kardashevskiy wrote:
> On 08/11/16 16:18, David Gibson wrote:
> > On Fri, Nov 04, 2016 at 03:01:40PM +1100, Alexey Kardashevskiy wrote:
> >> On 30/10/16 22:12, David Gibson wrote:
> >>> Once a compatiblity mode is negotiated with the guest,
> >>> h_client_architecture_support() uses run_on_cpu() to update each CPU to
> >>> the new mode. We're going to want this logic somewhere else shortly,
> >>> so make a helper function to do this global update.
> >>>
> >>> We put it in target-ppc/compat.c - it makes as much sense at the CPU level
> >>> as it does at the machine level. We also move the cpu_synchronize_state()
> >>> into ppc_set_compat(), since it doesn't really make any sense to call that
> >>> without synchronizing state.
> >>>
> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>> ---
> >>> hw/ppc/spapr_hcall.c | 31 +++++--------------------------
> >>> target-ppc/compat.c | 36 ++++++++++++++++++++++++++++++++++++
> >>> target-ppc/cpu.h | 3 +++
> >>> 3 files changed, 44 insertions(+), 26 deletions(-)
> >>>
> >>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> >>> index 3bd6d06..4eaf9a6 100644
> >>> --- a/hw/ppc/spapr_hcall.c
> >>> +++ b/hw/ppc/spapr_hcall.c
> >>> @@ -881,20 +881,6 @@ static target_ulong h_set_mode(PowerPCCPU *cpu, sPAPRMachineState *spapr,
> >>> return ret;
> >>> }
> >>>
> >>> -typedef struct {
> >>> - uint32_t compat_pvr;
> >>> - Error *err;
> >>> -} SetCompatState;
> >>> -
> >>> -static void do_set_compat(CPUState *cs, void *arg)
> >>> -{
> >>> - PowerPCCPU *cpu = POWERPC_CPU(cs);
> >>> - SetCompatState *s = arg;
> >>> -
> >>> - cpu_synchronize_state(cs);
> >>> - ppc_set_compat(cpu, s->compat_pvr, &s->err);
> >>> -}
> >>> -
> >>> static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> >>> sPAPRMachineState *spapr,
> >>> target_ulong opcode,
> >>> @@ -902,7 +888,6 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> >>> {
> >>> target_ulong list = ppc64_phys_to_real(args[0]);
> >>> target_ulong ov_table;
> >>> - CPUState *cs;
> >>> bool explicit_match = false; /* Matched the CPU's real PVR */
> >>> uint32_t max_compat = cpu->max_compat;
> >>> uint32_t best_compat = 0;
> >>> @@ -949,18 +934,12 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
> >>>
> >>> /* Update CPUs */
> >>> if (cpu->compat_pvr != best_compat) {
> >>> - CPU_FOREACH(cs) {
> >>> - SetCompatState s = {
> >>> - .compat_pvr = best_compat,
> >>> - .err = NULL,
> >>> - };
> >>> + Error *local_err = NULL;
> >>>
> >>> - run_on_cpu(cs, do_set_compat, &s);
> >>> -
> >>> - if (s.err) {
> >>> - error_report_err(s.err);
> >>> - return H_HARDWARE;
> >>> - }
> >>> + ppc_set_compat_all(best_compat, &local_err);
> >>> + if (local_err) {
> >>> + error_report_err(local_err);
> >>> + return H_HARDWARE;
> >>> }
> >>> }
> >>>
> >>> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
> >>> index 1059555..0b12b58 100644
> >>> --- a/target-ppc/compat.c
> >>> +++ b/target-ppc/compat.c
> >>> @@ -124,6 +124,8 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
> >>> pcr = compat->pcr;
> >>> }
> >>>
> >>> + cpu_synchronize_state(CPU(cpu));
> >>> +
> >>> cpu->compat_pvr = compat_pvr;
> >>> env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
> >>>
> >>> @@ -136,6 +138,40 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
> >>> }
> >>> }
> >>>
> >>> +#if !defined(CONFIG_USER_ONLY)
> >>> +typedef struct {
> >>> + uint32_t compat_pvr;
> >>> + Error *err;
> >>> +} SetCompatState;
> >>> +
> >>> +static void do_set_compat(CPUState *cs, void *arg)
> >>> +{
> >>> + PowerPCCPU *cpu = POWERPC_CPU(cs);
> >>> + SetCompatState *s = arg;
> >>> +
> >>> + ppc_set_compat(cpu, s->compat_pvr, &s->err);
> >>> +}
> >>> +
> >>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp)
> >>> +{
> >>> + CPUState *cs;
> >>> +
> >>> + CPU_FOREACH(cs) {
> >>> + SetCompatState s = {
> >>> + .compat_pvr = compat_pvr,
> >>> + .err = NULL,
> >>> + };
> >>> +
> >>> + run_on_cpu(cs, do_set_compat, &s);
> >>> +
> >>> + if (s.err) {
> >>> + error_propagate(errp, s.err);
> >>> + return;
> >>> + }
> >>> + }
> >>> +}
> >>> +#endif
> >>> +
> >>> int ppc_compat_max_threads(PowerPCCPU *cpu)
> >>> {
> >>> const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
> >>> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
> >>> index 91e8be8..201a655 100644
> >>> --- a/target-ppc/cpu.h
> >>> +++ b/target-ppc/cpu.h
> >>> @@ -1317,6 +1317,9 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool ifetch)
> >>> bool ppc_check_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
> >>> uint32_t min_compat_pvr, uint32_t max_compat_pvr);
> >>> void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp);
> >>> +#if !defined(CONFIG_USER_ONLY)
> >>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp);
> >>> +#endif
> >>
> >> I would put all ppc*compat*() under #if defined(CONFIG_USER_ONLY) &&
> >> defined(TARGET_PPC64) (or even moved this to target-ppc/Makefile.objs).
> >
> > I was originally going to do that, but decided against it.
> >
> >> Otherwise, functions like ppc_check_compat() have #if
> >> !defined(CONFIG_USER_ONLY) which suggests that the rest of
> >> ppc_check_compat() can actually be executed in ppc64-linux-user (while it
> >> cannot, can it?).
> >
> > It won't be, but there's no theoretical reason they couldn't be. User
> > mode, like spapr, doesn't execute hypervisor privilege code, and so
> > the PCR isn't owned by the "guest" (if you can call the user mode
> > executable that). Which means it could make sense to set it from the
> > outside, although that's not something we currently do.
>
> Compatibility modes are designed to disable sets of instructions to keep
> working old userspace software which relies on some opcodes to be invalid.
>
> linux-user is TCG, right? The user can pick any CPU he likes if there is
> need to run such an old software, why on earth would anyone bother with
> this compat mode in linux-user?
True, I can't really see any reason to do that.
On the other hand, compat mode does at least make theoretical sense,
whereas, for example, compat mode on powernv is fundamentally
nonsense. At this point I'm not terribly include to take away the
(token) user-only support unless there's a compelling reason *not* to
include it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [RFC 13/17] pseries: Move CPU compatibility property to machine
From: David Gibson @ 2016-11-09 4:41 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <711cf9b0-1233-c66b-eccd-a0acfccf7e96@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 6158 bytes --]
On Tue, Nov 08, 2016 at 04:56:10PM +1100, Alexey Kardashevskiy wrote:
> On 08/11/16 16:26, David Gibson wrote:
> > On Fri, Nov 04, 2016 at 06:43:52PM +1100, Alexey Kardashevskiy wrote:
> >> On 30/10/16 22:12, David Gibson wrote:
> >>> Server class POWER CPUs have a "compat" property, which is used to set the
> >>> backwards compatibility mode for the processor. However, this only makes
> >>> sense for machine types which don't give the guest access to hypervisor
> >>> privilege - otherwise the compatibility level is under the guest's control.
> >>>
> >>> To reflect this, this removes the CPU 'compat' property and instead
> >>> creates a 'max-cpu-compat' property on the pseries machine. Strictly
> >>> speaking this breaks compatibility, but AFAIK the 'compat' option was
> >>> never (directly) used with -device or device_add.
> >>>
> >>> The option was used with -cpu. So, to maintain compatibility, this patch
> >>> adds a hack to the cpu option parsing to strip out any compat options
> >>> supplied with -cpu and set them on the machine property instead of the new
> >>> removed cpu property.
> >>>
> >>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >>> ---
> >>> hw/ppc/spapr.c | 6 +++-
> >>> hw/ppc/spapr_cpu_core.c | 47 +++++++++++++++++++++++++++--
> >>> hw/ppc/spapr_hcall.c | 2 +-
> >>> include/hw/ppc/spapr.h | 10 +++++--
> >>> target-ppc/compat.c | 65 ++++++++++++++++++++++++++++++++++++++++
> >>> target-ppc/cpu.h | 6 ++--
> >>> target-ppc/translate_init.c | 73 ---------------------------------------------
> >>> 7 files changed, 127 insertions(+), 82 deletions(-)
> >>>
> >>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >>> index 6c78889..b983faa 100644
> >>> --- a/hw/ppc/spapr.c
> >>> +++ b/hw/ppc/spapr.c
> >>> @@ -1849,7 +1849,7 @@ static void ppc_spapr_init(MachineState *machine)
> >>> machine->cpu_model = kvm_enabled() ? "host" : smc->tcg_default_cpu;
> >>> }
> >>>
> >>> - ppc_cpu_parse_features(machine->cpu_model);
> >>> + spapr_cpu_parse_features(spapr);
> >>>
> >>> spapr_init_cpus(spapr);
> >>>
> >>> @@ -2191,6 +2191,10 @@ static void spapr_machine_initfn(Object *obj)
> >>> " place of standard EPOW events when possible"
> >>> " (required for memory hot-unplug support)",
> >>> NULL);
> >>> +
> >>> + object_property_add(obj, "max-cpu-compat", "str",
> >>> + ppc_compat_prop_get, ppc_compat_prop_set,
> >>> + NULL, &spapr->max_compat_pvr, &error_fatal);
> >>> }
> >>>
> >>> static void spapr_machine_finalizefn(Object *obj)
> >>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> >>> index ee5cd14..0319516 100644
> >>> --- a/hw/ppc/spapr_cpu_core.c
> >>> +++ b/hw/ppc/spapr_cpu_core.c
> >>> @@ -18,6 +18,49 @@
> >>> #include "target-ppc/mmu-hash64.h"
> >>> #include "sysemu/numa.h"
> >>>
> >>> +void spapr_cpu_parse_features(sPAPRMachineState *spapr)
> >>> +{
> >>> + /*
> >>> + * Backwards compatibility hack:
> >>> +
> >>> + * CPUs had a "compat=" property which didn't make sense for
> >>> + * anything except pseries. It was replaced by "max-cpu-compat"
> >>> + * machine option. This supports old command lines like
> >>> + * -cpu POWER8,compat=power7
> >>> + * By stripping the compat option and applying it to the machine
> >>> + * before passing it on to the cpu level parser.
> >>> + */
> >>> + gchar **inpieces, **outpieces;
> >>> + int n, i, j;
> >>> + gchar *compat_str = NULL;
> >>> + gchar *filtered_model;
> >>> +
> >>> + inpieces = g_strsplit(MACHINE(spapr)->cpu_model, ",", 0);
> >>> + n = g_strv_length(inpieces);
> >>> + outpieces = g_new0(gchar *, g_strv_length(inpieces));
> >>> +
> >>> + /* inpieces[0] is the actual model string */
> >>> + for (i = 0, j = 0; i < n; i++) {
> >>> + if (g_str_has_prefix(inpieces[i], "compat=")) {
> >>> + compat_str = inpieces[i];
> >>> + } else {
> >>> + outpieces[j++] = g_strdup(inpieces[i]);
> >>> + }
> >>> + }
> >>> +
> >>> + if (compat_str) {
> >>> + char *val = compat_str + strlen("compat=");
> >>> + object_property_set_str(OBJECT(spapr), val, "max-cpu-compat",
> >>> + &error_fatal);
> >>
> >> This part is ok.
> >>
> >>> + }
> >>> +
> >>> + filtered_model = g_strjoinv(",", outpieces);
> >>> + ppc_cpu_parse_features(filtered_model);
> >>
> >>
> >> Rather than reducing the CPU parameters string from the command line, I'd
> >> keep "dc->props = powerpc_servercpu_properties" and make them noop + warn
> >> to use the machine option instead. One day QEMU may start calling the CPU
> >> features parser itself and somebody will have to hack this thing
> >> again.
> >
> > Hrm. A deprecation message like that only works if a human is reading
> > it. Usually qemu will be invoked by libvirt and the message will
> > probably disappear into some log file to scare someone unnecessarily.
> >
> > Meanwhile, what will the actual behaviour be? Pulling the CPU's
> > property value into the machine instead would be really ugly.
> > Ignoring it would break users with existing libvirt.
>
>
> I only suggested instead of removing "compat=" from the model string,
> - pass the model as is to ppc_cpu_parse_features() with no changes;
> - change powerpc_set_compat() to print a message and do nothing else, and
> add a comment there saying why it is so.
Ah, right, now I understand. Yes, that's a good idea. It will
greatly simplify the rather hideous string mangling, too.
> > The hack above is nasty, but I'm not really seeing a better option.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: status of spdk
From: LIU, Fei @ 2016-11-09 5:02 UTC (permalink / raw)
To: Haomai Wang, Liu, Changpeng; +Cc: Yehuda Sadeh-Weinraub, Sage Weil, ceph-devel
In-Reply-To: <CACJqLybju4p+y08Uq5rFhhJ2h_pXMLTohr0t+6Lkg3EDQjQvRw@mail.gmail.com>
Haomai,
Thanks a lot.
Regards,
James
Hi Changpeng,
Would you mind updating us about the status of multi processes support of spdk?
Regards,
James
On 11/8/16, 8:59 PM, "Haomai Wang" <haomaiwang@gmail.com> wrote:
On Wed, Nov 9, 2016 at 8:21 AM, LIU, Fei <james.liu@alibaba-inc.com> wrote:
> Hi Yehuda and Haomai,
> The issue of drives driven by SPDK is not able to be shared by multiple OSDs as kernel NVMe drive since SPDK as a process so far can not be shared across multiple processes like OSDs, right?
spdk nvme supports multi process is a undergoing spdk feature now, it
will be implemented via shared memory among multi process.
>
> Regards,
> James
>
>
>
> On 11/8/16, 4:06 PM, "Yehuda Sadeh-Weinraub" <ceph-devel-owner@vger.kernel.org on behalf of yehuda@redhat.com> wrote:
>
> On Tue, Nov 8, 2016 at 3:40 PM, Sage Weil <sweil@redhat.com> wrote:
> > On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
> >> I just started looking at spdk, and have a few comments and questions.
> >>
> >> First, it's not clear to me how we should handle build. At the moment
> >> the spdk code resides as a submodule in the ceph tree, but it depends
> >> on dpdk, which currently needs to be downloaded separately. We can add
> >> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> >> said, getting it to build was a bit tricky and I think it might be
> >> broken with cmake. In order to get it working I resorted to building a
> >> system library and use that.
> >
> > Note that this PR is about to merge
> >
> > https://github.com/ceph/ceph/pull/10748
> >
> > which adds the DPDK submodule, so hopefully this issue will go away when
> > that merged or with a follow-on cleanup.
> >
> >> The way to currently configure an osd to use bluestore with spdk is by
> >> creating a symbolic link that replaces the bluestore 'block' device to
> >> point to a file that has a name that is prefixed with 'spdk:'.
> >> Originally I assumed that the suffix would be the nvme device id, but
> >> it seems that it's not really needed, however, the file itself needs
> >> to contain the device id (see
> >> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
> >> minor fixes).
> >
> > Open a PR for those?
>
> Sure
>
> >
> >> As I understand it, in order to support multiple osds on the same NVMe
> >> device we have a few options. We can leverage NVMe namespaces, but
> >> that's not supported on all devices. We can configure bluestore to
> >> only use part of the device (device sharding? not sure if it supports
> >> it). I think it's best if we could keep bluestore out of the loop
> >> there and have the NVMe driver abstract multiple partitions of the
> >> NVMe device. The idea is to be able to define multiple partitions on
> >> the device (e.g., each partition will be defined by the offset, size,
> >> and namespace), and have the osd set to use a specific partition.
> >> We'll probably need a special tool to manage it, and potentially keep
> >> the partition table information on the device itself. The tool could
> >> also manage the creation of the block link. We should probably rethink
> >> how the link is structure and what it points at.
> >
> > I agree that bluestore shouldn't get involved.
> >
> > Is the NVMe namespaces meant to support multiple processes sharing the
> > same hardware device?
>
> More of a partitioning solution, but yes (as far as I undestand).
>
> >
> > Also, if you do that, is it possible to give one of the namespaces to the
> > kernel? That might solve the bootstrapping problem we currently have
>
> Theoretically, but not right now (or ever?). See here:
>
> https://lists.01.org/pipermail/spdk/2016-July/000073.html
>
> > where we have nowhere to put the $osd_data filesystem with the device
> > metadata. (This is admittedly not necessarily a blocking issue. Putting
> > those dirs on / wouldn't be the end of the world; it just means cards
> > can't be easily moved between boxes.)
> >
>
> Maybe we can use bluestore for these too ;) that been said, there
> might be some kind of a loopback solution that could work, but not
> sure if it won't create major bottlenecks that we'd want to avoid.
>
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Best Regards,
Wheat
^ permalink raw reply
* Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs
From: kbuild test robot @ 2016-11-09 5:09 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, chrisw-69jw2NvuJkxg9hUCZPvPmw,
paul-r2n+y4ga6xFZroRs9YW3xA, sds-+05T5uksL2qpZYMLLGbcSA,
eparis-FjpueFixGhCM4zKIHC2jIg, dledford-H+wXaHxf7aLQT0dZR+AlfA,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w,
selinux-+05T5uksL2qpZYMLLGbcSA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
yevgenyp-VPRAkNaXOzVWk0Htik3J/w, liranl-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, Daniel Jurgens
In-Reply-To: <1478639185-47521-10-git-send-email-danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Hi Daniel,
[auto build test WARNING on rdma/master]
[also build test WARNING on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> security/selinux/ibpkey.c:116:24: sparse: incompatible types in comparison expression (different address spaces)
vim +116 security/selinux/ibpkey.c
100 * Description:
101 * Add a new pkey record to the hash table.
102 *
103 */
104 static void sel_pkey_insert(struct sel_pkey *pkey)
105 {
106 unsigned int idx;
107
108 /* we need to impose a limit on the growth of the hash table so check
109 * this bucket to make sure it is within the specified bounds
110 */
111 idx = sel_pkey_hashfn(pkey->psec.pkey);
112 list_add_rcu(&pkey->list, &sel_pkey_hash[idx].list);
113 if (sel_pkey_hash[idx].size == SEL_PKEY_HASH_BKT_LIMIT) {
114 struct sel_pkey *tail;
115
> 116 tail = list_entry(
117 rcu_dereference_protected(
118 sel_pkey_hash[idx].list.prev,
119 lockdep_is_held(&sel_pkey_lock)),
120 struct sel_pkey, list);
121 list_del_rcu(&tail->list);
122 kfree_rcu(tail, rcu);
123 } else {
124 sel_pkey_hash[idx].size++;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs
From: kbuild test robot @ 2016-11-09 5:09 UTC (permalink / raw)
To: Dan Jurgens
Cc: kbuild-all, chrisw, paul, sds, eparis, dledford, sean.hefty,
hal.rosenstock, selinux, linux-security-module, linux-rdma,
yevgenyp, liranl, leonro, Daniel Jurgens
In-Reply-To: <1478639185-47521-10-git-send-email-danielj@mellanox.com>
Hi Daniel,
[auto build test WARNING on rdma/master]
[also build test WARNING on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> security/selinux/ibpkey.c:116:24: sparse: incompatible types in comparison expression (different address spaces)
vim +116 security/selinux/ibpkey.c
100 * Description:
101 * Add a new pkey record to the hash table.
102 *
103 */
104 static void sel_pkey_insert(struct sel_pkey *pkey)
105 {
106 unsigned int idx;
107
108 /* we need to impose a limit on the growth of the hash table so check
109 * this bucket to make sure it is within the specified bounds
110 */
111 idx = sel_pkey_hashfn(pkey->psec.pkey);
112 list_add_rcu(&pkey->list, &sel_pkey_hash[idx].list);
113 if (sel_pkey_hash[idx].size == SEL_PKEY_HASH_BKT_LIMIT) {
114 struct sel_pkey *tail;
115
> 116 tail = list_entry(
117 rcu_dereference_protected(
118 sel_pkey_hash[idx].list.prev,
119 lockdep_is_held(&sel_pkey_lock)),
120 struct sel_pkey, list);
121 list_del_rcu(&tail->list);
122 kfree_rcu(tail, rcu);
123 } else {
124 sel_pkey_hash[idx].size++;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* RE: status of spdk
From: Liu, Changpeng @ 2016-11-09 5:09 UTC (permalink / raw)
To: LIU, Fei, Haomai Wang
Cc: Yehuda Sadeh-Weinraub, Sage Weil, ceph-devel, Cao, Gang,
Yang, Ziye, Dai, Qihua, Harris, James R
In-Reply-To: <7E8F4A68-9D8E-4E4A-B3C3-1D0EF5278590@alibaba-inc.com>
Hi James,
Yes, the multi processes support of SPDK is under development, Gang is the developer for the feature of SPDK.
We are targeting to release the feature in 16.12 version for SPDK(WW50).
> -----Original Message-----
> From: LIU, Fei [mailto:james.liu@alibaba-inc.com]
> Sent: Wednesday, November 9, 2016 1:03 PM
> To: Haomai Wang <haomaiwang@gmail.com>; Liu, Changpeng
> <changpeng.liu@intel.com>
> Cc: Yehuda Sadeh-Weinraub <yehuda@redhat.com>; Sage Weil
> <sweil@redhat.com>; ceph-devel <ceph-devel@vger.kernel.org>
> Subject: Re: status of spdk
>
> Haomai,
> Thanks a lot.
>
> Regards,
> James
>
> Hi Changpeng,
> Would you mind updating us about the status of multi processes support of
> spdk?
>
> Regards,
> James
>
> On 11/8/16, 8:59 PM, "Haomai Wang" <haomaiwang@gmail.com> wrote:
>
> On Wed, Nov 9, 2016 at 8:21 AM, LIU, Fei <james.liu@alibaba-inc.com> wrote:
> > Hi Yehuda and Haomai,
> > The issue of drives driven by SPDK is not able to be shared by multiple OSDs
> as kernel NVMe drive since SPDK as a process so far can not be shared across
> multiple processes like OSDs, right?
>
> spdk nvme supports multi process is a undergoing spdk feature now, it
> will be implemented via shared memory among multi process.
>
> >
> > Regards,
> > James
> >
> >
> >
> > On 11/8/16, 4:06 PM, "Yehuda Sadeh-Weinraub" <ceph-devel-
> owner@vger.kernel.org on behalf of yehuda@redhat.com> wrote:
> >
> > On Tue, Nov 8, 2016 at 3:40 PM, Sage Weil <sweil@redhat.com> wrote:
> > > On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
> > >> I just started looking at spdk, and have a few comments and questions.
> > >>
> > >> First, it's not clear to me how we should handle build. At the moment
> > >> the spdk code resides as a submodule in the ceph tree, but it depends
> > >> on dpdk, which currently needs to be downloaded separately. We can
> add
> > >> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> > >> said, getting it to build was a bit tricky and I think it might be
> > >> broken with cmake. In order to get it working I resorted to building a
> > >> system library and use that.
> > >
> > > Note that this PR is about to merge
> > >
> > > https://github.com/ceph/ceph/pull/10748
> > >
> > > which adds the DPDK submodule, so hopefully this issue will go away
> when
> > > that merged or with a follow-on cleanup.
> > >
> > >> The way to currently configure an osd to use bluestore with spdk is by
> > >> creating a symbolic link that replaces the bluestore 'block' device to
> > >> point to a file that has a name that is prefixed with 'spdk:'.
> > >> Originally I assumed that the suffix would be the nvme device id, but
> > >> it seems that it's not really needed, however, the file itself needs
> > >> to contain the device id (see
> > >> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple
> of
> > >> minor fixes).
> > >
> > > Open a PR for those?
> >
> > Sure
> >
> > >
> > >> As I understand it, in order to support multiple osds on the same NVMe
> > >> device we have a few options. We can leverage NVMe namespaces, but
> > >> that's not supported on all devices. We can configure bluestore to
> > >> only use part of the device (device sharding? not sure if it supports
> > >> it). I think it's best if we could keep bluestore out of the loop
> > >> there and have the NVMe driver abstract multiple partitions of the
> > >> NVMe device. The idea is to be able to define multiple partitions on
> > >> the device (e.g., each partition will be defined by the offset, size,
> > >> and namespace), and have the osd set to use a specific partition.
> > >> We'll probably need a special tool to manage it, and potentially keep
> > >> the partition table information on the device itself. The tool could
> > >> also manage the creation of the block link. We should probably rethink
> > >> how the link is structure and what it points at.
> > >
> > > I agree that bluestore shouldn't get involved.
> > >
> > > Is the NVMe namespaces meant to support multiple processes sharing
> the
> > > same hardware device?
> >
> > More of a partitioning solution, but yes (as far as I undestand).
> >
> > >
> > > Also, if you do that, is it possible to give one of the namespaces to the
> > > kernel? That might solve the bootstrapping problem we currently have
> >
> > Theoretically, but not right now (or ever?). See here:
> >
> > https://lists.01.org/pipermail/spdk/2016-July/000073.html
> >
> > > where we have nowhere to put the $osd_data filesystem with the device
> > > metadata. (This is admittedly not necessarily a blocking issue. Putting
> > > those dirs on / wouldn't be the end of the world; it just means cards
> > > can't be easily moved between boxes.)
> > >
> >
> > Maybe we can use bluestore for these too ;) that been said, there
> > might be some kind of a loopback solution that could work, but not
> > sure if it won't create major bottlenecks that we'd want to avoid.
> >
> > Yehuda
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> >
>
>
>
> --
> Best Regards,
>
> Wheat
>
>
^ permalink raw reply
* [PATCHv2 1/2] gpio: xilinx: dt-binding: Add clock node
From: Shubhrajyoti Datta @ 2016-11-09 5:09 UTC (permalink / raw)
To: linux-gpio, devicetree
Cc: soren.brinkmann, michal.simek, shubhrajyoti.datta,
Shubhrajyoti Datta
Add the clock node to the dt binding.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
---
v2:
Make clocks optional
Add clock name
.../devicetree/bindings/gpio/gpio-xilinx.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
index 63bf4be..1372007 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
@@ -25,12 +25,16 @@ Optional properties:
- xlnx,dout-default-2 : as above but the second channel
- xlnx,gpio2-width : as above but for the second channel
- xlnx,tri-default-2 : as above but for the second channel
+- clocks: Input clock specifier. Refer to common clock bindings.
+- clock-names: Input clock name, should be s_axi_aclk.
Example:
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
+ clocks = <&clkc 15>;
+ clock-names = "s_axi_aclk";
gpio-controller ;
interrupt-parent = <µblaze_0_intc>;
interrupts = < 6 2 >;
--
1.7.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] spapr: Fix migration of PCI host bridges from qemu-2.7
From: Alexey Kardashevskiy @ 2016-11-09 5:14 UTC (permalink / raw)
To: David Gibson, mdroth; +Cc: agraf, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <1478663122-29357-1-git-send-email-david@gibson.dropbear.id.au>
On 09/11/16 14:45, David Gibson wrote:
> daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from
> qemu-2.7 to the current version. It split the device's MMIO window into
> two pieces for 32-bit and 64-bit MMIO.
>
> The patch included backwards compatibility code to convert the old property
> into the new format. However, the property value was also transferred in
> the migration stream and compared with a (probably unwise) VMSTATE_EQUAL.
> So, the "raw" value from 2.7 is compared to the new style converted value
> from (pre-)2.8 giving a mismatch and migration failure.
>
> Although it would be technically possible to fix this in a way allowing
> backwards migration, that would leave an ugly legacy around indefinitely.
> This patch takes the simpler approach of bumping the migration version,
> dropping the unwise VMSTATE_EQUAL (and some equally unwise ones around it)
> and ignoring them on an incoming migration.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> hw/ppc/spapr_pci.c | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 7cde30e..7f1cc29 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1658,19 +1658,24 @@ static int spapr_pci_post_load(void *opaque, int version_id)
> return 0;
> }
>
> +static bool version_before_3(void *opaque, int version_id)
> +{
> + return version_id < 3;
> +}
> +
> static const VMStateDescription vmstate_spapr_pci = {
> .name = "spapr_pci",
> - .version_id = 2,
> + .version_id = 3,
> .minimum_version_id = 2,
> .pre_save = spapr_pci_pre_save,
> .post_load = spapr_pci_post_load,
> .fields = (VMStateField[]) {
> VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
You could probably go one step further and get rid of @buid as well.
Nevertheless, this works,
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> - VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
> - VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
> - VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
> - VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
> - VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
> + VMSTATE_UNUSED_TEST(version_before_3, sizeof(uint32_t) /* dma_liobn[0] */
> + + sizeof(uint64_t) /* mem_win_addr */
> + + sizeof(uint64_t) /* mem_win_size */
> + + sizeof(uint64_t) /* io_win_addr */
> + + sizeof(uint64_t) /* io_win_size */),
> VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
> vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
> VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
>
--
Alexey
^ permalink raw reply
* Re: [PATCH v5 00/12] ufs-qcom: phy/hcd: Clean up qcom-ufs phy and ufs-qcom hcd
From: Vivek Gautam @ 2016-11-09 5:16 UTC (permalink / raw)
To: Martin K. Petersen
Cc: kishon, jejb, Vinayak Holikatti, Stephen Boyd, Subhash Jadavani,
Yaniv Gardi, linux-scsi, linux-arm-msm
In-Reply-To: <yq1r36lr2q6.fsf@sermon.lab.mkp.net>
On Wed, Nov 9, 2016 at 4:36 AM, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>>>>>> "Vivek" == Vivek Gautam <vivek.gautam@codeaurora.org> writes:
>
> Vivek> Here's the rebased version of patches based on 4.10/scsi-queue
> Vivek> branch as requested. The patches can now be applied and
> Vivek> pulled-in.
>
> Thanks! Applied to 4.10/scsi-queue.
Thanks Martin.
Regards
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] cpupower: Warn if values are truncated in frequency-info
From: Akshay Adiga @ 2016-11-09 5:17 UTC (permalink / raw)
To: trenn, rafael.j.wysocki, jtanenba, linux-pm, linux-kernel; +Cc: Akshay Adiga
frequency-info currently rounds the frequnecy values to 2 decimal places
while printing "available frequency steps". Hence frequencies with 3rd
decimal place being greater than 5 will be rounded to next higher number
like 2.227GHz will be rounded to 2.23Ghz. On setting this frequency,
using "cpupower frequency-set -f <freq>" ,if the value does not match,
then it will set to the next lowest frequency greater than provided
frequency value (according to the userspace governor).
Hence adding a warning if there are any cases where the displayed
frequency cannot be used directly to set a perticular frequency, and
insist the user to use the "-n" option.
Simple usecase where it give counter intuitive results :
bash# cpupower frequency-info
...
available frequency steps: 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz,
2.29 GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz
bash# cpupower frequency-info -n
...
available frequency steps: 2.427000 GHz, 2.394000 GHz, 2.360000 GHz,
2.327000 GHz, 2.294000 GHz, 2.261000 GHz, 2.227000 GHz, 2.194000 GHz,
2.161000 GHz, 2.128000 GHz
bash# cpupower frequency-set -f 2.23Ghz
bash# cpupower frequency-info
...
current CPU frequency: 2.26 GHz (asserted by call to hardware)
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
---
tools/power/cpupower/utils/cpufreq-info.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/power/cpupower/utils/cpufreq-info.c b/tools/power/cpupower/utils/cpufreq-info.c
index 590d12a..4f13b06 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -85,6 +85,7 @@ static void proc_cpufreq_output(void)
}
static int no_rounding;
+static int freq_info_truncated;
static void print_speed(unsigned long speed)
{
unsigned long tmp;
@@ -103,8 +104,10 @@ static void print_speed(unsigned long speed)
} else {
if (speed > 1000000) {
tmp = speed%10000;
- if (tmp >= 5000)
+ if (tmp >= 5000) {
+ freq_info_truncated = 1;
speed += 10000;
+ }
printf("%u.%02u GHz", ((unsigned int) speed/1000000),
((unsigned int) (speed%1000000)/10000));
} else if (speed > 100000) {
@@ -243,6 +246,7 @@ static int get_boost_mode(unsigned int cpu)
printf(_(" %.0f MHz max turbo 1 active cores\n"),
ratio * bclk);
}
+
return 0;
}
@@ -641,5 +645,12 @@ int cmd_freq_info(int argc, char **argv)
return ret;
printf("\n");
}
+
+ if (freq_info_truncated) {
+ printf(" Warning! Frequency values shown are rounded off\n");
+ printf(" To set frequency use frequency values provided\n");
+ printf(" by \"cpupower frequency-info -n \"\n");
+ }
+
return ret;
}
--
2.5.5
^ permalink raw reply related
* Re: [Qemu-devel] [RFC 11/17] ppc: Add ppc_set_compat_all()
From: Alexey Kardashevskiy @ 2016-11-09 5:18 UTC (permalink / raw)
To: David Gibson; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <20161109035229.GD427@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 7349 bytes --]
On 09/11/16 14:52, David Gibson wrote:
> On Wed, Nov 09, 2016 at 12:27:47PM +1100, Alexey Kardashevskiy wrote:
>> On 08/11/16 16:18, David Gibson wrote:
>>> On Fri, Nov 04, 2016 at 03:01:40PM +1100, Alexey Kardashevskiy wrote:
>>>> On 30/10/16 22:12, David Gibson wrote:
>>>>> Once a compatiblity mode is negotiated with the guest,
>>>>> h_client_architecture_support() uses run_on_cpu() to update each CPU to
>>>>> the new mode. We're going to want this logic somewhere else shortly,
>>>>> so make a helper function to do this global update.
>>>>>
>>>>> We put it in target-ppc/compat.c - it makes as much sense at the CPU level
>>>>> as it does at the machine level. We also move the cpu_synchronize_state()
>>>>> into ppc_set_compat(), since it doesn't really make any sense to call that
>>>>> without synchronizing state.
>>>>>
>>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>>> ---
>>>>> hw/ppc/spapr_hcall.c | 31 +++++--------------------------
>>>>> target-ppc/compat.c | 36 ++++++++++++++++++++++++++++++++++++
>>>>> target-ppc/cpu.h | 3 +++
>>>>> 3 files changed, 44 insertions(+), 26 deletions(-)
>>>>>
>>>>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>>>>> index 3bd6d06..4eaf9a6 100644
>>>>> --- a/hw/ppc/spapr_hcall.c
>>>>> +++ b/hw/ppc/spapr_hcall.c
>>>>> @@ -881,20 +881,6 @@ static target_ulong h_set_mode(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>>>> return ret;
>>>>> }
>>>>>
>>>>> -typedef struct {
>>>>> - uint32_t compat_pvr;
>>>>> - Error *err;
>>>>> -} SetCompatState;
>>>>> -
>>>>> -static void do_set_compat(CPUState *cs, void *arg)
>>>>> -{
>>>>> - PowerPCCPU *cpu = POWERPC_CPU(cs);
>>>>> - SetCompatState *s = arg;
>>>>> -
>>>>> - cpu_synchronize_state(cs);
>>>>> - ppc_set_compat(cpu, s->compat_pvr, &s->err);
>>>>> -}
>>>>> -
>>>>> static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>>>> sPAPRMachineState *spapr,
>>>>> target_ulong opcode,
>>>>> @@ -902,7 +888,6 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>>>> {
>>>>> target_ulong list = ppc64_phys_to_real(args[0]);
>>>>> target_ulong ov_table;
>>>>> - CPUState *cs;
>>>>> bool explicit_match = false; /* Matched the CPU's real PVR */
>>>>> uint32_t max_compat = cpu->max_compat;
>>>>> uint32_t best_compat = 0;
>>>>> @@ -949,18 +934,12 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>>>>
>>>>> /* Update CPUs */
>>>>> if (cpu->compat_pvr != best_compat) {
>>>>> - CPU_FOREACH(cs) {
>>>>> - SetCompatState s = {
>>>>> - .compat_pvr = best_compat,
>>>>> - .err = NULL,
>>>>> - };
>>>>> + Error *local_err = NULL;
>>>>>
>>>>> - run_on_cpu(cs, do_set_compat, &s);
>>>>> -
>>>>> - if (s.err) {
>>>>> - error_report_err(s.err);
>>>>> - return H_HARDWARE;
>>>>> - }
>>>>> + ppc_set_compat_all(best_compat, &local_err);
>>>>> + if (local_err) {
>>>>> + error_report_err(local_err);
>>>>> + return H_HARDWARE;
>>>>> }
>>>>> }
>>>>>
>>>>> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
>>>>> index 1059555..0b12b58 100644
>>>>> --- a/target-ppc/compat.c
>>>>> +++ b/target-ppc/compat.c
>>>>> @@ -124,6 +124,8 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
>>>>> pcr = compat->pcr;
>>>>> }
>>>>>
>>>>> + cpu_synchronize_state(CPU(cpu));
>>>>> +
>>>>> cpu->compat_pvr = compat_pvr;
>>>>> env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
>>>>>
>>>>> @@ -136,6 +138,40 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
>>>>> }
>>>>> }
>>>>>
>>>>> +#if !defined(CONFIG_USER_ONLY)
>>>>> +typedef struct {
>>>>> + uint32_t compat_pvr;
>>>>> + Error *err;
>>>>> +} SetCompatState;
>>>>> +
>>>>> +static void do_set_compat(CPUState *cs, void *arg)
>>>>> +{
>>>>> + PowerPCCPU *cpu = POWERPC_CPU(cs);
>>>>> + SetCompatState *s = arg;
>>>>> +
>>>>> + ppc_set_compat(cpu, s->compat_pvr, &s->err);
>>>>> +}
>>>>> +
>>>>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp)
>>>>> +{
>>>>> + CPUState *cs;
>>>>> +
>>>>> + CPU_FOREACH(cs) {
>>>>> + SetCompatState s = {
>>>>> + .compat_pvr = compat_pvr,
>>>>> + .err = NULL,
>>>>> + };
>>>>> +
>>>>> + run_on_cpu(cs, do_set_compat, &s);
>>>>> +
>>>>> + if (s.err) {
>>>>> + error_propagate(errp, s.err);
>>>>> + return;
>>>>> + }
>>>>> + }
>>>>> +}
>>>>> +#endif
>>>>> +
>>>>> int ppc_compat_max_threads(PowerPCCPU *cpu)
>>>>> {
>>>>> const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
>>>>> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
>>>>> index 91e8be8..201a655 100644
>>>>> --- a/target-ppc/cpu.h
>>>>> +++ b/target-ppc/cpu.h
>>>>> @@ -1317,6 +1317,9 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool ifetch)
>>>>> bool ppc_check_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
>>>>> uint32_t min_compat_pvr, uint32_t max_compat_pvr);
>>>>> void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp);
>>>>> +#if !defined(CONFIG_USER_ONLY)
>>>>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp);
>>>>> +#endif
>>>>
>>>> I would put all ppc*compat*() under #if defined(CONFIG_USER_ONLY) &&
>>>> defined(TARGET_PPC64) (or even moved this to target-ppc/Makefile.objs).
>>>
>>> I was originally going to do that, but decided against it.
>>>
>>>> Otherwise, functions like ppc_check_compat() have #if
>>>> !defined(CONFIG_USER_ONLY) which suggests that the rest of
>>>> ppc_check_compat() can actually be executed in ppc64-linux-user (while it
>>>> cannot, can it?).
>>>
>>> It won't be, but there's no theoretical reason they couldn't be. User
>>> mode, like spapr, doesn't execute hypervisor privilege code, and so
>>> the PCR isn't owned by the "guest" (if you can call the user mode
>>> executable that). Which means it could make sense to set it from the
>>> outside, although that's not something we currently do.
>>
>> Compatibility modes are designed to disable sets of instructions to keep
>> working old userspace software which relies on some opcodes to be invalid.
>>
>> linux-user is TCG, right? The user can pick any CPU he likes if there is
>> need to run such an old software, why on earth would anyone bother with
>> this compat mode in linux-user?
>
> True, I can't really see any reason to do that.
>
> On the other hand, compat mode does at least make theoretical sense,
> whereas, for example, compat mode on powernv is fundamentally
> nonsense. At this point I'm not terribly include to take away the
> (token) user-only support unless there's a compelling reason *not* to
> include it.
What would make a compelling reason? :)
This will make makefile simpler and will reduce number of #ifdef, and in
fact it is not supported now anyway, it has not even been tried.
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 839 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.