Re: [patch for-4.7] mm, compaction: prevent VM_BUG_ON when terminating freeing scanner
On Wed, Jun 29, 2016 at 02:47:20PM -0700, David Rientjes wrote: > It's possible to isolate some freepages in a pageblock and then fail > split_free_page() due to the low watermark check. In this case, we hit > VM_BUG_ON() because the freeing scanner terminated early without a > contended lock or enough freepages. > > This should never have been a VM_BUG_ON() since it's not a fatal > condition. It should have been a VM_WARN_ON() at best, or even handled > gracefully. > > Regardless, we need to terminate anytime the full pageblock scan was not > done. The logic belongs in isolate_freepages_block(), so handle its state > gracefully by terminating the pageblock loop and making a note to restart > at the same pageblock next time since it was not possible to complete the > scan this time. > > Reported-by: Minchan Kim > Signed-off-by: David Rientjes Tested-by: Minchan Kim I don't know you sill send updated version based on Joonsoo again. Anyway, this patch itself doesn't trigger VM_BUG_ON in my test. Thanks.
Re: [PATCH v2 0/4] implement vcpu preempted check
On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: > change fomr v1: > a simplier definition of default vcpu_is_preempted > skip mahcine type check on ppc, and add config. remove dedicated macro. > add one patch to drop overload of rwsem_spin_on_owner and > mutex_spin_on_owner. > add more comments > thanks boqun and Peter's suggestion. > > This patch set aims to fix lock holder preemption issues. > > test-case: > perf record -a perf bench sched messaging -g 400 -p && perf report > > 18.09% sched-messaging [kernel.vmlinux] [k] osq_lock > 12.28% sched-messaging [kernel.vmlinux] [k] rwsem_spin_on_owner > 5.27% sched-messaging [kernel.vmlinux] [k] mutex_unlock > 3.89% sched-messaging [kernel.vmlinux] [k] wait_consider_task > 3.64% sched-messaging [kernel.vmlinux] [k] _raw_write_lock_irq > 3.41% sched-messaging [kernel.vmlinux] [k] mutex_spin_on_owner.is > 2.49% sched-messaging [kernel.vmlinux] [k] system_call > > We introduce interface bool vcpu_is_preempted(int cpu) and use it in some spin > loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner. > These spin_on_onwer variant also cause rcu stall before we apply this patch > set > Paolo, could you help out with an (x86) KVM interface for this? Waiman, could you see if you can utilize this to get rid of the SPIN_THRESHOLD in qspinlock_paravirt?
[PATCH] samples/seccomp: Add standalone config option
Add a separate Kconfig option for SAMPLES_SECCOMP. Main reason for this is that, just like other samples, it's forced to be a module. Without this, since the sample is a target only controlled by CONFIG_SECCOMP_FILTER, the samples will be built before include files are put in place properly. For example, from an arm64 allmodconfig built with "make -sk -j 32" (without specific target), the following happens: samples/seccomp/bpf-fancy.c:13:27: fatal error: linux/seccomp.h: No such file or directory samples/seccomp/bpf-helper.h:20:50: fatal error: linux/seccomp.h: No such file or directory samples/seccomp/dropper.c:20:27: fatal error: linux/seccomp.h: No such file or directory samples/seccomp/bpf-direct.c:21:27: fatal error: linux/seccomp.h: No such file or directory So, just stick to the same format as other samples. Signed-off-by: Olof Johansson --- samples/Kconfig | 7 +++ samples/seccomp/Makefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) Hi Kees, This has been showing up for a while on my builder, and I finally had a bit of time to sit down and look at it. It'd be nice to see this in 4.7, but please consider for 4.8 at the least. Thanks! -Olof diff --git a/samples/Kconfig b/samples/Kconfig index 559a58b..ccc50be 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -85,4 +85,11 @@ config SAMPLE_CONNECTOR with it. See also Documentation/connector/connector.txt +config SAMPLE_SECCOMP + tristate "Build seccomp sample code -- loadable modules only" + depends on SECCOMP_FILTER && m + help + Build samples of seccomp filters using various methods of + BPF filter construction. + endif # SAMPLES diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile index 1b4e4b8..ae7ff6f 100644 --- a/samples/seccomp/Makefile +++ b/samples/seccomp/Makefile @@ -1,7 +1,7 @@ # kbuild trick to avoid linker error. Can be omitted if a module is built. obj- := dummy.o -hostprogs-$(CONFIG_SECCOMP_FILTER) := bpf-fancy dropper bpf-direct +hostprogs-$(CONFIG_SAMPLE_SECCOMP) := bpf-fancy dropper bpf-direct HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include HOSTCFLAGS_bpf-fancy.o += -idirafter $(objtree)/include -- 2.8.0.rc3.29.gb552ff8
Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220
On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson wrote: > On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote: >> This patchset enables the pl031 RTC on the Hi6220 SoC. >> >> I'd like to submit it to be merged. >> >> Wei has acked the second patch (modulo a whitespace fix which >> I've included in this v3), so it seems like both could go >> through the clk tree. >> >> But Wei also seemed open to pulling in a clk tree branch >> as it goes through arm-soc. >> >> Michael/Stephen: If there's no other objections, could you >> queue the first patch and make it avilable via the branch for >> Wei, or just take both patches? > > I happen to dread these kind of patchsets these days. There's added > dependencies across trees just because a defined name for the clock > number is added to a header file. > > I much prefer to use numerical clocks for one release, and then once > everything is in, switch over to the defines in the DTS. > > That way there are no dependencies, no need to setup a shared branch > for a simple 3-line patch, etc. > > So, mind respinning the DTS piece? Huh.. But trying to boot w/ the numerical clock in the DTS, without the clk change results in lots of noise: [ 116.491458] of_clk_src_onecell_get: invalid clock index 37 [ 116.511627] of_clk_src_onecell_get: invalid clock index 38 Is that acceptable? thanks -john
[PATCH v4 1/7] xen-pciback: drop unused function parameter of read_dev_bar()
Signed-off-by: Jan Beulich --- drivers/xen/xen-pciback/conf_space_header.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) --- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c @@ -210,8 +210,7 @@ static int bar_read(struct pci_dev *dev, } static inline void read_dev_bar(struct pci_dev *dev, - struct pci_bar_info *bar_info, int offset, - u32 len_mask) + struct pci_bar_info *bar_info, int offset) { int pos; struct resource *res = dev->resource; @@ -248,7 +247,7 @@ static void *bar_init(struct pci_dev *de if (!bar) return ERR_PTR(-ENOMEM); - read_dev_bar(dev, bar, offset, ~0); + read_dev_bar(dev, bar, offset); return bar; } @@ -260,7 +259,7 @@ static void *rom_init(struct pci_dev *de if (!bar) return ERR_PTR(-ENOMEM); - read_dev_bar(dev, bar, offset, ~PCI_ROM_ADDRESS_ENABLE); + read_dev_bar(dev, bar, offset); return bar; }
Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering
On Tue, Jul 05, 2016 at 07:57:07PM -0700, Viresh Kumar wrote: > The i2c-dev calls i2c_get_adapter() from the .open() callback, which > doesn't let the adapter device unregister unless the .close() callback > is called. > > On some platforms (like Google ARA), this doesn't let the modules > (hardware attached to the phone) eject from the phone as the cleanup > path for the module hasn't finished yet (i2c adapter not removed). > > We can't let the userspace block the kernel forever in such cases. > > Fix this by calling i2c_get_adapter() from all other file operations, > i.e. read/write/ioctl, to make sure the adapter doesn't get away while > we are in the middle of a operation, but not otherwise. In .open() we > will release the adapter device before returning and so if there is no > data transfer in progress, then the i2c-dev doesn't block the adapter > from unregistering. > > Signed-off-by: Viresh Kumar I'd think Jean has more experience with I2C hotplugging approaches and difficulties, so I'd be interested in his high level review. However: > @@ -234,6 +234,7 @@ struct i2c_client { > struct i2c_adapter *adapter;/* the adapter we sit on*/ > struct device dev; /* the device structure */ > int irq;/* irq issued by device */ > + int adapter_nr; > struct list_head detected; Adding something to *every* i2c_client for this corner case sounds pretty expensive to me. Regards, Wolfram signature.asc Description: PGP signature
[PATCH v4 2/7] xen-pciback: drop rom_init()
It is now identical to bar_init(). Signed-off-by: Jan Beulich --- drivers/xen/xen-pciback/conf_space_header.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) --- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c @@ -252,18 +252,6 @@ static void *bar_init(struct pci_dev *de return bar; } -static void *rom_init(struct pci_dev *dev, int offset) -{ - struct pci_bar_info *bar = kzalloc(sizeof(*bar), GFP_KERNEL); - - if (!bar) - return ERR_PTR(-ENOMEM); - - read_dev_bar(dev, bar, offset); - - return bar; -} - static void bar_reset(struct pci_dev *dev, int offset, void *data) { struct pci_bar_info *bar = data; @@ -382,7 +370,7 @@ static const struct config_field header_ { \ .offset = reg_offset, \ .size = 4,\ - .init = rom_init, \ + .init = bar_init, \ .reset = bar_reset,\ .release= bar_release, \ .u.dw.read = bar_read, \
[PATCH v4 3/7] xen-pciback: fold read_dev_bar() into its now single caller
Signed-off-by: Jan Beulich --- drivers/xen/xen-pciback/conf_space_header.c | 33 +++- 1 file changed, 13 insertions(+), 20 deletions(-) --- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c @@ -209,11 +209,14 @@ static int bar_read(struct pci_dev *dev, return 0; } -static inline void read_dev_bar(struct pci_dev *dev, - struct pci_bar_info *bar_info, int offset) +static void *bar_init(struct pci_dev *dev, int offset) { int pos; struct resource *res = dev->resource; + struct pci_bar_info *bar = kzalloc(sizeof(*bar), GFP_KERNEL); + + if (!bar) + return ERR_PTR(-ENOMEM); if (offset == PCI_ROM_ADDRESS || offset == PCI_ROM_ADDRESS1) pos = PCI_ROM_RESOURCE; @@ -223,31 +226,21 @@ static inline void read_dev_bar(struct p PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == (PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64))) { - bar_info->val = res[pos - 1].start >> 32; - bar_info->len_val = -resource_size(&res[pos - 1]) >> 32; - return; + bar->val = res[pos - 1].start >> 32; + bar->len_val = -resource_size(&res[pos - 1]) >> 32; + return bar; } } if (!res[pos].flags || (res[pos].flags & (IORESOURCE_DISABLED | IORESOURCE_UNSET | IORESOURCE_BUSY))) - return; - - bar_info->val = res[pos].start | - (res[pos].flags & PCI_REGION_FLAG_MASK); - bar_info->len_val = -resource_size(&res[pos]) | - (res[pos].flags & PCI_REGION_FLAG_MASK); -} - -static void *bar_init(struct pci_dev *dev, int offset) -{ - struct pci_bar_info *bar = kzalloc(sizeof(*bar), GFP_KERNEL); - - if (!bar) - return ERR_PTR(-ENOMEM); + return bar; - read_dev_bar(dev, bar, offset); + bar->val = res[pos].start | + (res[pos].flags & PCI_REGION_FLAG_MASK); + bar->len_val = -resource_size(&res[pos]) | + (res[pos].flags & PCI_REGION_FLAG_MASK); return bar; }
[PATCH v4 4/7] xen-pciback: simplify determination of 64-bit memory resource
Other than for raw BAR values, flags are properly separated in the internal representation. Signed-off-by: Jan Beulich --- drivers/xen/xen-pciback/conf_space_header.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c @@ -222,10 +222,7 @@ static void *bar_init(struct pci_dev *de pos = PCI_ROM_RESOURCE; else { pos = (offset - PCI_BASE_ADDRESS_0) / 4; - if (pos && ((res[pos - 1].flags & (PCI_BASE_ADDRESS_SPACE | - PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == - (PCI_BASE_ADDRESS_SPACE_MEMORY | - PCI_BASE_ADDRESS_MEM_TYPE_64))) { + if (pos && (res[pos - 1].flags & IORESOURCE_MEM_64)) { bar->val = res[pos - 1].start >> 32; bar->len_val = -resource_size(&res[pos - 1]) >> 32; return bar;
[PATCH v4 5/7] xen-pciback: use const and unsigned in bar_init()
Signed-off-by: Jan Beulich --- drivers/xen/xen-pciback/conf_space_header.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c +++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c @@ -211,8 +211,8 @@ static int bar_read(struct pci_dev *dev, static void *bar_init(struct pci_dev *dev, int offset) { - int pos; - struct resource *res = dev->resource; + unsigned int pos; + const struct resource *res = dev->resource; struct pci_bar_info *bar = kzalloc(sizeof(*bar), GFP_KERNEL); if (!bar)