Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 18 May 01:39 PDT 2017, Varadarajan Narayanan wrote: > > > On 5/18/2017 1:03 AM, Bjorn Andersson wrote: > > On Mon 15 May 02:05 PDT 2017, Varadarajan Narayanan wrote: > > > > > On 5/14/2017 9:53 AM, Bjorn Andersson wrote: > > > > On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote:

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

On Thu 18 May 01:39 PDT 2017, Varadarajan Narayanan wrote: > > > On 5/18/2017 1:03 AM, Bjorn Andersson wrote: > > On Mon 15 May 02:05 PDT 2017, Varadarajan Narayanan wrote: > > > > > On 5/14/2017 9:53 AM, Bjorn Andersson wrote: > > > > On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote:

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

> Looks like you running your patched kernel? That's right. >>> CONFIG_RMI4_CORE=m >>> CONFIG_RMI4_I2C=m >>> CONFIG_RMI4_SPI=m >>> # CONFIG_RMI4_SMB is not set > > This is your issue I believe. Indeed, enabling that configuration solves that issue. However, I think it is quite unintuitive that

Re: [4.12 regression] Thinkpad X250 Touchpad and Trackpoint not recognized anymore; commit e839ffa: "Input: synaptics - add support for Intertouch devices"

> Looks like you running your patched kernel? That's right. >>> CONFIG_RMI4_CORE=m >>> CONFIG_RMI4_I2C=m >>> CONFIG_RMI4_SPI=m >>> # CONFIG_RMI4_SMB is not set > > This is your issue I believe. Indeed, enabling that configuration solves that issue. However, I think it is quite unintuitive that

Re: [PATCH 7/7] DWARF: add the config option

On Fri, May 19, 2017 at 2:35 PM, Josh Poimboeuf wrote: > On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote: >> > How are you handling control flow? >> >> Control flow of what? >> >> > > Here's the struct in its current state: >> > > >> > > #define

Re: [PATCH 7/7] DWARF: add the config option

On Fri, May 19, 2017 at 2:35 PM, Josh Poimboeuf wrote: > On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote: >> > How are you handling control flow? >> >> Control flow of what? >> >> > > Here's the struct in its current state: >> > > >> > > #define UNDWARF_REG_UNDEFINED 0

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Alex, Yes, I hope kernel can disable SR-IOV and related VF resource allocation if the system BIOS is not SR-IOV capable. Adding the parameter "pci=nosriov" sounds a doable solution, but it would need user to add this parameter manually, right? I think an automatic detection would be

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Alex, Yes, I hope kernel can disable SR-IOV and related VF resource allocation if the system BIOS is not SR-IOV capable. Adding the parameter "pci=nosriov" sounds a doable solution, but it would need user to add this parameter manually, right? I think an automatic detection would be

Re: [PATCH v3] jbd2: preserve original nofs flag during journal restart

On Thu, May 18, 2017 at 09:28:50AM -0700, Tahsin Erdogan wrote: > When a transaction starts, start_this_handle() saves current > PF_MEMALLOC_NOFS value so that it can be restored at journal stop time. > Journal restart is a special case that calls start_this_handle() without > stopping the

Re: [PATCH v3] jbd2: preserve original nofs flag during journal restart

