Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Abstracted out the arch specific code into the header file, and > added powerpc specific changes. > > a) added 4k-backed hpte, memory allocator, powerpc specific. > b) added three test case where the key is associated after the page is >

Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys

On 07/05/2017 02:22 PM, Ram Pai wrote: > Abstracted out the arch specific code into the header file, and > added powerpc specific changes. > > a) added 4k-backed hpte, memory allocator, powerpc specific. > b) added three test case where the key is associated after the page is >

[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Greetings, I met $subject in master-rt post drm merge, but taking the config (attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible. KERNEL: vmlinux-4.12.0.g9967468-preempt.gz DUMPFILE: vmcore CPUS: 8 DATE: Tue Jul 11 18:55:28 2017 UPTIME: 00:02:03 LOAD

[regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Greetings, I met $subject in master-rt post drm merge, but taking the config (attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible. KERNEL: vmlinux-4.12.0.g9967468-preempt.gz DUMPFILE: vmcore CPUS: 8 DATE: Tue Jul 11 18:55:28 2017 UPTIME: 00:02:03 LOAD

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: > From: Colin Ian King > > Don't populate array gamma_par_mask on the stack but instead make it > static. Makes the object code smaller by 148 bytes: > > Before: >text data bss dec

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote: > From: Colin Ian King > > Don't populate array gamma_par_mask on the stack but instead make it > static. Makes the object code smaller by 148 bytes: > > Before: >text data bss dec hex filename >2993

Re: [patches] Re: [PATCH 16/17] RISC-V: User-facing API

On Tue, 11 Jul 2017 07:01:32 PDT (-0700), james.ho...@imgtec.com wrote: > Hi Christoph, > > On Tue, Jul 11, 2017 at 06:39:48AM -0700, Christoph Hellwig wrote: >> > +#ifdef CONFIG_64BIT >> > +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, >> > + unsigned long, prot, unsigned long,

Re: [patches] Re: [PATCH 16/17] RISC-V: User-facing API

On Tue, 11 Jul 2017 07:01:32 PDT (-0700), james.ho...@imgtec.com wrote: > Hi Christoph, > > On Tue, Jul 11, 2017 at 06:39:48AM -0700, Christoph Hellwig wrote: >> > +#ifdef CONFIG_64BIT >> > +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, >> > + unsigned long, prot, unsigned long,

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, 11 Jul 2017 06:55:28 PDT (-0700), h...@infradead.org wrote: > On Tue, Jul 11, 2017 at 02:22:15PM +0100, Will Deacon wrote: >> The problem is that by supporting these hypothetical designs that can't do >> atomics, you hurt sensible designs that *can* do the atomics because you >> force them

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, 11 Jul 2017 06:55:28 PDT (-0700), h...@infradead.org wrote: > On Tue, Jul 11, 2017 at 02:22:15PM +0100, Will Deacon wrote: >> The problem is that by supporting these hypothetical designs that can't do >> atomics, you hurt sensible designs that *can* do the atomics because you >> force them

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 08:03 PM, Kirill A. Shutemov wrote: > On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: >> On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: >>> >>> I reproduced this, and this is kasan bug: >>> >>>│0x84864897 mov >>>

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 08:03 PM, Kirill A. Shutemov wrote: > On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: >> On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: >>> >>> I reproduced this, and this is kasan bug: >>> >>>│0x84864897mov >>> $0x83f1d0b8,%rdi >>>

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

Hi Michael, On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > Ohh, scratch that. The patch is bogus. I have completely missed that > vmemmap_populate_hugepages already falls back to > vmemmap_populate_basepages. I have to revisit the bug report I have > received to see what happened

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

Hi Michael, On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > Ohh, scratch that. The patch is bogus. I have completely missed that > vmemmap_populate_hugepages already falls back to > vmemmap_populate_basepages. I have to revisit the bug report I have > received to see what happened

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 11:39:27AM -0700, Mark Rogers wrote: > Thank you for your feedback. I guess when making this patch I had the > preferred coding style in mind, but didn't ask myself if making the code > conform to it would truly improve readability. > > I agree with all of your comments.

Re: [PATCH] staging: ks7010: fix styling WARNINGs

On Fri, Jun 30, 2017 at 11:39:27AM -0700, Mark Rogers wrote: > Thank you for your feedback. I guess when making this patch I had the > preferred coding style in mind, but didn't ask myself if making the code > conform to it would truly improve readability. > > I agree with all of your comments.

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/11/2017 12:24 AM, Ryan Hsu wrote: > On 07/04/2017 08:59 AM, Andrey Ryabinin wrote: > >> On 07/04/2017 04:49 PM, Kalle Valo wrote: >>> Andrey Ryabinin writes: >>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with ath10k card.

Re: WARN_ON_ONCE(work > weight) in napi_poll()

On 07/11/2017 12:24 AM, Ryan Hsu wrote: > On 07/04/2017 08:59 AM, Andrey Ryabinin wrote: > >> On 07/04/2017 04:49 PM, Kalle Valo wrote: >>> Andrey Ryabinin writes: >>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a laptop with ath10k card.

Re: [PATCH] staging: rts5208: Replace embedded function names with "%s: ", __func__

On Fri, Jul 07, 2017 at 09:29:10PM +0530, Gaurav Pathak wrote: > staging: rts5208: Avoid possible defects when refactoring. > > Signed-off-by: Gaurav Pathak > --- > drivers/staging/rts5208/ms.c| 5 +++-- > drivers/staging/rts5208/rtsx.c | 4 ++-- >

Re: [PATCH] staging: rts5208: Replace embedded function names with "%s: ", __func__

On Fri, Jul 07, 2017 at 09:29:10PM +0530, Gaurav Pathak wrote: > staging: rts5208: Avoid possible defects when refactoring. > > Signed-off-by: Gaurav Pathak > --- > drivers/staging/rts5208/ms.c| 5 +++-- > drivers/staging/rts5208/rtsx.c | 4 ++-- >

RE: [PATCH 05/13] mpt3sas: Set NVMe device queue depth as 128

> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h > @@ -115,7 +115,7 @@ > > #define MPT3SAS_RAID_MAX_SECTORS 8192 > #define MPT3SAS_HOST_PAGE_SIZE_4K12 > - > +#define MPT3SAS_NVME_QUEUE_DEPTH 128 ... > + /*TODO-right Queue Depth?*/ > + qdepth =

RE: [PATCH 05/13] mpt3sas: Set NVMe device queue depth as 128

> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h > @@ -115,7 +115,7 @@ > > #define MPT3SAS_RAID_MAX_SECTORS 8192 > #define MPT3SAS_HOST_PAGE_SIZE_4K12 > - > +#define MPT3SAS_NVME_QUEUE_DEPTH 128 ... > + /*TODO-right Queue Depth?*/ > + qdepth =

Re: [PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

+ Lorenzo, since he deals with ACPI on arm64. On 11/07/17 17:45, Mark Salter wrote: > The function acpi_gsi_to_irq must return 0 on success as the caller > ghes_probe expects an 0 for success. This change also matches x86 > implementation. > > This patch was submitted around 4.5 timeframe but

Re: [PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

+ Lorenzo, since he deals with ACPI on arm64. On 11/07/17 17:45, Mark Salter wrote: > The function acpi_gsi_to_irq must return 0 on success as the caller > ghes_probe expects an 0 for success. This change also matches x86 > implementation. > > This patch was submitted around 4.5 timeframe but

Re: [PATCH] tracing/ring_buffer: Try harder to allocate

On Mon, Jul 10, 2017 at 11:05:00PM -0700, Joel Fernandes wrote: > ftrace can fail to allocate per-CPU ring buffer on systems with a large > number of CPUs coupled while large amounts of cache happening in the > page cache. Currently the ring buffer allocation doesn't retry in the VM >

Re: [PATCH] tracing/ring_buffer: Try harder to allocate

On Mon, Jul 10, 2017 at 11:05:00PM -0700, Joel Fernandes wrote: > ftrace can fail to allocate per-CPU ring buffer on systems with a large > number of CPUs coupled while large amounts of cache happening in the > page cache. Currently the ring buffer allocation doesn't retry in the VM >

[GIT PULL] Ceph updates for 4.13-rc1

Hi Linus, The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c: Linux 4.12 (2017-07-02 16:07:02 -0700) are available in the git repository at: https://github.com/ceph/ceph-client.git tags/ceph-for-4.13-rc1 for you to fetch changes up to

[GIT PULL] Ceph updates for 4.13-rc1

Hi Linus, The following changes since commit 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c: Linux 4.12 (2017-07-02 16:07:02 -0700) are available in the git repository at: https://github.com/ceph/ceph-client.git tags/ceph-for-4.13-rc1 for you to fetch changes up to

Re: [PATCH v1 1/1] gpio: gpio-crystalcove: Skip IRQ CTRL register update for virtual GPIOs

Hi Hans, On 7/11/2017 2:47 AM, Hans de Goede wrote: Hi, On 11-07-17 01:35, sathyanarayanan kuppuswamy wrote: Hi Hans, Do you have any comments on this patch ? It kind of fixes your patch, so would prefer to get your comments. Sorry I did not notice this patch before, did you Cc me ? As

Re: [PATCH v1 1/1] gpio: gpio-crystalcove: Skip IRQ CTRL register update for virtual GPIOs

Hi Hans, On 7/11/2017 2:47 AM, Hans de Goede wrote: Hi, On 11-07-17 01:35, sathyanarayanan kuppuswamy wrote: Hi Hans, Do you have any comments on this patch ? It kind of fixes your patch, so would prefer to get your comments. Sorry I did not notice this patch before, did you Cc me ? As

[PATCH] staging: fbtft: make const array gamma_par_mask static

From: Colin Ian King Don't populate array gamma_par_mask on the stack but instead make it static. Makes the object code smaller by 148 bytes: Before: textdata bss dec hex filename 29931104 040971001

[PATCH] staging: fbtft: make const array gamma_par_mask static

From: Colin Ian King Don't populate array gamma_par_mask on the stack but instead make it static. Makes the object code smaller by 148 bytes: Before: textdata bss dec hex filename 29931104 040971001 drivers/staging/fbtft/fb_st7789v.o After: text

Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 11/07/17 18:17, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote: > > delta_ns = time - j_sg_cpu->last_update; > > if (delta_ns > TICK_NSEC) { > > j_sg_cpu->iowait_boost = 0; > > - continue; > > +

Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 11/07/17 18:17, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote: > > delta_ns = time - j_sg_cpu->last_update; > > if (delta_ns > TICK_NSEC) { > > j_sg_cpu->iowait_boost = 0; > > - continue; > > +

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Tony Lindgren wrote: > * Linus Torvalds [170711 08:40]: > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote: > > > > > > Ah. Now that makes sense. > > > > > > Unpatched the ordering is: > > > > > >

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Tony Lindgren wrote: > * Linus Torvalds [170711 08:40]: > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote: > > > > > > Ah. Now that makes sense. > > > > > > Unpatched the ordering is: > > > > > > chip_bus_lock(desc); > > >

Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in different mount namespace

On Tue, Jul 11, 2017 at 09:51:16AM -0300, Arnaldo Carvalho de Melo wrote: > Right, we need to use the build-id and look it up in a database > populated somehow. > > perf right now, by default, collects the build-ids in a table, at the > end of the recording session, trying not to disrupt the

Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in different mount namespace

On Tue, Jul 11, 2017 at 09:51:16AM -0300, Arnaldo Carvalho de Melo wrote: > Right, we need to use the build-id and look it up in a database > populated somehow. > > perf right now, by default, collects the build-ids in a table, at the > end of the recording session, trying not to disrupt the

Re: [PATCH 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h

On Fri, Jul 07, 2017 at 01:47:04AM +, Craig Inches wrote: > This fixes multiple block statements found not to match > style as per checkpatch > > Signed-off-by: Craig Inches > --- > drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 > + > 1

Re: [PATCH 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h

On Fri, Jul 07, 2017 at 01:47:04AM +, Craig Inches wrote: > This fixes multiple block statements found not to match > style as per checkpatch > > Signed-off-by: Craig Inches > --- > drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 > + > 1 file changed, 81

Re: [PATCH 1/4] Staging: Luster: Clean up line over 80Char in lib-lnet.h

On Fri, Jul 07, 2017 at 01:46:42AM +, Craig Inches wrote: > This patch fixes a warning generated by checkpatch for > a line over 80 characters. > > Signed-off-by: Craig Inches > --- > drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 3 ++- > 1 file changed, 2

Re: [PATCH 1/4] Staging: Luster: Clean up line over 80Char in lib-lnet.h

On Fri, Jul 07, 2017 at 01:46:42AM +, Craig Inches wrote: > This patch fixes a warning generated by checkpatch for > a line over 80 characters. > > Signed-off-by: Craig Inches > --- > drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

Quoting Stefan Berger (Stefan bergerstef...@linux.vnet.ibm.com): > er.kernel.org> > X-Mailing-List: linux-kernel@vger.kernel.org > Content-Length: 19839 > Lines: 700 > X-UID: 24770 > Status: RO > > From: Stefan Berger >

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

Quoting Stefan Berger (Stefan bergerstef...@linux.vnet.ibm.com): > er.kernel.org> > X-Mailing-List: linux-kernel@vger.kernel.org > Content-Length: 19839 > Lines: 700 > X-UID: 24770 > Status: RO > > From: Stefan Berger > > This patch enables

Re: [PATCH] scsi: hisi_sas: make several const arrays static

On 11/07/2017 13:11, Colin King wrote: From: Colin Ian King Don't populate various tables on the stack but make them static const. Makes the object code smaller by over 280 bytes: Before: textdata bss dec hex filename 398875080 64

Re: [PATCH] scsi: hisi_sas: make several const arrays static

On 11/07/2017 13:11, Colin King wrote: From: Colin Ian King Don't populate various tables on the stack but make them static const. Makes the object code smaller by over 280 bytes: Before: textdata bss dec hex filename 398875080 64 45031afe7 hisi_sas_v2_hw.o

Re: [PATCH] gpu: host1x: Free the IOMMU domain when there is no device to attach

On 07/11/2017 05:44 PM, Paul Kocialkowski wrote: On Tue, 2017-07-11 at 14:37 +, Marcel Ziswiler wrote: On Tue, 2017-07-11 at 11:49 +0300, Paul Kocialkowski wrote: On Mon, 2017-07-10 at 21:33 +0200, Paul Kocialkowski wrote: When there is no device to attach to the IOMMU domain, as may be

Re: [PATCH] gpu: host1x: Free the IOMMU domain when there is no device to attach

On 07/11/2017 05:44 PM, Paul Kocialkowski wrote: On Tue, 2017-07-11 at 14:37 +, Marcel Ziswiler wrote: On Tue, 2017-07-11 at 11:49 +0300, Paul Kocialkowski wrote: On Mon, 2017-07-10 at 21:33 +0200, Paul Kocialkowski wrote: When there is no device to attach to the IOMMU domain, as may be

Re: [PATCH 390/390] staging:rtl8723bs:core:rtw_btcoex: Fixed checkpatch.pl warning on 'Comparisons should place the constant on the right side of the test'.

On Wed, Jul 05, 2017 at 12:49:52PM +0530, Shreeya Patel wrote: > Fixed a coding style issue. > > Signed-off-by: Shreeya Patel > --- > drivers/staging/rtl8723bs/core/rtw_btcoex.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Where are the 329 other

Re: [PATCH 390/390] staging:rtl8723bs:core:rtw_btcoex: Fixed checkpatch.pl warning on 'Comparisons should place the constant on the right side of the test'.

On Wed, Jul 05, 2017 at 12:49:52PM +0530, Shreeya Patel wrote: > Fixed a coding style issue. > > Signed-off-by: Shreeya Patel > --- > drivers/staging/rtl8723bs/core/rtw_btcoex.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Where are the 329 other patches in this series? I can't

Re: [PATCH 7/7] Staging: rtl8712 : rtl871x_io.c:fix coding style of kmalloc usage

On Tue, Jul 04, 2017 at 04:11:31PM +0530, Jaya Durga wrote: > CHECK: multiple assignments should be avoided > CHECK: Prefer kmalloc(sizeof(*pintf_hdl->pintfpriv)...) > over kmalloc(sizeof(struct intf_priv)...) > > Signed-off-by: Jaya Durga > --- >

Re: [PATCH 7/7] Staging: rtl8712 : rtl871x_io.c:fix coding style of kmalloc usage

On Tue, Jul 04, 2017 at 04:11:31PM +0530, Jaya Durga wrote: > CHECK: multiple assignments should be avoided > CHECK: Prefer kmalloc(sizeof(*pintf_hdl->pintfpriv)...) > over kmalloc(sizeof(struct intf_priv)...) > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/rtl871x_io.c | 3 ++- >

Re: [PATCH 2/6] Staging: rtl8712 : os_intfs.c: use octal permission representation

On Tue, Jul 04, 2017 at 11:31:15AM +0530, Jaya Durga wrote: > Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not > preferred. > Consider using octal permissions '0644'. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/os_intfs.c | 2 +- >

Re: [PATCH 2/6] Staging: rtl8712 : os_intfs.c: use octal permission representation

On Tue, Jul 04, 2017 at 11:31:15AM +0530, Jaya Durga wrote: > Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not > preferred. > Consider using octal permissions '0644'. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/os_intfs.c | 2 +- > 1 file changed, 1

Re: [PATCH 2/6] Staging: rtl8712 : os_intfs.c: use octal permission representation

On Fri, Jun 30, 2017 at 11:28:13AM +0530, Jaya Durga wrote: > Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not > preferred. > Consider using octal permissions '0644'. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/os_intfs.c | 2 +- > 1

Re: [PATCH 2/6] Staging: rtl8712 : os_intfs.c: use octal permission representation

On Fri, Jun 30, 2017 at 11:28:13AM +0530, Jaya Durga wrote: > Fix checkpatch.pl Warning: Symbolic permissions 'S_IRUGO | S_IWUSR' are not > preferred. > Consider using octal permissions '0644'. > > Signed-off-by: Jaya Durga > --- > drivers/staging/rtl8712/os_intfs.c | 2 +- > 1 file changed, 1

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

On Thu, Jul 06, 2017 at 12:43:15PM +0530, Jaya Durga wrote: > Replace all instances of (1 << 27) with BIT(27) to fix > checkpatch check messages > > Signed-off-by: Jaya Durga > --- > drivers/staging/lustre/lustre/include/lustre_compat.h | 2 +- > 1 file changed, 1

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

On Thu, Jul 06, 2017 at 12:43:15PM +0530, Jaya Durga wrote: > Replace all instances of (1 << 27) with BIT(27) to fix > checkpatch check messages > > Signed-off-by: Jaya Durga > --- > drivers/staging/lustre/lustre/include/lustre_compat.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, 11 Jul 2017 06:22:15 PDT (-0700), will.dea...@arm.com wrote: > On Mon, Jul 10, 2017 at 01:00:29PM -0700, Palmer Dabbelt wrote: >> On Thu, 06 Jul 2017 08:45:13 PDT (-0700), will.dea...@arm.com wrote: >> > On Thu, Jul 06, 2017 at 08:34:27AM -0700, Christoph Hellwig wrote: >> >> On Thu, Jul

Re: [PATCH 8/9] RISC-V: User-facing API

On Tue, 11 Jul 2017 06:22:15 PDT (-0700), will.dea...@arm.com wrote: > On Mon, Jul 10, 2017 at 01:00:29PM -0700, Palmer Dabbelt wrote: >> On Thu, 06 Jul 2017 08:45:13 PDT (-0700), will.dea...@arm.com wrote: >> > On Thu, Jul 06, 2017 at 08:34:27AM -0700, Christoph Hellwig wrote: >> >> On Thu, Jul

Re: [PATCH] drivers/staging/wilc1000: fix sparse warning: right shift by bigger than source value

On Mon, Jul 10, 2017 at 04:57:31PM +0800, Rui Teng wrote: > This patch sets memory to zero directly to avoid unnecessary shift and > bitwise operations on bool type, which can fix a sparse warning and also > improve performance. It does? How did you measure the performance impact? What was now

Re: [PATCH] btrfs: resume qgroup rescan on rw remount

On Mon, Jul 10, 2017 at 04:56:36PM +0300, Nikolay Borisov wrote: > On 10.07.2017 16:12, Nikolay Borisov wrote: > > On 4.07.2017 14:49, Aleksa Sarai wrote: > >> Several distributions mount the "proper root" as ro during initrd and > >> then remount it as rw before pivot_root(2). Thus, if a rescan

Re: [PATCH] drivers/staging/wilc1000: fix sparse warning: right shift by bigger than source value

On Mon, Jul 10, 2017 at 04:57:31PM +0800, Rui Teng wrote: > This patch sets memory to zero directly to avoid unnecessary shift and > bitwise operations on bool type, which can fix a sparse warning and also > improve performance. It does? How did you measure the performance impact? What was now

Re: [PATCH] btrfs: resume qgroup rescan on rw remount

On Mon, Jul 10, 2017 at 04:56:36PM +0300, Nikolay Borisov wrote: > On 10.07.2017 16:12, Nikolay Borisov wrote: > > On 4.07.2017 14:49, Aleksa Sarai wrote: > >> Several distributions mount the "proper root" as ro during initrd and > >> then remount it as rw before pivot_root(2). Thus, if a rescan

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: > On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > > > I reproduced this, and this is kasan bug: > > > >│0x84864897 mov > > $0x83f1d0b8,%rdi > >│0x8486489e

Re: [PATCH v2 1/7] pwm: rockchip: Add APB and function both clocks support

Hi, On Fri, Jul 7, 2017 at 9:03 PM, David Wu wrote: > @@ -6,7 +6,13 @@ Required properties: > "rockchip,rk3288-pwm": found on RK3288 SoC > "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC > - reg: physical base address and length of the controller's

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On Tue, Jul 11, 2017 at 07:45:48PM +0300, Andrey Ryabinin wrote: > On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > > > I reproduced this, and this is kasan bug: > > > >│0x84864897mov > > $0x83f1d0b8,%rdi > >│0x8486489e movabs > >

Re: [PATCH v2 1/7] pwm: rockchip: Add APB and function both clocks support

Hi, On Fri, Jul 7, 2017 at 9:03 PM, David Wu wrote: > @@ -6,7 +6,13 @@ Required properties: > "rockchip,rk3288-pwm": found on RK3288 SoC > "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC > - reg: physical base address and length of the controller's registers > - - clocks:

[PATCH] HID: multitouch: do not blindly set EV_KEY or EV_ABS bits

Now that input core insists on having dev->absinfo when device claims to generate EV_ABS in its dev->evbit, we should not be blindly setting that bit. The code in question might have been needed before input_set_abs_params() started setting EV_ABS in device's evbit, but not anymore, and is now

[PATCH] HID: multitouch: do not blindly set EV_KEY or EV_ABS bits

Now that input core insists on having dev->absinfo when device claims to generate EV_ABS in its dev->evbit, we should not be blindly setting that bit. The code in question might have been needed before input_set_abs_params() started setting EV_ABS in device's evbit, but not anymore, and is now

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 11/07/17 18:18, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:00AM +0100, Juri Lelli wrote: > > @@ -4065,6 +4067,9 @@ static int __sched_setscheduler(struct task_struct *p, > > } > > > > if (user) { > > + if (attr->sched_flags & SCHED_FLAG_SPECIAL) > > +

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 11/07/17 18:18, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:00AM +0100, Juri Lelli wrote: > > @@ -4065,6 +4067,9 @@ static int __sched_setscheduler(struct task_struct *p, > > } > > > > if (user) { > > + if (attr->sched_flags & SCHED_FLAG_SPECIAL) > > +

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

2017-07-11 1:40 GMT+02:00 Mickaël Salaün : > > On 10/07/2017 09:59, Salvatore Mesoraca wrote: >> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün : >>> Hi, >>> >>> I think it make sense to merge the W^X features with the TPE/shebang LSM >>> [1]. >>> >>> Regards, >>>

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

2017-07-11 1:40 GMT+02:00 Mickaël Salaün : > > On 10/07/2017 09:59, Salvatore Mesoraca wrote: >> 2017-07-09 21:35 GMT+02:00 Mickaël Salaün : >>> Hi, >>> >>> I think it make sense to merge the W^X features with the TPE/shebang LSM >>> [1]. >>> >>> Regards, >>> Mickaël >>> >>> [1] >>>

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

On Tue, Jul 11, 2017 at 10:14:42AM -0400, Waiman Long wrote: > The "join" was a special op for the children of cgroup root to join the > root as part of a threaded subtree. The children can instead use the > "enable" option to become a thread root which was the configuration > shown above. This

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

On Tue, Jul 11, 2017 at 10:14:42AM -0400, Waiman Long wrote: > The "join" was a special op for the children of cgroup root to join the > root as part of a threaded subtree. The children can instead use the > "enable" option to become a thread root which was the configuration > shown above. This

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

On Tue, Jul 11, 2017 at 8:05 AM, Jerome Glisse wrote: > On Tue, Jul 11, 2017 at 12:31:22AM -0700, Dan Williams wrote: >> On Wed, Jul 5, 2017 at 11:49 AM, Jerome Glisse wrote: >> > On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote: >> >> On Wed,

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

On Tue, Jul 11, 2017 at 8:05 AM, Jerome Glisse wrote: > On Tue, Jul 11, 2017 at 12:31:22AM -0700, Dan Williams wrote: >> On Wed, Jul 5, 2017 at 11:49 AM, Jerome Glisse wrote: >> > On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote: >> >> On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse

Re: [PATCH v2] [media] uvcvideo: Prevent heap overflow in uvc driver

Any comments / feedback ? Thanks, Guenter On Fri, Jun 30, 2017 at 09:21:56AM -0700, Guenter Roeck wrote: > The size of uvc_control_mapping is user controlled leading to a > potential heap overflow in the uvc driver. This adds a check to verify > the user provided size fits within the bounds of

Re: [PATCH v2] [media] uvcvideo: Prevent heap overflow in uvc driver

Any comments / feedback ? Thanks, Guenter On Fri, Jun 30, 2017 at 09:21:56AM -0700, Guenter Roeck wrote: > The size of uvc_control_mapping is user controlled leading to a > potential heap overflow in the uvc driver. This adds a check to verify > the user provided size fits within the bounds of

[PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

The function acpi_gsi_to_irq must return 0 on success as the caller ghes_probe expects an 0 for success. This change also matches x86 implementation. This patch was submitted around 4.5 timeframe but wasn't pushed because it didn't fix a real problem. Now that RAS/GHES patches are in kernel, this

[PATCH] acpi: Fix proper return code for function acpi_gsi_to_irq

The function acpi_gsi_to_irq must return 0 on success as the caller ghes_probe expects an 0 for success. This change also matches x86 implementation. This patch was submitted around 4.5 timeframe but wasn't pushed because it didn't fix a real problem. Now that RAS/GHES patches are in kernel, this

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > I reproduced this, and this is kasan bug: > >│0x84864897 mov > $0x83f1d0b8,%rdi >│0x8486489e movabs > $0xdc00,%rax >

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:15 PM, Andrey Ryabinin wrote: > > I reproduced this, and this is kasan bug: > >│0x84864897mov > $0x83f1d0b8,%rdi >│0x8486489e movabs > $0xdc00,%rax >│0x848648a8 push %rbp >│0x848648a9 mov

Re: [PATCH v3 7/9] vfio: Use driver_override to avert binding to compromising drivers

On Tue, 11 Jul 2017 11:46:27 +0200 Greg KH wrote: > On Mon, Jul 10, 2017 at 03:34:12PM -0600, Alex Williamson wrote: > > On Mon, 26 Jun 2017 10:08:55 +0100 > > Russell King - ARM Linux wrote: > > > > > On Tue, Jun 20, 2017 at 09:48:31AM -0600, Alex

Re: [PATCH v3 7/9] vfio: Use driver_override to avert binding to compromising drivers

On Tue, 11 Jul 2017 11:46:27 +0200 Greg KH wrote: > On Mon, Jul 10, 2017 at 03:34:12PM -0600, Alex Williamson wrote: > > On Mon, 26 Jun 2017 10:08:55 +0100 > > Russell King - ARM Linux wrote: > > > > > On Tue, Jun 20, 2017 at 09:48:31AM -0600, Alex Williamson wrote: > > > > If a device is

Re: [PATCH] KVM: arm/arm64: Fix bug in advertising KVM_CAP_MSI_DEVID capability

On 08/07/17 14:48, Shanker Donthineni wrote: > Commit 0e4e82f154e3 ("KVM: arm64: vgic-its: Enable ITS emulation as > a virtual MSI controller") tried to advertise KVM_CAP_MSI_DEVID, but > the code logic was not updating the dist->msis_require_devid field > correctly. If hypervisor tool creates the

Re: [PATCH] KVM: arm/arm64: Fix bug in advertising KVM_CAP_MSI_DEVID capability

On 08/07/17 14:48, Shanker Donthineni wrote: > Commit 0e4e82f154e3 ("KVM: arm64: vgic-its: Enable ITS emulation as > a virtual MSI controller") tried to advertise KVM_CAP_MSI_DEVID, but > the code logic was not updating the dist->msis_require_devid field > correctly. If hypervisor tool creates the

Re: [GIT pull] irq updates for 4.13

Hi, On Tue, Jul 11, 2017 at 09:20:44AM -0700, Tony Lindgren wrote: > * Sebastian Reichel [170711 07:41]: > > Ack, that also works for me. The strange thing is, that I added the > > following before and it did not print anything. > > > > if

Re: [GIT pull] irq updates for 4.13

Hi, On Tue, Jul 11, 2017 at 09:20:44AM -0700, Tony Lindgren wrote: > * Sebastian Reichel [170711 07:41]: > > Ack, that also works for me. The strange thing is, that I added the > > following before and it did not print anything. > > > > if (!pm_runtime_enabled(bank->chip.parent)) > >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote: > > > - tick_nohz_idle_enter costs 7058ns - 10726ns > > > - tick_nohz_idle_exit costs 8372ns - 20850ns > > > > Right, those are horrible expensive, but skipping them isn't 'hard', the > > only tricky bit is finding a condition

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote: > > > - tick_nohz_idle_enter costs 7058ns - 10726ns > > > - tick_nohz_idle_exit costs 8372ns - 20850ns > > > > Right, those are horrible expensive, but skipping them isn't 'hard', the > > only tricky bit is finding a condition

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 09:20]: > On Tue, 11 Jul 2017, Linus Torvalds wrote: > > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote: > > > > > > Ah. Now that makes sense. > > > > > > Unpatched the ordering is: > > > > > >

Re: [GIT pull] irq updates for 4.13

* Thomas Gleixner [170711 09:20]: > On Tue, 11 Jul 2017, Linus Torvalds wrote: > > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote: > > > > > > Ah. Now that makes sense. > > > > > > Unpatched the ordering is: > > > > > > chip_bus_lock(desc); > > >

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote: > On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > > From: Aubrey Li > > > > The system will enter a fast idle loop if the predicted idle period > > is shorter than the threshold. > > --- > >

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote: > On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote: > > From: Aubrey Li > > > > The system will enter a fast idle loop if the predicted idle period > > is shorter than the threshold. > > --- > > kernel/sched/idle.c | 9

Re: [GIT pull] irq updates for 4.13

On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote: > > What I do not understand here is that we have already power management > around all of that. > >irq_chip_pm_get(>irq_data); >... >chip_bus_lock(desc); >... >

Re: [GIT pull] irq updates for 4.13

On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote: > > What I do not understand here is that we have already power management > around all of that. > >irq_chip_pm_get(>irq_data); >... >chip_bus_lock(desc); >... >chip_bus_unlock_sync(desc); >...

[PATCH] ima: namespacing IMA (PoC) - experimental

This IMA namespacing patch set was initially implemented by Yuqiong Sun, while at IBM Research as a summer intern working with David Safford. It was subsequently modified and rebased by Stefan Berger and Mehmet Kayaalp. The resulting patches are being made available from the

[PATCH] f2fs: remove extra inode_unlock() in error path

This commit removes an extra inode_unlock() that is being done in function f2fs_ioc_setflags error path. While there, get rid of a useless 'out' label as well. Fixes: 0abd675e97e6 ("f2fs: support plain user/group quota") Signed-off-by: Luis Henriques --- fs/f2fs/file.c | 5

<    2   3   4   5   6   7   8   9   10   11   >