On 10/3/17 12:37 AM, cjacob wrote:
> diff --git a/samples/bpf/xdp3_kern.c b/samples/bpf/xdp3_kern.c
> new file mode 100644
> index 000..62d905d
> --- /dev/null
> +++ b/samples/bpf/xdp3_kern.c
> @@ -0,0 +1,204 @@
> +/* Copyright (c) 2016 PLUMgrid
2016 PLUMgrid?
> + *
> + * This program is fre
On Tue, Oct 03, 2017 at 10:05:38AM -0500, Josh Poimboeuf wrote:
> I don't know the lockdep code, but one more comment from the peanut
> gallery. This code looks suspect to me:
>
>
> /*
>* Stop saving stack_trace if save_trace() was
>
On Mon, Oct 2, 2017 at 6:56 AM, Kai-Heng Feng
wrote:
> peaq-wmi on Lenovo ideapad 700-15ISK keeps sending KEY_SOUND,
> which makes user's repeated keys gets interrupted.
>
> The system does not have Dolby button, let's blacklist it.
Pushed to my review queue, thanks!
P.S. It's not going to stabl
On Thu, Sep 21, 2017 at 05:47:42PM +0530, suni...@techveda.org wrote:
> From: Suniel Mahesh
>
> Platform devices are expected to use wrapper functions,
> platform_{get,set}_drvdata() with platform_device as argument,
> for getting and setting the driver data. dev_{get,set}_drvdata()
> are using &
On Tue, Oct 3, 2017 at 9:44 PM, Greg KH wrote:
> On Sat, Sep 30, 2017 at 12:49:00PM +0530, Srishti Sharma wrote:
>> Replaces instances of container_of with list_entry to
>> access current list element.
>>
>> Srishti Sharma (6):
>> Staging: rtl8188eu: core: Use list_entry instead of container_of
On Wed, Sep 27, 2017 at 06:16:18PM +0100, Alfonso Lima Astor wrote:
> sparse was complaning about an incorrect type cast:
> drivers/staging/fbtft/fbtft-bus.c:60:1: warning: incorrect type in assignment
> (different base types)
> drivers/staging/fbtft/fbtft-bus.c:60:1:expected unsigned short [u
On Tue, Oct 3, 2017 at 9:06 AM, Dmitry Vyukov wrote:
> On Tue, Oct 3, 2017 at 5:38 PM, 'Eric Dumazet' via syzkaller
> wrote:
>> On Tue, Oct 3, 2017 at 8:19 AM, Dmitry Vyukov wrote:
>>> On Mon, Oct 2, 2017 at 4:42 PM, 'Eric Dumazet' via syzkaller
>>> wrote:
On Mon, Oct 2, 2017 at 7:21 AM, M
Linus Torvalds writes:
> On Tue, Oct 3, 2017 at 7:46 AM, Eric W. Biederman
> wrote:
>>
>> The process that requests the signal be sent is the process that is
>> receiving the signal. I can see a theoretical need for a permission
>> check in there somewhere (especially as this persists over for
10-02 13:58:12 -0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-core-for-mingo-4.15-20171003
>
> for you to fetch changes up to f6a9820d572bd8384d982357cba
> -Original Message-
> From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Rafael J.
> Wysocki
> Sent: Tuesday, October 3, 2017 9:05 AM
> To: Colin Ian King
> Cc: Wysocki, Rafael J ; Rafael J. Wysocki
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; ACPI Devel Maling List
On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote:
> That essay is full of shit, and you've even mentioned parts of that just
> above...
> NAK; you'd _still_ need proper quoting (or a shell with something resembling
> an
> actual syntax, rather than the "more or less what srb had ended up
On 10/3/2017 9:17 AM, Grygorii Strashko wrote:
Now acking of edge irqs happens the following way:
- omap_gpio_irq_handler
- "isr" = read irq status
- omap_clear_gpio_irqbank(bank, isr_saved & ~level_mask);
^ clear edge status, so irq can be accepted
- loop while "isr"
g
On Tue, Oct 03, 2017 at 10:26:06AM -0400, Zi Yan wrote:
> From: Zi Yan
>
> A non present pmd entry can appear after pmd_lock is taken in
> page_vma_mapped_walk(), even if THP migration is not enabled.
> The WARN_ONCE is unnecessary.
>
> Fixes: 616b8371539a ("mm: thp: enable thp migration in gene
Commit 3a321d2a3dde separated NUMA counters from zone counters, but
the NUMA_INTERLEAVE_HIT call site wasn't updated to use the new interface.
So alloc_page_interleave() actually increments NR_ZONE_INACTIVE_FILE
instead of NUMA_INTERLEAVE_HIT.
Fix this by using __inc_numa_state() interface to incr
Commit-ID: 3440fe2790aa3d13530260af6033533b18959aee
Gitweb: https://git.kernel.org/tip/3440fe2790aa3d13530260af6033533b18959aee
Author: Thomas Richter
AuthorDate: Wed, 13 Sep 2017 10:12:08 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 2 Oct 2017 14:00:20 -0300
perf test at
Commit-ID: 10836d9f9ac63d40ccfa756f871ce4ed51ae3b52
Gitweb: https://git.kernel.org/tip/10836d9f9ac63d40ccfa756f871ce4ed51ae3b52
Author: Jiri Olsa
AuthorDate: Mon, 3 Jul 2017 16:50:30 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 2 Oct 2017 13:59:18 -0300
perf tests attr: F
Commit-ID: 22905582f6dd4bbd0c370fe5732c607452010c04
Gitweb: https://git.kernel.org/tip/22905582f6dd4bbd0c370fe5732c607452010c04
Author: Thomas Richter
AuthorDate: Wed, 13 Sep 2017 10:12:09 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 2 Oct 2017 14:00:57 -0300
perf test at
Commit-ID: f6a9820d572bd8384d982357cbad214b3a6c04bb
Gitweb: https://git.kernel.org/tip/f6a9820d572bd8384d982357cbad214b3a6c04bb
Author: Jiri Olsa
AuthorDate: Thu, 28 Sep 2017 18:06:33 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 3 Oct 2017 09:41:45 -0300
perf tests attr:
Commit-ID: b32ee9e522f7ba26339856a047cfe9efc0be0ff3
Gitweb: https://git.kernel.org/tip/b32ee9e522f7ba26339856a047cfe9efc0be0ff3
Author: Kan Liang
AuthorDate: Fri, 29 Sep 2017 07:47:52 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 3 Oct 2017 09:27:27 -0300
perf tools: Lock
Commit-ID: f988e71bc6220d8b404dbd43c0e0962e30305795
Gitweb: https://git.kernel.org/tip/f988e71bc6220d8b404dbd43c0e0962e30305795
Author: Kan Liang
AuthorDate: Fri, 29 Sep 2017 07:47:53 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 3 Oct 2017 09:27:36 -0300
perf tools: Lock
Commit-ID: 340b47f510bbe55a76b7309107276f02ea11f117
Gitweb: https://git.kernel.org/tip/340b47f510bbe55a76b7309107276f02ea11f117
Author: Kan Liang
AuthorDate: Fri, 29 Sep 2017 07:47:54 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 3 Oct 2017 09:27:46 -0300
perf top: Impleme
On Tue, Oct 3, 2017 at 8:10 AM, Darren Hart wrote:
> On Tue, Oct 03, 2017 at 11:23:23AM +0200, Greg KH wrote:
>> On Wed, Sep 27, 2017 at 11:02:16PM -0500, Mario Limonciello wrote:
>> > For WMI operations that are only Set or Query read or write sysfs
>> > attributes created by WMI vendor drivers m
ebied...@xmission.com (Eric W. Biederman) writes:
> Philipp Hahn writes:
>
>> We will try 4.9.52 next and see, if we can still reproduce it.
Can you still reproduce this on 4.9.52?
I am not seeing anything obvious that would result in last_source
becomming NULL there so knowing I am not looknin
On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> Thinking about this a bit more, I'm not 100% sure if this
> will allow the security rules we want. Heap ids are assigned
> dynamically and therefore so will the /dev/ionX designation.
> From my understanding, security rules like selin
Commit-ID: 0c6b499495e928777c41ca2de4fbb58788269690
Gitweb: https://git.kernel.org/tip/0c6b499495e928777c41ca2de4fbb58788269690
Author: Kan Liang
AuthorDate: Fri, 29 Sep 2017 07:47:55 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 3 Oct 2017 09:27:54 -0300
perf top: Add opt
This is a test utility to verify ION buffer sharing in user space
between 2 independent processes.
It uses unix domain socket as IPC to transfer an FD to another process
and install it.
This utility demonstrates how ION buffer sharing can be implemented between
two user space processes, using vari
On Tue, 3 Oct 2017, Takashi Iwai wrote:
> > It's a dev_WARN because it indicates a potentially serious error in the
> > driver: The driver has submitted an interrupt URB to a bulk endpoint.
> > That may not sound bad, but the same check gets triggered if a driver
> > submits a bulk URB to an i
Hi Santosh,
On 10/03/2017 11:41 AM, Santosh Shilimkar wrote:
>
>
> On 10/3/2017 9:17 AM, Grygorii Strashko wrote:
>> Now acking of edge irqs happens the following way:
>> - omap_gpio_irq_handler
>> - "isr" = read irq status
>> - omap_clear_gpio_irqbank(bank, isr_saved & ~level_mask);
>>
On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote:
>
> This patch triggers a NULL-dereference bug at update_stack_state().
> Although its parent commit also has a NULL-dereference bug, however
> the call stack looks rather different. Both dmesg files are attached.
>
> It also triggers this warnin
On Thu, 21 Sep 2017 10:17:18 +0200
Vitaly Kuznetsov wrote:
> Steven Rostedt writes:
>
> > On Wed, 20 Sep 2017 19:21:53 +0200
> > Vitaly Kuznetsov wrote:
> >
> >> diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
> >> index 9a29ef55477d..72911dfc9682 100644
> >> --- a/drivers/hv/hv_t
On Tue, Oct 3, 2017 at 9:54 AM, Linus Torvalds
wrote:
>
> Can we consider just reverting the crossrelease thing?
>
> The apparent stack corruption really worries me [...]
Side note: I also think the thing is just broken.
Any actual cross-releaser should be way more annotated than just "set
cross
On Tue, Oct 03, 2017 at 05:07:09PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 03, 2017 at 03:32:45PM +0100, Will Deacon wrote:
> > The lockdep subsystem provides a robust way to assert that a lock is
> > held, so use that instead of write_can_lock, which can give incorrect
> > results for qrwlocks.
The Allwinner XR819 SDIO Wi-Fi chip supports an out-of-band interrupt line,
and the in-band interrupt is also supported.
However the current out-of-tree driver uses the out-of-band interrupt by
default.
This patchset adds the device tree binding for the chip as well as the
out-of-band interrupt,
Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to use
an out-of-band interrupt pin instead of SDIO in-band interrupt.
Add the device tree binding of this chip, in order to make it possible
to add this interrupt pin to device trees.
Signed-off-by: Icenowy Zheng
Acked-by: Rob He
From: Sergey Matyukevich
The Orange Pi Zero board has Allwinner XR819 SDIO wifi chip. The board
dts file provides a node enabling mmc1 controller, and a out-of-band
interrupt line of the chip is also connected, although the chip also
supports in-band interrupt.
The current out-of-tree driver is
New GPIO IRQs are allocated and mapped dynamically by default when
GPIO IRQ infrastructure is used by cherryview-pinctrl driver.
This causes issues on some Intel platforms [1][2] with broken BIOS which
hardcodes Linux IRQ numbers in their ACPI tables.
On such platforms cherryview-pinctrl driver sh
On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote:
> There is a general need to find out about the death of other processes,
> if you are not the parent of the process. I would be inclined to call
> it waitfd. Something that you give a pid. It performs a permission
> check and the pid
On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman wrote:
>
> *Scratches head*
> pdeath_signal is cleared during exec if bprm->cap_elevated.
It's not cleared if we are *releasing* capabilities, which is exactly
what might cause a "we can no longer send a signal"
> is_setid is set if the uid != ei
On Tue, Oct 03, 2017 at 10:11:20AM -0600, Jens Axboe wrote:
> On 10/03/2017 10:06 AM, Matthew Wilcox wrote:
> > test_and_test_and_set_bit()? It's an unusual name, so when either
> > reading it or writing it, people are going to say "something unusual
> > here", rather than "That Jens Axboe is such
On 03.10.2017 18:38, Stephen Warren wrote:
> On 10/03/2017 04:32 AM, Jon Hunter wrote:
>>
>>
>> On 03/10/17 00:02, Dmitry Osipenko wrote:
>>> On 02.10.2017 20:05, Stephen Warren wrote:
On 09/29/2017 09:11 PM, Dmitry Osipenko wrote:
> On 29.09.2017 22:30, Stephen Warren wrote:
>> On 09/
2017-09-28 18:04-0700, Wanpeng Li:
> From: Wanpeng Li
>
> SDM 10.5.4.1 TSC-Deadline Mode mentioned that "Transitioning between
> TSC-Deadline
> mode and other timer modes also disarms the timer". So the APIC Timer Initial
> Count
> Register for one-shot/periodic mode should be reset. This patch
2017-09-28 18:04-0700, Wanpeng Li:
> From: Wanpeng Li
>
> If we take TSC-deadline mode timer out of the picture, the Intel SDM
> does not say that the timer is disable when the timer mode is change,
> either from one-shot to periodic or vice versa.
I think it does, please see comment under [v2 1
I added an additional set of trace points for when channel gets notified or
signals host.
diff -urNp linux-msft/drivers/hv/channel.c msft-4.14-rc3/drivers/hv/channel.c
--- linux-msft/drivers/hv/channel.c 2017-10-03 10:06:54.893209237 -0700
+++ msft-4.14-rc3/drivers/hv/channel.c 2017-10-03 10
* Masami Hiramatsu wrote:
> On Tue, 3 Oct 2017 11:33:44 +0200
> Ingo Molnar wrote:
>
> >
> > * Masami Hiramatsu wrote:
> >
> > > Jprobe actually doesn't need to disable IRQs while calling
> > > handlers, because Documentation/kprobes.txt says:
> > >
> > > -
> > > Probe handlers are ru
On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
wrote:
> Hi Rob,
>
> On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
>> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
>> wrote:
>> > Hi Rob,
>> >
>> > On Sun, 2017-10-01 at 17:00 -0500, Rob Herring wrote:
>> >> On Thu, Sep 28, 2017 at 2:
The ARM CCI driver seem to be using smp_processor_id() in a
preemptible context, which is likely to make a DEBUG_PREMPT
kernel scream at boot time.
Turn this into a get_cpu()/put_cpu() that extends over the CPU
hotplug registration, making sure that we don't race against
a CPU down operation.
Sig
I've just noticed that both the CCI and CCN drivers have a small
buglet in that they call smp_processor_id() from preemptible context,
which is frown upon (having just booted a 4.13 kernel with
DEBUG_PREEMPT on my Seattle, I was surprised to be greeted with a nice
backtrace...).
I've tested the CC
Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
results in the following splat:
[...]
arm-ccn e800.ccn: No access to interrupts, using timer.
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id+0x1c/0x28
CPU: 1 PID: 1 Comm: sw
* Linus Torvalds wrote:
> On Tue, Oct 3, 2017 at 7:06 AM, Fengguang Wu wrote:
> >
> > This patch triggers a NULL-dereference bug at update_stack_state().
> > Although its parent commit also has a NULL-dereference bug, however
> > the call stack looks rather different. Both dmesg files are attac
On Tue, Oct 03, 2017 at 06:14:11PM +0100, Marc Zyngier wrote:
> I've just noticed that both the CCI and CCN drivers have a small
> buglet in that they call smp_processor_id() from preemptible context,
> which is frown upon (having just booted a 4.13 kernel with
> DEBUG_PREEMPT on my Seattle, I was
From: Colin King
Date: Tue, 3 Oct 2017 11:39:18 +0100
> From: Colin Ian King
>
> The functions lan9303_mdio_phy_write and lan9303_mdio_phy_read are local
> to the source and do not need to be in global scope, so make them static.
>
> Cleans up sparse warnings:
> symbol 'lan9303_mdio_phy_write
From: Colin King
Date: Tue, 3 Oct 2017 11:46:33 +0100
> From: Colin Ian King
>
> The function mt7530_phy_write is local to the source and does not need to
> be in global scope, so make it static.
>
> Cleans up sparse warnings:
> symbol 'mt7530_phy_write' was not declared. Should it be static?
On Tue, Oct 03, 2017 at 11:52:01AM -0500, Grygorii Strashko wrote:
> Hi Santosh,
>
> On 10/03/2017 11:41 AM, Santosh Shilimkar wrote:
> >
> >
> > On 10/3/2017 9:17 AM, Grygorii Strashko wrote:
> >> Now acking of edge irqs happens the following way:
> >> - omap_gpio_irq_handler
> >> - "isr" =
On Tue, Oct 3, 2017 at 6:26 AM, Tejun Heo wrote:
>
> * Mark noticed that the generic implementations of percpu local atomic
> reads aren't properly protected against irqs and there's a (slim)
> chance for split reads on some 32bit systems.
Grr.
Do we really want to support 64-bit percpu oper
2017-09-28 18:04-0700, Wanpeng Li:
> From: Wanpeng Li
>
> The description in the Intel SDM of how the divide configuration
> register is used: "The APIC timer frequency will be the processor's bus
> clock or core crystal clock frequency divided by the value specified in
> the divide configuration
On Tue, Oct 03, 2017 at 12:40:12PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 03, 2017 at 03:07:24AM +0100, Al Viro wrote:
> > That essay is full of shit, and you've even mentioned parts of that just
> > above...
> > NAK; you'd _still_ need proper quoting (or a shell with something
> > resembling
On Tue, Oct 03, 2017 at 11:28:15AM -0500, Josh Poimboeuf wrote:
> There are two bugs:
>
> 1) Somebody -- presumably lockdep -- is corrupting the stack. Need the
>lockdep people to look at that.
>
> 2) The 32-bit FP unwinder isn't handling the corrupt stack very well,
>It's blindly derefe
* Arnaldo Carvalho de Melo wrote:
> From: Kan Liang
>
> The proc files which is sorted with alphabetical order are evenly
> assigned to several synthesize threads to be processed in parallel.
>
> For 'perf top', the threads number hard code to online CPU number. The
> following patch will int
Hi Jintack,
On 03/10/17 04:11, Jintack Lim wrote:
> This design overview will help to digest the subsequent patches that
> implement AT instruction emulation.
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 8d04926..d8728cc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +
Hi Rob,
On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote:
> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou
> wrote:
> > Hi Rob,
> >
> > On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote:
> >> On Mon, Oct 2, 2017 at 2:46 PM, Pantelis Antoniou
> >> wrote:
> >> > Hi Rob,
> >> >
> >> > On
On Tue, Oct 3, 2017 at 9:45 PM, Oleg Nesterov wrote:
> On 10/02, Andrew Morton wrote:
>>
>> From: Alexey Dobriyan
>> Subject: pid: delete struct pidmap::nr_free
>>
>> There is a check in pid allocation code to skip a full page:
>>
>> if (likely(atomic_read(&map->nr_free))) {
>>
Jürg Billeter writes:
> On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote:
>> There is a general need to find out about the death of other processes,
>> if you are not the parent of the process. I would be inclined to call
>> it waitfd. Something that you give a pid. It performs a pe
On Tue, Oct 03, 2017 at 12:50:08PM -0400, Alan Stern wrote:
> On Tue, 3 Oct 2017, Takashi Iwai wrote:
>
> > > It's a dev_WARN because it indicates a potentially serious error in the
> > > driver: The driver has submitted an interrupt URB to a bulk endpoint.
> > > That may not sound bad, but the
Commit-ID: ee213fc72fd67d0988525af501534f4cb924d1e9
Gitweb: https://git.kernel.org/tip/ee213fc72fd67d0988525af501534f4cb924d1e9
Author: Josh Poimboeuf
AuthorDate: Tue, 3 Oct 2017 08:51:43 -0500
Committer: Ingo Molnar
CommitDate: Tue, 3 Oct 2017 19:11:27 +0200
kprobes/x86: Set up frame
Commit-ID: b664d57f39d01e775204d4f1a7e2f8bda77bc549
Gitweb: https://git.kernel.org/tip/b664d57f39d01e775204d4f1a7e2f8bda77bc549
Author: Masami Hiramatsu
AuthorDate: Tue, 3 Oct 2017 16:18:02 +0900
Committer: Ingo Molnar
CommitDate: Tue, 3 Oct 2017 19:11:48 +0200
kprobes/x86: Remove IRQ
On Tue, Oct 03, 2017 at 09:48:05AM -0700, Andy Lutomirski wrote:
> On Tue, Oct 3, 2017 at 8:10 AM, Darren Hart wrote:
> > On Tue, Oct 03, 2017 at 11:23:23AM +0200, Greg KH wrote:
> >> On Wed, Sep 27, 2017 at 11:02:16PM -0500, Mario Limonciello wrote:
> >> > For WMI operations that are only Set or
On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote:
> Jürg Billeter writes:
> > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN?
> > Does CLONE_NEWPID pose any risks that don't exist for
> > CLONE_NEWUSER|CLONE_NEWPID? Assuming we can't simply drop the
> > CAP_SYS_ADM
[+cc linux-pci]
My plan is to take these two additional fixes via the PCI tree, along
with Lorenzo's patch to add a pci_assign_irq() call in
ide_scan_pcidev(), since they're all related.
On Tue, Oct 03, 2017 at 01:18:47PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Recent pci_assign_irq() changes u
2017-09-28 18:04-0700, Wanpeng Li:
> From: Wanpeng Li
>
> Vectors 0-15 are reserved, and a physical LAPIC - upon sending or
> receiving one - would generate an APIC error instead of doing the
> requested action. Make our emulation behave similarly.
>
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Si
On Tue, Oct 3, 2017 at 8:00 PM, Grygorii Strashko
wrote:
> New GPIO IRQs are allocated and mapped dynamically by default when
> GPIO IRQ infrastructure is used by cherryview-pinctrl driver.
> This causes issues on some Intel platforms [1][2] with broken BIOS which
> hardcodes Linux IRQ numbers in
Hi Josh,
On Fri, Sep 29, 2017 at 03:46:09PM -0500, Josh Poimboeuf wrote:
> On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote:
> > Hi Josh,
> >
> > when trying to compile an image with KCFLAGS="-frecord-gcc-switches",
> > I get the folllowing build warning/error.
> >
> > make allmodco
[+cc linux-pci for real]
My plan is to take these two additional fixes via the PCI tree, along
with Lorenzo's patch to add a pci_assign_irq() call in
ide_scan_pcidev(), since they're all related.
On Tue, Oct 03, 2017 at 01:18:47PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Recent pci_assign_irq()
On Tue, Oct 03, 2017 at 10:54:57AM -0700, Guenter Roeck wrote:
> Hi Josh,
>
> On Fri, Sep 29, 2017 at 03:46:09PM -0500, Josh Poimboeuf wrote:
> > On Fri, Sep 29, 2017 at 01:00:56PM -0700, Guenter Roeck wrote:
> > > Hi Josh,
> > >
> > > when trying to compile an image with KCFLAGS="-frecord-gcc-sw
On 03/10/17 13:55, David Woodhouse wrote:
> On Thu, 2017-09-28 at 15:14 +0100, Robin Murphy wrote:
>> The intel-iommu DMA ops fail to correctly handle scatterlists where
>> sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
>> appropriately based on the page-aligned portion of t
On Tue, Oct 03, 2017 at 07:47:20PM +0300, Andrey Ryabinin wrote:
> Commit 3a321d2a3dde separated NUMA counters from zone counters, but
> the NUMA_INTERLEAVE_HIT call site wasn't updated to use the new interface.
> So alloc_page_interleave() actually increments NR_ZONE_INACTIVE_FILE
> instead of NUM
According to the discussion with Christoph [1], it sounds it is pointless
to keep CONFIG_SLABINFO around.
This patch just remove CONFIG_SLABINFO config option, but /proc/slabinfo
is still available.
[1] https://marc.info/?l=linux-kernel&m=150695909709711&w=2
Signed-off-by: Yang Shi
---
init/Kc
Kernel may panic when oom happens without killable process sometimes it
is caused by huge unreclaimable slabs used by kernel.
Although kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it
Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump
doesn't capture vmcore due to some reason.
So, it may sound better to capture unreclaimable slab info in oom message when
kernel panic to aid tr
Add "-U" option to show unreclaimable slabs only.
"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.
Signed-off-by: Yang Shi
Acked-by: Christoph Lameter
Acked-by: David Rientjes
---
tools/vm/slabinfo.c | 11 ++-
This round should be v9. Sorry for the typo.
Yang
On 10/3/17 11:06 AM, Yang Shi wrote:
Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump
doesn't capture vmcore due to some reason.
So, it may
-increased-stack-usage/20171003-210611
config: x86_64-randconfig-ws0-10040032 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file include
On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre wrote:
> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>
>> If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
>> hundred identical messages:
>>
>> unwind: Unknown symbol address c0800300
>> unwind: Index not found c0800300
>>
>
Hi Chao.
Yep, that patch seems to have fixed it.
Doing "while true; do fstrim -v /; done" while "rm -rf"ing a 2GB
kbuild directory
(with lots of small .o files and stuff) ended flawlessly.
I hope to see this patch merged with next 4.14 merge cycle.
Thanks :)
On Tue, Oct 3, 2017 at 12:59 AM, Cha
On 10/3/2017 9:52 AM, Grygorii Strashko wrote:
Hi Santosh,
On 10/03/2017 11:41 AM, Santosh Shilimkar wrote:
[...]
This was one of the concern I was thinking when GPIO IRQ conversion
was done. Grygorii since you did that conversion, can you please
check since I see now that the irq code is
On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven wrote:
> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre
> wrote:
>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> Please send it to RMK's patch system.
>
> Done (I hope so ;-)
Failed. Retrying.
Gr{oetje,eeting}s,
Gee
On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven wrote:
> On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven
> wrote:
>> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre
>> wrote:
>>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>>> Please send it to RMK's patch system.
>>
>> Done (I hope so ;
Dear All,
Maybe somebody could shed some light to following issue:
On my setup I do have USB connected touchscreen powered from VBUS.
The VBUS power is controlled by a GPIO pin, which in turn is governed by
regulator API:
reg_usbh1_vbus: usb-h1-vbus {
compatible = "re
The property "post-power-on-delay-ms" allows a platform to specify
the delay needed after power-on, but only via device trees currently.
Use device_property_* instead of of_* reads to allow ACPI systems to
also provide the same information. This is useful for Wacom hardware
on ACPI systems.
Signed
On 10/03/2017 12:54 PM, Andy Shevchenko wrote:
> On Tue, Oct 3, 2017 at 8:00 PM, Grygorii Strashko
> wrote:
>> New GPIO IRQs are allocated and mapped dynamically by default when
>> GPIO IRQ infrastructure is used by cherryview-pinctrl driver.
>> This causes issues on some Intel platforms [1][2]
On Thu, Sep 28, 2017 at 11:07:40AM +0100, Martyn Welch wrote:
> The imx serial driver uses PAGE_SIZE when allocating rx_buf, but then
> uses RX_BUF_SIZE (which is currently defined as PAGE_SIZE) to describe
> the length of the buffer when initialising the scatter gather list.
>
> In order to ensur
On Tue, Oct 3, 2017 at 2:28 AM, Andy Shevchenko
wrote:
> + Cc: Jarkko, he spent a lot of nice hours to debug i2c HID touchscreen
> devices on x86 ACPI enabled platforms, so, he might have a better idea
> or some comments.
Thanks Andy, I'll look out for any suggestions on inputs from Jarkko.
>
>
arch_{read,spin,write}_relax are defined as cpu_relax() by the core
code, so architectures that can't do better (i.e. most of them) don't
need to bother with the dummy definitions.
Cc: Peter Zijlstra
Signed-off-by: Will Deacon
---
arch/arc/include/asm/spinlock.h | 4
arch/arm/incl
Outside of the locking code itself, {read,spin,write}_can_lock have no
users in tree. Apparmor (the last remaining user of write_can_lock) is
moved over to lockdep by the previous patch.
This patch removes the use of {read,spin,write}_can_lock from the
BUILD_LOCK_OPS macro, deferring to the tryloc
The lockdep subsystem provides a robust way to assert that a lock is
held, so use that instead of write_can_lock, which can give incorrect
results for qrwlocks.
Cc: Peter Zijlstra
Acked-by: John Johansen
Signed-off-by: Will Deacon
---
security/apparmor/include/lib.h | 11 ---
security/
The arch_{read,spin,write}_lock_flags macros are simply mapped to the
non-flags versions by the majority of architectures, so do this in core
code and remove the dummy implementations. Also remove the implementation
in spinlock_up.h, since all callers of do_raw_spin_lock_flags call
local_irq_save(f
On 10/02/2017 02:55 AM, Linus Walleij wrote:
> On Thu, Sep 28, 2017 at 4:22 PM, Grygorii Strashko
> wrote:
>
>> Sry, but I do not agree with this series.
>> - no prof that it can be re-used by other drivers than tegra
>> (at least I do not see reasons to re-use it for any TI drivers)
>
> Thi
On Fri, Sep 29, 2017 at 10:22:19AM +0100, Martyn Welch wrote:
> The comment in imx_flush_buffer() states that the state of 4 registers
> are to be saved/restored, then only saves and restores 3 registers. The
> missing register (UBRC) is read only and thus can't be restored.
>
> Update the comment
Also
Tested-by: Oleksandr Natalenko
for whole v8.
On úterý 3. října 2017 16:03:58 CEST Ming Lei wrote:
> Hi Jens,
>
> Please consider this patchset for V4.15, and it fixes one
> kind of long-term I/O hang issue in either block legacy path
> or blk-mq.
>
> The current SCSI quiesce isn't safe a
libfdt has gained some new files. We need to include them in the
kernel's copy.
Reported-by: Kyle Yan
Signed-off-by: Rob Herring
---
scripts/dtc/update-dtc-source.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/dtc/update-dtc-source.sh b/scripts/dtc/update-dtc-
This adds the following commits from upstream:
b1a60033c110 tests: Add a test for overlays syntactic sugar
737b2df39cc8 overlay: Add syntactic sugar version of overlays
497432fd2131 checks: Use proper format modifier for size_t
22a65c5331c2 dtc: Bump version to v1.4.5
c575d8059fff Add fdtoverlay t
801 - 900 of 1098 matches
Mail list logo