On Thu, May 18, 2017 at 09:28:50AM -0700, Tahsin Erdogan wrote: > When a transaction starts, start_this_handle() saves current > PF_MEMALLOC_NOFS value so that it can be restored at journal stop time. > Journal restart is a special case that calls start_this_handle() without > stopping the

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 10:40, Hugh Dickins wrote: > On Sat, 20 May 2017, Xishi Qiu wrote: >> Here is a bug report form redhat: >> https://bugzilla.redhat.com/show_bug.cgi?id=1305620 >> And I meet the bug too. However it is hard to reproduce, and >> 624483f3ea82598("mm: rmap: fix use-after-free in

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 10:40, Hugh Dickins wrote: > On Sat, 20 May 2017, Xishi Qiu wrote: >> Here is a bug report form redhat: >> https://bugzilla.redhat.com/show_bug.cgi?id=1305620 >> And I meet the bug too. However it is hard to reproduce, and >> 624483f3ea82598("mm: rmap: fix use-after-free in

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi Bjorn/Avaneesh, On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote: > This patch refactor code to first load all firmware blobs > and then update modem proc to authenticate and boot fw. > Also make a trivial change in a error log. > > Signed-off-by: Avaneesh Kumar Dwivedi

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi Bjorn/Avaneesh, On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote: > This patch refactor code to first load all firmware blobs > and then update modem proc to authenticate and boot fw. > Also make a trivial change in a error log. > > Signed-off-by: Avaneesh Kumar Dwivedi > --- >

Re: mm, something wring in page_lock_anon_vma_read()?

On Sat, 20 May 2017, Xishi Qiu wrote: > > Here is a bug report form redhat: > https://bugzilla.redhat.com/show_bug.cgi?id=1305620 > And I meet the bug too. However it is hard to reproduce, and > 624483f3ea82598("mm: rmap: fix use-after-free in __put_anon_vma") is not help. > > From the vmcore,

Re: mm, something wring in page_lock_anon_vma_read()?

On Sat, 20 May 2017, Xishi Qiu wrote: > > Here is a bug report form redhat: > https://bugzilla.redhat.com/show_bug.cgi?id=1305620 > And I meet the bug too. However it is hard to reproduce, and > 624483f3ea82598("mm: rmap: fix use-after-free in __put_anon_vma") is not help. > > From the vmcore,

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

; > > > Note on the latest linux-next and on the commit that introduced this the > > > config > > > and kernel yields only *one* page: > > > > > > x86/mm: Checked W+X mappings: FAILED, 1 W+X pages found. > > > > > > I believe this is

Re: next-20170515: WARNING: CPU: 0 PID: 1 at arch/x86/mm/dump_pagetables.c:236 note_page+0x630/0x7e0

linux-next and on the commit that introduced this the > > > config > > > and kernel yields only *one* page: > > > > > > x86/mm: Checked W+X mappings: FAILED, 1 W+X pages found. > > > > > > I believe this is more indications my suspicion might be right. >

[PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts

The number of xilinx ps uart should be set by a kernel parameter instead of using a #define. This allows the user to set the number of xilinx ps uart using only kconfig and not modifying kernel source. The ps uart is used in Xilnx Zynq chips usually in quantities maxing at two, but there may be

[PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts

The number of xilinx ps uart should be set by a kernel parameter instead of using a #define. This allows the user to set the number of xilinx ps uart using only kconfig and not modifying kernel source. The ps uart is used in Xilnx Zynq chips usually in quantities maxing at two, but there may be

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 10:02, Hugh Dickins wrote: > On Sat, 20 May 2017, Xishi Qiu wrote: >> On 2017/5/20 6:00, Hugh Dickins wrote: >>> >>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(), >>> and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature >>> of the

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 10:02, Hugh Dickins wrote: > On Sat, 20 May 2017, Xishi Qiu wrote: >> On 2017/5/20 6:00, Hugh Dickins wrote: >>> >>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(), >>> and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature >>> of the

Re: [RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint

On Fri, 2017-05-19 at 16:38 -0400, Tejun Heo wrote: > Hello, Waiman. > > On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote: > > The rationale behind the cgroup v2 no internal process constraint is > > to avoid resouorce competition between internal processes and child > > cgroups.

Re: [RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint

On Fri, 2017-05-19 at 16:38 -0400, Tejun Heo wrote: > Hello, Waiman. > > On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote: > > The rationale behind the cgroup v2 no internal process constraint is > > to avoid resouorce competition between internal processes and child > > cgroups.

Re: mm, something wring in page_lock_anon_vma_read()?

On Sat, 20 May 2017, Xishi Qiu wrote: > On 2017/5/20 6:00, Hugh Dickins wrote: > > > > You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(), > > and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature > > of the anon_vma_cachep kmem cache. It is not safe

Re: mm, something wring in page_lock_anon_vma_read()?

On Sat, 20 May 2017, Xishi Qiu wrote: > On 2017/5/20 6:00, Hugh Dickins wrote: > > > > You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(), > > and the SLAB_DESTROY_BY_RCU (recently renamed SLAB_TYPESAFE_BY_RCU) nature > > of the anon_vma_cachep kmem cache. It is not safe

Re: [linux-sunxi] Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support

On Sat, May 20, 2017 at 2:06 AM, Icenowy Zheng wrote: > > > 于 2017年5月20日 GMT+08:00 上午2:02:15, Maxime Ripard > 写到: >>On Thu, May 18, 2017 at 12:43:44AM +0800, Icenowy Zheng wrote: >>> -On SoCs other than the A33 and V3s, there is one more clock

Re: [linux-sunxi] Re: [RFC PATCH 01/11] dt-bindings: update the binding for Allwinner H3 TVE support

On Sat, May 20, 2017 at 2:06 AM, Icenowy Zheng wrote: > > > 于 2017年5月20日 GMT+08:00 上午2:02:15, Maxime Ripard > 写到: >>On Thu, May 18, 2017 at 12:43:44AM +0800, Icenowy Zheng wrote: >>> -On SoCs other than the A33 and V3s, there is one more clock >>required: >>> +For the following compatibles: >>>

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

"J. R. Okajima": > I don't know whether the fix is good to me or not yet. I will test your > fix, but I am busy now and my test will be a few weeks later. Other > people may want the fix soon. So I'd suggest you to reproduce the > problem on your side. I guess "mem=1G" or "mem=512M" will make it

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

"J. R. Okajima": > I don't know whether the fix is good to me or not yet. I will test your > fix, but I am busy now and my test will be a few weeks later. Other > people may want the fix soon. So I'd suggest you to reproduce the > problem on your side. I guess "mem=1G" or "mem=512M" will make it

Re: [PATCH v2 1/2] Documentation: dt: Update ti,emif bindings

On Fri, May 19, 2017 at 12:57:07PM -0500, Dave Gerlach wrote: > Update the Texas Instruments EMIF binding document to include the device > tree bindings for ti,emif-am3352 and ti,emif-am4372 which are used by > the ti-emif-sram driver to provide low-level PM functionality. > > Signed-off-by: Dave

Re: [PATCH v2 1/2] Documentation: dt: Update ti,emif bindings

On Fri, May 19, 2017 at 12:57:07PM -0500, Dave Gerlach wrote: > Update the Texas Instruments EMIF binding document to include the device > tree bindings for ti,emif-am3352 and ti,emif-am4372 which are used by > the ti-emif-sram driver to provide low-level PM functionality. > > Signed-off-by: Dave

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec wrote: > Hi, > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard electrons.com> 写到: >> >On Thu, May 18, 2017 at 12:43:50AM

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec wrote: > Hi, > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard electrons.com> 写到: >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: >> >> Allwinner H3

[for-next][PATCH] tracing: Make sure RCU is watching before calling a stack trace

I'll probably just push this to Linus tomorrow along with my other changes. -- Steve git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: a33d7d94eed92b23fbbc7b0de06a41b2bbaa49e3 Steven Rostedt (VMware) (1): tracing: Make sure RCU is watching

[for-next][PATCH] tracing: Make sure RCU is watching before calling a stack trace

I'll probably just push this to Linus tomorrow along with my other changes. -- Steve git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: a33d7d94eed92b23fbbc7b0de06a41b2bbaa49e3 Steven Rostedt (VMware) (1): tracing: Make sure RCU is watching

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 6:00, Hugh Dickins wrote: > On Fri, 19 May 2017, Xishi Qiu wrote: >> On 2017/5/19 16:52, Xishi Qiu wrote: >>> On 2017/5/18 17:46, Xishi Qiu wrote: >>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be freed. The kernel is RHEL 7.2, and the

Re: mm, something wring in page_lock_anon_vma_read()?

On 2017/5/20 6:00, Hugh Dickins wrote: > On Fri, 19 May 2017, Xishi Qiu wrote: >> On 2017/5/19 16:52, Xishi Qiu wrote: >>> On 2017/5/18 17:46, Xishi Qiu wrote: >>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be freed. The kernel is RHEL 7.2, and the

Re: [PATCH] mm: clarify why we want kmalloc before falling backto vmallock

On 05/17/2017 01:09 AM, Michal Hocko wrote: From: Michal Hocko While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger

Re: [PATCH] mm: clarify why we want kmalloc before falling backto vmallock

On 05/17/2017 01:09 AM, Michal Hocko wrote: From: Michal Hocko While converting drm_[cm]alloc* helpers to kvmalloc* variants Chris Wilson has wondered why we want to try kmalloc before vmalloc fallback even for larger allocations requests. Let's clarify that one larger physically contiguous

Re: [PATCH RFC 0/3] Improve stability of system clock

On Wed, May 17, 2017 at 9:54 PM, Richard Cochran wrote: > On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >> wrote: >> > Is there a better way to run the timekeeping code in an

Re: [PATCH RFC 0/3] Improve stability of system clock

On Wed, May 17, 2017 at 9:54 PM, Richard Cochran wrote: > On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote: >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar >> wrote: >> > Is there a better way to run the timekeeping code in an userspace >> > application? I suspect it would need

Re: [PATCH] x86/mm: synchronize pgd in vmemmap_free()

Hi Jerome, On 05/19/2017 11:01 AM, Jérôme Glisse wrote: When we free kernel virtual map we should synchronize p4d/pud for all the pgds to avoid any stall entry in non canonical pgd. "any stale entry in the non-canonical pgd", is what I think you meant to type there. Also, it would be nice

Re: [PATCH] x86/mm: synchronize pgd in vmemmap_free()

Hi Jerome, On 05/19/2017 11:01 AM, Jérôme Glisse wrote: When we free kernel virtual map we should synchronize p4d/pud for all the pgds to avoid any stall entry in non canonical pgd. "any stale entry in the non-canonical pgd", is what I think you meant to type there. Also, it would be nice

[PATCH v2 2/7] arch/sparc: Remove the check #ifndef __LINUX_SPINLOCK_TYPES_H

Remove the un-necessary "ifndef __LINUX_SPINLOCK_TYPES_H" stanza from SPARC. Signed-off-by: Babu Moger Suggested-by: David Miller --- arch/sparc/include/asm/spinlock_types.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git

[PATCH v2 0/7] Enable queued rwlock and queued spinlock for SPARC

This series of patches enables queued rwlock and queued spinlock support for SPARC. These features were introduced some time ago in upstream. Here are some of the earlier discussions. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ https://lwn.net/Articles/561775/

[PATCH v2 7/7] arch/sparc: Enable queued spinlock support for SPARC

This patch makes the necessary changes in SPARC architecture to enable queued spinlock support. Here are some of the earlier discussions about this feature. https://lwn.net/Articles/561775/ https://lwn.net/Articles/590243/ Cleaned-up the spinlock_64.h. The definitions of arch_spin_xxx are

[PATCH v2 2/7] arch/sparc: Remove the check #ifndef __LINUX_SPINLOCK_TYPES_H

Remove the un-necessary "ifndef __LINUX_SPINLOCK_TYPES_H" stanza from SPARC. Signed-off-by: Babu Moger Suggested-by: David Miller --- arch/sparc/include/asm/spinlock_types.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/sparc/include/asm/spinlock_types.h

[PATCH v2 0/7] Enable queued rwlock and queued spinlock for SPARC

This series of patches enables queued rwlock and queued spinlock support for SPARC. These features were introduced some time ago in upstream. Here are some of the earlier discussions. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ https://lwn.net/Articles/561775/

[PATCH v2 7/7] arch/sparc: Enable queued spinlock support for SPARC

This patch makes the necessary changes in SPARC architecture to enable queued spinlock support. Here are some of the earlier discussions about this feature. https://lwn.net/Articles/561775/ https://lwn.net/Articles/590243/ Cleaned-up the spinlock_64.h. The definitions of arch_spin_xxx are

[PATCH v2 6/7] arch/sparc: Introduce xchg16 for SPARC

SPARC supports 32 bit and 64 bit xchg right now. Add the support for 16 bit (2 byte) xchg. This is required to support queued spinlock feature which uses 2 byte xchg. This is achieved using 4 byte cas instructions with byte manipulations. Also re-arranged the code to call __cmpxchg_u32 inside

[PATCH v2 6/7] arch/sparc: Introduce xchg16 for SPARC

SPARC supports 32 bit and 64 bit xchg right now. Add the support for 16 bit (2 byte) xchg. This is required to support queued spinlock feature which uses 2 byte xchg. This is achieved using 4 byte cas instructions with byte manipulations. Also re-arranged the code to call __cmpxchg_u32 inside

[PATCH v2 5/7] arch/sparc: Enable queued rwlocks for SPARC

Enable queued rwlocks for SPARC. Here are the discussions on this feature when this was introduced. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ Cleaned-up the arch_read_xxx and arch_write_xxx definitions in spinlock_64.h. These routines are replaced by the functions in

[PATCH v2 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return

[PATCH v2 4/7] arch/sparc: Introduce cmpxchg_u8 SPARC

SPARC supports 32 bit and 64 bit cmpxchg right now. Add support for 8 bit (1 byte) cmpxchg. This is required to support queued rwlocks feature which uses 1 byte cmpxchg. The function __cmpxchg_u8 here uses the 4 byte cas instruction with a byte manipulation to achieve 1 byte cmpxchg.

[PATCH v2 1/7] kernel/locking: Fix compile error with qrwlock.c

Some architectures use the following guard in include file "asm/spinlock_types.h" to discourage including the file directly. Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o In file included from ./include/asm-generic/qrwlock_types.h:5,

[PATCH v2 5/7] arch/sparc: Enable queued rwlocks for SPARC

Enable queued rwlocks for SPARC. Here are the discussions on this feature when this was introduced. https://lwn.net/Articles/572765/ https://lwn.net/Articles/582200/ Cleaned-up the arch_read_xxx and arch_write_xxx definitions in spinlock_64.h. These routines are replaced by the functions in

[PATCH v2 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN

Found this problem while enabling queued rwlock on SPARC. The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the specific byte in qrwlock structure. Without this parameter, we clear the wrong byte. Here is the code. static inline u8 *__qrwlock_write_byte(struct qrwlock *lock) { return

[PATCH v2 4/7] arch/sparc: Introduce cmpxchg_u8 SPARC

SPARC supports 32 bit and 64 bit cmpxchg right now. Add support for 8 bit (1 byte) cmpxchg. This is required to support queued rwlocks feature which uses 1 byte cmpxchg. The function __cmpxchg_u8 here uses the 4 byte cas instruction with a byte manipulation to achieve 1 byte cmpxchg.

[PATCH v2 1/7] kernel/locking: Fix compile error with qrwlock.c

Some architectures use the following guard in include file "asm/spinlock_types.h" to discourage including the file directly. Saw these compile errors on SPARC when queued rwlock feature is enabled. CC kernel/locking/qrwlock.o In file included from ./include/asm-generic/qrwlock_types.h:5,

Re: [PATCH] dt-bindings: Document optional "reserved-names" property

On 05/12/2017 04:55 PM, Rob Herring wrote: > On Tue, May 09, 2017 at 10:18:47AM -0700, Florian Fainelli wrote: >> Define an optional string property: "reserved-names" which can be used >> by the client program to tag/identify reserved memory regions. >> >> Signed-off-by: Florian Fainelli

Re: [PATCH] dt-bindings: Document optional "reserved-names" property

On 05/12/2017 04:55 PM, Rob Herring wrote: > On Tue, May 09, 2017 at 10:18:47AM -0700, Florian Fainelli wrote: >> Define an optional string property: "reserved-names" which can be used >> by the client program to tag/identify reserved memory regions. >> >> Signed-off-by: Florian Fainelli >> ---

Re: stackprotector: ascii armor the stack canary

On Fri, 2017-05-19 at 17:26 -0400, r...@redhat.com wrote: > Zero out the first byte of the stack canary value on 64 bit systems, > in order to prevent unterminated C string overflows from being able > to successfully overwrite the canary, even if an attacker somehow > guessed or obtained the

Re: stackprotector: ascii armor the stack canary

On Fri, 2017-05-19 at 17:26 -0400, r...@redhat.com wrote: > Zero out the first byte of the stack canary value on 64 bit systems, > in order to prevent unterminated C string overflows from being able > to successfully overwrite the canary, even if an attacker somehow > guessed or obtained the

[PATCH v2 3/3] drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si

Same as the previous patch, but for pageflipping now. This also lets us clear up the copy paste for vblank/vline IRQs. Changes since v1: - Preserve the order all registers are written back Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 105

[PATCH v2 3/3] drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si

Same as the previous patch, but for pageflipping now. This also lets us clear up the copy paste for vblank/vline IRQs. Changes since v1: - Preserve the order all registers are written back Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 105 ---

[PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

This is the first part of me going through and cleaning up the IRQ handling code for radeon, since after taking a look at it the other day while trying to debug something I realized basically all of the code was copy pasted everywhere, and quite difficult to actually read through. Will come up

[PATCH v2 0/3] Cleanup evergreen/si IRQ handling code

This is the first part of me going through and cleaning up the IRQ handling code for radeon, since after taking a look at it the other day while trying to debug something I realized basically all of the code was copy pasted everywhere, and quite difficult to actually read through. Will come up

[PATCH v2 2/3] drm/radeon: Cleanup HDMI audio interrupt handling for evergreen

Same as the previous patch, but now for handling HDMI audio interrupts. Changes since v1: - Preserve the order we write back all registers Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 153 +++-- drivers/gpu/drm/radeon/radeon.h

[PATCH v2 1/3] drm/radeon: Cleanup display interrupt handling for evergreen, si

The current code here is really, really bad. A huge amount of it looks to be copy pasted, it has some weird hatred of arrays and code sharing, switch cases everywhere for things that really don't need them, and it makes the file seem immensely more complex then it actually is. This is a pain for

[PATCH v2 2/3] drm/radeon: Cleanup HDMI audio interrupt handling for evergreen

Same as the previous patch, but now for handling HDMI audio interrupts. Changes since v1: - Preserve the order we write back all registers Signed-off-by: Lyude --- drivers/gpu/drm/radeon/evergreen.c | 153 +++-- drivers/gpu/drm/radeon/radeon.h| 7 +- 2

[PATCH v2 1/3] drm/radeon: Cleanup display interrupt handling for evergreen, si

The current code here is really, really bad. A huge amount of it looks to be copy pasted, it has some weird hatred of arrays and code sharing, switch cases everywhere for things that really don't need them, and it makes the file seem immensely more complex then it actually is. This is a pain for

[PATCH net v2] bonding: fix accounting of active ports in 3ad

As of 7bb11dc9f59d and 0622cab0341c, bond slaves in a 3ad bond are not removed from the aggregator when they are down, and the active slave count is NOT equal to number of ports in the aggregator, but rather the number of ports in the aggregator that are still enabled. The sysfs spew for

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

Michal Hocko wrote: > On Sat 20-05-17 00:22:30, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 19-05-17 22:02:44, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > Any allocation failure during the #PF path will return with > > > > > VM_FAULT_OOM > > > > > which in turn results

[PATCH] ipc: Fail build if IPC structures change layout

Since struct layout can be seen at build-time, turn runtime report into a build failure so it can be fixed more quickly. Cc: Manfred Spraul Signed-off-by: Kees Cook --- Should be applied on top of the -mm tree's IPC changes --- ipc/msg.c | 5

[PATCH net v2] bonding: fix accounting of active ports in 3ad

As of 7bb11dc9f59d and 0622cab0341c, bond slaves in a 3ad bond are not removed from the aggregator when they are down, and the active slave count is NOT equal to number of ports in the aggregator, but rather the number of ports in the aggregator that are still enabled. The sysfs spew for

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

Michal Hocko wrote: > On Sat 20-05-17 00:22:30, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Fri 19-05-17 22:02:44, Tetsuo Handa wrote: > > > > Michal Hocko wrote: > > > > > Any allocation failure during the #PF path will return with > > > > > VM_FAULT_OOM > > > > > which in turn results

[PATCH] ipc: Fail build if IPC structures change layout

Since struct layout can be seen at build-time, turn runtime report into a build failure so it can be fixed more quickly. Cc: Manfred Spraul Signed-off-by: Kees Cook --- Should be applied on top of the -mm tree's IPC changes --- ipc/msg.c | 5 + ipc/sem.c | 5 + ipc/shm.c | 5 + 3

Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params()

On Fri, 19 May 2017, Michal Hocko wrote: > On Thu 18-05-17 19:50:46, Junaid Shahid wrote: > > (Adding back the correct linux-mm email address and also adding > > linux-kernel.) > > > > On Thursday, May 18, 2017 01:41:33 PM David Rientjes wrote: > [...] > > > Let's ask Mikulas, who changed

Re: [PATCH] dm ioctl: Restore __GFP_HIGH in copy_params()

On Fri, 19 May 2017, Michal Hocko wrote: > On Thu 18-05-17 19:50:46, Junaid Shahid wrote: > > (Adding back the correct linux-mm email address and also adding > > linux-kernel.) > > > > On Thursday, May 18, 2017 01:41:33 PM David Rientjes wrote: > [...] > > > Let's ask Mikulas, who changed

Re: [PATCH] ARM64: defconfig: enable IR core, decoders and Meson IR device

Neil Armstrong writes: > This patch enables the MEDIA Infrared RC Decoders and Meson Infrared > decoder for ARM64 defconfig. > These drivers are selected as modules by default. > > Signed-off-by: Neil Armstrong > --- >

Re: [PATCH] ARM64: defconfig: enable IR core, decoders and Meson IR device

Neil Armstrong writes: > This patch enables the MEDIA Infrared RC Decoders and Meson Infrared > decoder for ARM64 defconfig. > These drivers are selected as modules by default. > > Signed-off-by: Neil Armstrong > --- > arch/arm64/configs/defconfig | 5 + > 1 file changed, 5 insertions(+) >

Re: [PATCH 04/29] printk-formats.txt: standardize document format

On 05/19/17 13:28, Mauro Carvalho Chehab wrote: > Em Fri, 19 May 2017 03:26:08 -0700 > Joe Perches escreveu: > >> On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote: >>> Each text file under Documentation follows a different >>> format. Some doesn't even have

Re: [PATCH 04/29] printk-formats.txt: standardize document format

On 05/19/17 13:28, Mauro Carvalho Chehab wrote: > Em Fri, 19 May 2017 03:26:08 -0700 > Joe Perches escreveu: > >> On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote: >>> Each text file under Documentation follows a different >>> format. Some doesn't even have titles! >>> >>> Change

[PATCH v2 05/18] xen/pvcalls: connect to a frontend

Introduce a per-frontend data structure named pvcalls_back_priv. It contains pointers to the command ring, its event channel, a list of active sockets and a tree of passive sockets (passing sockets need to be looked up from the id on listen, accept and poll commands, while active sockets only on

[PATCH v2 05/18] xen/pvcalls: connect to a frontend

Introduce a per-frontend data structure named pvcalls_back_priv. It contains pointers to the command ring, its event channel, a list of active sockets and a tree of passive sockets (passing sockets need to be looked up from the id on listen, accept and poll commands, while active sockets only on

[PATCH v2 04/18] xen/pvcalls: xenbus state handling

Introduce the code to handle xenbus state changes. Implement the probe function for the pvcalls backend. Write the supported versions, max-page-order and function-calls nodes to xenstore, as required by the protocol. Introduce stub functions for disconnecting/connecting to a frontend.

[PATCH v2 01/18] xen: introduce the pvcalls interface header

Introduce the C header file which defines the PV Calls interface. It is imported from xen/include/public/io/pvcalls.h. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- include/xen/interface/io/pvcalls.h |

[PATCH v2 04/18] xen/pvcalls: xenbus state handling

Introduce the code to handle xenbus state changes. Implement the probe function for the pvcalls backend. Write the supported versions, max-page-order and function-calls nodes to xenstore, as required by the protocol. Introduce stub functions for disconnecting/connecting to a frontend.

[PATCH v2 01/18] xen: introduce the pvcalls interface header

Introduce the C header file which defines the PV Calls interface. It is imported from xen/include/public/io/pvcalls.h. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- include/xen/interface/io/pvcalls.h | 120

[PATCH v2 06/18] xen/pvcalls: handle commands from the frontend

When the other end notifies us that there are commands to be read (pvcalls_back_event), wake up the backend thread to parse the command. The command ring works like most other Xen rings, so use the usual ring macros to read and write to it. The functions implementing the commands are empty stubs

[PATCH v2 06/18] xen/pvcalls: handle commands from the frontend

When the other end notifies us that there are commands to be read (pvcalls_back_event), wake up the backend thread to parse the command. The command ring works like most other Xen rings, so use the usual ring macros to read and write to it. The functions implementing the commands are empty stubs

[PATCH v2 10/18] xen/pvcalls: implement listen command

Call inet_listen to implement the listen command. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git

[PATCH v2 07/18] xen/pvcalls: implement socket command

Just reply with success to the other end for now. Delay the allocation of the actual socket to bind and/or connect. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 29 - 1 file

[PATCH v2 10/18] xen/pvcalls: implement listen command

Call inet_listen to implement the listen command. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/xen/pvcalls-back.c

[PATCH v2 07/18] xen/pvcalls: implement socket command

Just reply with success to the other end for now. Delay the allocation of the actual socket to bind and/or connect. Signed-off-by: Stefano Stabellini CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- drivers/xen/pvcalls-back.c | 29 - 1 file changed, 28

[PATCH v2 11/18] xen/pvcalls: implement accept command

Implement the accept command by calling inet_accept. To avoid blocking in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get scheduled on sk_data_ready (for a passive socket, it means that there are connections to accept). Use the reqcopy field to store the request. Accept the

[PATCH v2 11/18] xen/pvcalls: implement accept command

Implement the accept command by calling inet_accept. To avoid blocking in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get scheduled on sk_data_ready (for a passive socket, it means that there are connections to accept). Use the reqcopy field to store the request. Accept the

Re: Widespread crashes in -next, bisected to 'mm: drop HASH_ADAPT'

On Fri, May 19, 2017 at 9:46 AM, Guenter Roeck <li...@roeck-us.net> wrote: > Hi, > > my qemu tests of next-20170519 show the following results: > total: 122 pass: 30 fail: 92 > > I won't bother listing all of the failures; they are available at > http://kerneltes

[PATCH v2 12/18] xen/pvcalls: implement poll command

Implement poll on passive sockets by requesting a delayed response with mappass->reqcopy, and reply back when there is data on the passive socket. Poll on active socket is unimplemented as by the spec, as the frontend should just wait for events and check the indexes on the indexes page. Only

  1   2   3   4   5   6   7   8   9   10   >