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)
