Re: [PATCH 02/10] block: Convert bio_set to mempool_init()

On Fri, May 18, 2018 at 09:20:28AM -0700, Christoph Hellwig wrote: > On Tue, May 08, 2018 at 09:33:50PM -0400, Kent Overstreet wrote: > > Minor performance improvement by getting rid of pointer indirections > > from allocation/freeing fastpaths. > > Can you please also send a long conversion for

Re: [PATCH 02/10] block: Convert bio_set to mempool_init()

On Fri, May 18, 2018 at 09:20:28AM -0700, Christoph Hellwig wrote: > On Tue, May 08, 2018 at 09:33:50PM -0400, Kent Overstreet wrote: > > Minor performance improvement by getting rid of pointer indirections > > from allocation/freeing fastpaths. > > Can you please also send a long conversion for

Re: [PATCH 02/10] block: Convert bio_set to mempool_init()

On Tue, May 08, 2018 at 09:33:50PM -0400, Kent Overstreet wrote: > Minor performance improvement by getting rid of pointer indirections > from allocation/freeing fastpaths. Can you please also send a long conversion for the remaining few bioset_create users? It would be rather silly to keep two

Re: [PATCH 02/10] block: Convert bio_set to mempool_init()

On Tue, May 08, 2018 at 09:33:50PM -0400, Kent Overstreet wrote: > Minor performance improvement by getting rid of pointer indirections > from allocation/freeing fastpaths. Can you please also send a long conversion for the remaining few bioset_create users? It would be rather silly to keep two

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

Hi Neil, 2018-05-18 15:05 GMT+02:00 Neil Armstrong : > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

Hi Neil, 2018-05-18 15:05 GMT+02:00 Neil Armstrong : > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly inside the mkbp event >

Re: [PATCH] scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()

On Fri, May 18, 2018 at 04:23:18PM +0200, Alexander Potapenko wrote: > This shall help avoid copying uninitialized memory to the userspace > when calling ioctl(fd, SG_IO) with an empty command. Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH] scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()

On Fri, May 18, 2018 at 04:23:18PM +0200, Alexander Potapenko wrote: > This shall help avoid copying uninitialized memory to the userspace > when calling ioctl(fd, SG_IO) with an empty command. Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH net v2] net: dsa: Do not register devlink for unused ports

From: Florian Fainelli Date: Thu, 17 May 2018 16:55:39 -0700 > Even if commit 1d27732f411d ("net: dsa: setup and teardown ports") indicated > that registering a devlink instance for unused ports is not a problem, and > this > is true, this can be confusing nonetheless, so

Re: [PATCH net v2] net: dsa: Do not register devlink for unused ports

From: Florian Fainelli Date: Thu, 17 May 2018 16:55:39 -0700 > Even if commit 1d27732f411d ("net: dsa: setup and teardown ports") indicated > that registering a devlink instance for unused ports is not a problem, and > this > is true, this can be confusing nonetheless, so let's not do it. > >

Re: [PATCH] objtool: Detect assembly code falling through to INT3 padding

On Fri, May 18, 2018 at 12:27:15AM -0700, H. Peter Anvin wrote: > On 05/18/18 00:18, Ingo Molnar wrote: > > > > Ok, this is cool, it addresses the robustness problem that INT3 padding > > introduced > > very nicely. > > > > The concept of built-in kernel tooling working at the machine code

Re: [PATCH] objtool: Detect assembly code falling through to INT3 padding

On Fri, May 18, 2018 at 12:27:15AM -0700, H. Peter Anvin wrote: > On 05/18/18 00:18, Ingo Molnar wrote: > > > > Ok, this is cool, it addresses the robustness problem that INT3 padding > > introduced > > very nicely. > > > > The concept of built-in kernel tooling working at the machine code

Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote: > On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote: >> pdev_nr and rhport can be controlled by user-space, hence leading to >> a potential exploitation of the Spectre variant 1 vulnerability. >> >> This issue was detected with

Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote: > On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote: >> pdev_nr and rhport can be controlled by user-space, hence leading to >> a potential exploitation of the Spectre variant 1 vulnerability. >> >> This issue was detected with

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

Looks fine, although I'd split it into a aio and block_dev patch. Also please wire this up for the fs/iomap.c direct I/O code, it should be essentially the same sniplet as in the block_dev.c code.

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

Looks fine, although I'd split it into a aio and block_dev patch. Also please wire this up for the fs/iomap.c direct I/O code, it should be essentially the same sniplet as in the block_dev.c code.

Re: [PATCH] scsi: dpt_i2o: Remove VLA usage

Kees, >> On the quest to remove all VLAs from the kernel[1] this moves the sg_list >> variable off the stack, as already done for other allocated buffers in >> adpt_i2o_passthru(). Additionally consolidates the error path for kfree(). > > Friendly ping! How does this look for v4.18? Applied to

Re: [PATCH] scsi: dpt_i2o: Remove VLA usage

Kees, >> On the quest to remove all VLAs from the kernel[1] this moves the sg_list >> variable off the stack, as already done for other allocated buffers in >> adpt_i2o_passthru(). Additionally consolidates the error path for kfree(). > > Friendly ping! How does this look for v4.18? Applied to

Re: [PATCH] gpu: ipu-csi: add rgb/bgr888 24bit support to mbus_code_to_bus_cfg

On Wed, 2018-05-02 at 14:52 +0200, Michael Grzeschik wrote: > The 24bit RGB format configuration is currently missing, we add > it now. > > Signed-off-by: Michael Grzeschik Applied to imx-drm/next. regards Philipp

Re: [PATCH] gpu: ipu-csi: add rgb/bgr888 24bit support to mbus_code_to_bus_cfg

On Wed, 2018-05-02 at 14:52 +0200, Michael Grzeschik wrote: > The 24bit RGB format configuration is currently missing, we add > it now. > > Signed-off-by: Michael Grzeschik Applied to imx-drm/next. regards Philipp

Re: [PATCH v4 2/3] fs: Convert kiocb rw_hint from enum to u16

> +/* ki_hint changed from enum to u16, make sure rw_hint fits into u16 */ I don't think this comment is very useful. > +static inline u16 ki_hint_valid(enum rw_hint hint) I'd call this ki_hint_validate. > +{ > + if (hint > MAX_KI_HINT) > + return 0; > + > + return hint;

Re: [PATCH v4 2/3] fs: Convert kiocb rw_hint from enum to u16

> +/* ki_hint changed from enum to u16, make sure rw_hint fits into u16 */ I don't think this comment is very useful. > +static inline u16 ki_hint_valid(enum rw_hint hint) I'd call this ki_hint_validate. > +{ > + if (hint > MAX_KI_HINT) > + return 0; > + > + return hint;

Re: [PATCH net-next 1/2] net: mscc: ocelot: add bonding support

On Fri, May 18, 2018 at 08:41:05AM +0200, Alexandre Belloni wrote: > Add link aggregation hardware offload support for Ocelot. Hi Alexandre What i don't see here is anything checking the mode being requested. If the user requests 'random' but the hardware only supports 'roundrobin', you probably

Re: [PATCH net-next 1/2] net: mscc: ocelot: add bonding support

On Fri, May 18, 2018 at 08:41:05AM +0200, Alexandre Belloni wrote: > Add link aggregation hardware offload support for Ocelot. Hi Alexandre What i don't see here is anything checking the mode being requested. If the user requests 'random' but the hardware only supports 'roundrobin', you probably

Re: [PATCH v4 1/3] block: add ioprio_check_cap function

On Thu, May 17, 2018 at 01:38:01PM -0700, adam.manzana...@wdc.com wrote: > From: Adam Manzanares > > Aio per command iopriority support introduces a second interface between > userland and the kernel capable of passing iopriority. The aio interface also > needs the

Re: [PATCH v4 1/3] block: add ioprio_check_cap function

On Thu, May 17, 2018 at 01:38:01PM -0700, adam.manzana...@wdc.com wrote: > From: Adam Manzanares > > Aio per command iopriority support introduces a second interface between > userland and the kernel capable of passing iopriority. The aio interface also > needs the ability to verify that the

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

Hi Akashi, On 18/05/18 11:39, AKASHI Takahiro wrote: > On Tue, May 15, 2018 at 06:11:15PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> Enabling crash dump (kdump) includes >>> * prepare contents of ELF header of a core dump file, /proc/vmcore, >>> using

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

Hi Akashi, On 18/05/18 11:39, AKASHI Takahiro wrote: > On Tue, May 15, 2018 at 06:11:15PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> Enabling crash dump (kdump) includes >>> * prepare contents of ELF header of a core dump file, /proc/vmcore, >>> using

Re: [PATCH 10/10] Dynamic fault injection

On Fri, May 18, 2018 at 03:49:18AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet Completely lacks any explanation or argument why it would be useful.

Re: [PATCH 08/10] bcache: move closures to lib/

On Fri, May 18, 2018 at 03:49:13AM -0400, Kent Overstreet wrote: > Prep work for bcachefs - being a fork of bcache it also uses closures Hell no. This code needs to go away and not actually be promoted to lib/.

Re: [PATCH 08/10] bcache: move closures to lib/

On Fri, May 18, 2018 at 03:49:13AM -0400, Kent Overstreet wrote: > Prep work for bcachefs - being a fork of bcache it also uses closures Hell no. This code needs to go away and not actually be promoted to lib/.

Re: [PATCH 10/10] Dynamic fault injection

On Fri, May 18, 2018 at 03:49:18AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet Completely lacks any explanation or argument why it would be useful.

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > [+ppp list and maintainer] > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's > easily > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl > doesn't > consider that the file can

Re: KASAN: use-after-free Read in remove_wait_queue (2)

On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote: > [+ppp list and maintainer] > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's > easily > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl > doesn't > consider that the file can

Re: [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree

Hi Akashi, On 18/05/18 08:42, AKASHI Takahiro wrote: > On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote: >> On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote: >>> On 25/04/18 07:26, AKASHI Takahiro wrote: diff --git a/arch/arm64/kernel/machine_kexec_file.c

Re: [PATCH v9 05/11] arm64: kexec_file: load initrd and device-tree

Hi Akashi, On 18/05/18 08:42, AKASHI Takahiro wrote: > On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote: >> On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote: >>> On 25/04/18 07:26, AKASHI Takahiro wrote: diff --git a/arch/arm64/kernel/machine_kexec_file.c

Re: [PATCH 06/10] Generic radix trees

Completely lacks any explanation, including why this should be in lib/. Also should come in the same series with actual users of the infrastructure.

Re: [PATCH 06/10] Generic radix trees

Completely lacks any explanation, including why this should be in lib/. Also should come in the same series with actual users of the infrastructure.

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote: > > Hi Kishon, Gustavo, > > > > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > >> In order to be able to provide correct

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

On Fri, May 18, 2018 at 08:19:20PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On Friday 18 May 2018 07:52 PM, Lorenzo Pieralisi wrote: > > Hi Kishon, Gustavo, > > > > On Mon, Apr 02, 2018 at 06:59:35PM +0530, Kishon Vijay Abraham I wrote: > >> In order to be able to provide correct

Re: [PATCH 05/10] don't use spin_lock_irqsave() unnecessarily

On Fri, May 18, 2018 at 03:49:08AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet Looks generally fine. A little changelog with an explanation of how we obviously never could get here with irqs disabled would be nice, though.

Re: [PATCH 05/10] don't use spin_lock_irqsave() unnecessarily

On Fri, May 18, 2018 at 03:49:08AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet Looks generally fine. A little changelog with an explanation of how we obviously never could get here with irqs disabled would be nice, though.

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 10:52, Stefan Berger wrote: > On 05/18/2018 10:39 AM, Mimi Zohar wrote: > > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote: > > > On 05/18/2018 08:53 AM, Mimi Zohar wrote: > > [..] > > > > > > > > > If so, which ones? We could probably refactor the current > > > > > > >

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 10:52, Stefan Berger wrote: > On 05/18/2018 10:39 AM, Mimi Zohar wrote: > > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote: > > > On 05/18/2018 08:53 AM, Mimi Zohar wrote: > > [..] > > > > > > > > > If so, which ones? We could probably refactor the current > > > > > > >

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 18.05.2018 17:57, David Hildenbrand wrote: > On 01.02.2018 17:33, Andrey Ryabinin wrote: >> KASAN uses different routines to map shadow for hot added memory and memory >> obtained in boot process. Attempt to offline memory onlined by normal boot >> process leads to this: >> >> Trying to

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 18.05.2018 17:57, David Hildenbrand wrote: > On 01.02.2018 17:33, Andrey Ryabinin wrote: >> KASAN uses different routines to map shadow for hot added memory and memory >> obtained in boot process. Attempt to offline memory onlined by normal boot >> process leads to this: >> >> Trying to

Re: [PATCH 02/10] mm: export find_get_pages()

On Fri, May 18, 2018 at 03:49:02AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet > --- > mm/filemap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 31dd888785..78b99019bf 100644 > --- a/mm/filemap.c > +++

Re: [PATCH 02/10] mm: export find_get_pages()

On Fri, May 18, 2018 at 03:49:02AM -0400, Kent Overstreet wrote: > Signed-off-by: Kent Overstreet > --- > mm/filemap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 31dd888785..78b99019bf 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@

Re: [PATCH 6/6] arm64: perf: Add support for chaining counters

Hi Robin, On 18/05/18 14:49, Robin Murphy wrote: On 18/05/18 11:22, Suzuki K Poulose wrote: Add support for chained event counters. PMUv3 allows chaining a pair of adjacent PMU counters (with the lower counter number being always "even"). The low counter is programmed to count the event of

Re: [PATCH 6/6] arm64: perf: Add support for chaining counters

Hi Robin, On 18/05/18 14:49, Robin Murphy wrote: On 18/05/18 11:22, Suzuki K Poulose wrote: Add support for chained event counters. PMUv3 allows chaining a pair of adjacent PMU counters (with the lower counter number being always "even"). The low counter is programmed to count the event of

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 10:39, Mimi Zohar wrote: > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote: > > On 05/18/2018 08:53 AM, Mimi Zohar wrote: > > [..] > > > If so, which ones? We could probably refactor the current > > integrity_audit_message() and have ima_parse_rule() call into it

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 10:39, Mimi Zohar wrote: > On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote: > > On 05/18/2018 08:53 AM, Mimi Zohar wrote: > > [..] > > > If so, which ones? We could probably refactor the current > > integrity_audit_message() and have ima_parse_rule() call into it

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 01.02.2018 17:33, Andrey Ryabinin wrote: > KASAN uses different routines to map shadow for hot added memory and memory > obtained in boot process. Attempt to offline memory onlined by normal boot > process leads to this: > > Trying to vfree() nonexistent vm area (5d3b34b9) >

Re: [PATCH] mm/kasan: Don't vfree() nonexistent vm_area.

On 01.02.2018 17:33, Andrey Ryabinin wrote: > KASAN uses different routines to map shadow for hot added memory and memory > obtained in boot process. Attempt to offline memory onlined by normal boot > process leads to this: > > Trying to vfree() nonexistent vm area (5d3b34b9) >

Re: [RFC PATCH 01/11] vfs: push __sync_blockdev calls down into sync_fs routines

> --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -1097,7 +1097,7 @@ xfs_fs_sync_fs( >* Doing anything during the async pass would be counterproductive. >*/ > if (!wait) > - return 0; > + goto out; > > xfs_log_force(mp, XFS_LOG_SYNC);

Re: [RFC PATCH 01/11] vfs: push __sync_blockdev calls down into sync_fs routines

> --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -1097,7 +1097,7 @@ xfs_fs_sync_fs( >* Doing anything during the async pass would be counterproductive. >*/ > if (!wait) > - return 0; > + goto out; > > xfs_log_force(mp, XFS_LOG_SYNC);

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 03:46:33PM +, Nadav Amit wrote: > In case you didn’t read the cover-letter: the patch-set does give a 2% > performance improvement for #PF-MADV_DONTNEED microbenchmark loop. I saw it but *micro*-benchmark doesn't tell me a whole lot. If that "improvement" is not

[PATCH] kernfs: fix dentry unexpected skip

kernfs_dir_next_pos() overlooks the situation that the dentry corresponding to a given pos object has already been inactive. Hence, when kernfs_dir_pos() returns the dentry with a hash value larger than the original one, kernfs_dir_next_pos() returns the dentry next to the one returned by

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 03:46:33PM +, Nadav Amit wrote: > In case you didn’t read the cover-letter: the patch-set does give a 2% > performance improvement for #PF-MADV_DONTNEED microbenchmark loop. I saw it but *micro*-benchmark doesn't tell me a whole lot. If that "improvement" is not

[PATCH] kernfs: fix dentry unexpected skip

kernfs_dir_next_pos() overlooks the situation that the dentry corresponding to a given pos object has already been inactive. Hence, when kernfs_dir_pos() returns the dentry with a hash value larger than the original one, kernfs_dir_next_pos() returns the dentry next to the one returned by

Re: [PATCH 01/10] mm: pagecache add lock

On Fri, May 18, 2018 at 06:13:06AM -0700, Matthew Wilcox wrote: > > Historically, the only problematic case has been direct IO, and people > > have been willing to say "well, if you mix buffered and direct IO you > > get what you deserve", and that's probably not unreasonable. But now we > > have

Re: [PATCH 01/10] mm: pagecache add lock

On Fri, May 18, 2018 at 06:13:06AM -0700, Matthew Wilcox wrote: > > Historically, the only problematic case has been direct IO, and people > > have been willing to say "well, if you mix buffered and direct IO you > > get what you deserve", and that's probably not unreasonable. But now we > > have

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 08:53, Mimi Zohar wrote: > On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote: > > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: > > [...] > > > >>> auxiliary record either by being converted to a syscall auxiliary record > > >>> by using current->audit_context rather than

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 08:53, Mimi Zohar wrote: > On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote: > > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: > > [...] > > > >>> auxiliary record either by being converted to a syscall auxiliary record > > >>> by using current->audit_context rather than

[PATCH] kernfs: fix dentry unexpected skip

kernfs_dir_next_pos() overlooks the situation that the dentry corresponding to a given pos object has already been inactive. Hence, when kernfs_dir_pos() returns the dentry with a hash value larger than the original one, kernfs_dir_next_pos() returns the dentry next to the one returned by

[PATCH] kernfs: fix dentry unexpected skip

kernfs_dir_next_pos() overlooks the situation that the dentry corresponding to a given pos object has already been inactive. Hence, when kernfs_dir_pos() returns the dentry with a hash value larger than the original one, kernfs_dir_next_pos() returns the dentry next to the one returned by

Re: [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On Fri, May 18, 2018 at 03:05:00PM +0200, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name > instead and will

Re: [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On Fri, May 18, 2018 at 03:05:00PM +0200, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name > instead and will

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

Borislav Petkov wrote: > On Fri, May 18, 2018 at 02:36:21PM +, Nadav Amit wrote: >> I didn’t try too hard to find more affected (micro)benchmarks, but I am >> pretty sure there are: > > So you being pretty sure there are, doesn't make me go, oh, ok, then, > this is an

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

Borislav Petkov wrote: > On Fri, May 18, 2018 at 02:36:21PM +, Nadav Amit wrote: >> I didn’t try too hard to find more affected (micro)benchmarks, but I am >> pretty sure there are: > > So you being pretty sure there are, doesn't make me go, oh, ok, then, > this is an uglification we should

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 07:49, Stefan Berger wrote: > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: > > On 2018-05-17 10:18, Stefan Berger wrote: > > > On 03/08/2018 06:21 AM, Richard Guy Briggs wrote: > > > > On 2018-03-05 09:24, Mimi Zohar wrote: > > > > > On Mon, 2018-03-05 at 08:50 -0500, Richard

Re: [PATCH] audit: add containerid support for IMA-audit

On 2018-05-18 07:49, Stefan Berger wrote: > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: > > On 2018-05-17 10:18, Stefan Berger wrote: > > > On 03/08/2018 06:21 AM, Richard Guy Briggs wrote: > > > > On 2018-03-05 09:24, Mimi Zohar wrote: > > > > > On Mon, 2018-03-05 at 08:50 -0500, Richard

[PATCH] net: sched: don't disable bh when accessing action idr

Underlying implementation of action map has changed and doesn't require disabling bh anymore. Replace all action idr spinlock usage with regular calls that do not disable bh. Signed-off-by: Vlad Buslov --- net/sched/act_api.c | 20 ++-- 1 file changed, 10

[PATCH] net: sched: don't disable bh when accessing action idr

Underlying implementation of action map has changed and doesn't require disabling bh anymore. Replace all action idr spinlock usage with regular calls that do not disable bh. Signed-off-by: Vlad Buslov --- net/sched/act_api.c | 20 ++-- 1 file changed, 10 insertions(+), 10

Re: WARNING in ip_recv_error

From: Eric Dumazet Date: Fri, 18 May 2018 08:30:43 -0700 > We probably need to revert Willem patch > (7ce875e5ecb8562fd44040f69bda96c999e38bbc) Is it really valid to reach ip_recv_err with an ipv6 socket?

Re: WARNING in ip_recv_error

From: Eric Dumazet Date: Fri, 18 May 2018 08:30:43 -0700 > We probably need to revert Willem patch > (7ce875e5ecb8562fd44040f69bda96c999e38bbc) Is it really valid to reach ip_recv_err with an ipv6 socket?

Re: [PATCH v3] sched/fair: update scale invariance of PELT

On 18 May 2018 at 17:16, Dietmar Eggemann wrote: > On 05/18/2018 10:36 AM, Peter Zijlstra wrote: >> >> >> Replying to the latest version available; given the current interest I >> figure I'd re-read some of the old threads and look at this stuff again. >> >> On Fri, Apr

Re: [PATCH v3] sched/fair: update scale invariance of PELT

On 18 May 2018 at 17:16, Dietmar Eggemann wrote: > On 05/18/2018 10:36 AM, Peter Zijlstra wrote: >> >> >> Replying to the latest version available; given the current interest I >> figure I'd re-read some of the old threads and look at this stuff again. >> >> On Fri, Apr 28, 2017 at 04:23:55PM

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 02:36:21PM +, Nadav Amit wrote: > I didn’t try too hard to find more affected (micro)benchmarks, but I am > pretty sure there are: So you being pretty sure there are, doesn't make me go, oh, ok, then, this is an uglification we should try to live with. It is still ugly

Re: [PATCH 2/6] x86: bug: prevent gcc distortions

On Fri, May 18, 2018 at 02:36:21PM +, Nadav Amit wrote: > I didn’t try too hard to find more affected (micro)benchmarks, but I am > pretty sure there are: So you being pretty sure there are, doesn't make me go, oh, ok, then, this is an uglification we should try to live with. It is still ugly

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

On Fri, 18 May 2018 11:21:06 -0400 Richard Guy Briggs wrote: > On 2018-05-18 09:56, Steve Grubb wrote: > > On Thu, 17 May 2018 17:56:00 -0400 > > Richard Guy Briggs wrote: > > > > > > During syscall events, the path info is returned in a a record > > > >

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

On Fri, 18 May 2018 11:21:06 -0400 Richard Guy Briggs wrote: > On 2018-05-18 09:56, Steve Grubb wrote: > > On Thu, 17 May 2018 17:56:00 -0400 > > Richard Guy Briggs wrote: > > > > > > During syscall events, the path info is returned in a a record > > > > simply called AUDIT_PATH, cwd info is

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

On Fri, May 18, 2018 at 10:52:17AM +0200, Heiko Stuebner wrote: > Am Freitag, 18. Mai 2018, 03:45:46 CEST schrieb Brian Norris: > > On Thu, May 17, 2018 at 6:41 PM, hl wrote: > > > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote: > > >> On Thu, May 17, 2018 at 05:18:00PM

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

On Fri, May 18, 2018 at 10:52:17AM +0200, Heiko Stuebner wrote: > Am Freitag, 18. Mai 2018, 03:45:46 CEST schrieb Brian Norris: > > On Thu, May 17, 2018 at 6:41 PM, hl wrote: > > > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote: > > >> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang

Re: [PATCH v10 25/27] ARM: davinci: add device tree support to timer

On 05/18/2018 01:05 AM, Sekhar Nori wrote: On Thursday 17 May 2018 08:39 PM, David Lechner wrote: On 05/17/2018 09:35 AM, Sekhar Nori wrote: Hi David, On Wednesday 09 May 2018 10:56 PM, David Lechner wrote: This adds device tree support to the davinci timer so that when clocks are moved to

Re: [PATCH v10 25/27] ARM: davinci: add device tree support to timer

On 05/18/2018 01:05 AM, Sekhar Nori wrote: On Thursday 17 May 2018 08:39 PM, David Lechner wrote: On 05/17/2018 09:35 AM, Sekhar Nori wrote: Hi David, On Wednesday 09 May 2018 10:56 PM, David Lechner wrote: This adds device tree support to the davinci timer so that when clocks are moved to

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

On Tue, May 15, 2018 at 06:12:59PM +0100, James Morse wrote: > Hi guys, > > (CC: +RobH, devicetree list) Thanks. > On 25/04/18 07:26, AKASHI Takahiro wrote: > > Enabling crash dump (kdump) includes > > * prepare contents of ELF header of a core dump file, /proc/vmcore, > > using

Re: [PATCH v9 07/11] arm64: kexec_file: add crash dump support

On Tue, May 15, 2018 at 06:12:59PM +0100, James Morse wrote: > Hi guys, > > (CC: +RobH, devicetree list) Thanks. > On 25/04/18 07:26, AKASHI Takahiro wrote: > > Enabling crash dump (kdump) includes > > * prepare contents of ELF header of a core dump file, /proc/vmcore, > > using

Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents

Hi, Dne petek, 18. maj 2018 ob 17:26:51 CEST je Maxime Ripard napisal(a): > On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej Škrabec wrote: > > > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to > > > lookup pll-2 either. > > > > It is highly unlikely this will be higher

Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents

Hi, Dne petek, 18. maj 2018 ob 17:26:51 CEST je Maxime Ripard napisal(a): > On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej Škrabec wrote: > > > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to > > > lookup pll-2 either. > > > > It is highly unlikely this will be higher

Re: [PATCH 2/2] kselftests: ftrace: Add tests for the preemptoff and irqsoff tracers

Hi Joel, 55ty jmnOn Thu, 17 May 2018 18:54:21 -0700 "Joel Fernandes (Google)" wrote: > Here we add unit tests for the preemptoff and irqsoff tracer by using a > kernel module introduced previously to trigger atomic sections in the > kernel. > > Cc: Steven Rostedt

Re: [PATCH 2/2] kselftests: ftrace: Add tests for the preemptoff and irqsoff tracers

Hi Joel, 55ty jmnOn Thu, 17 May 2018 18:54:21 -0700 "Joel Fernandes (Google)" wrote: > Here we add unit tests for the preemptoff and irqsoff tracer by using a > kernel module introduced previously to trigger atomic sections in the > kernel. > > Cc: Steven Rostedt > Cc: Peter Zilstra > Cc:

Re: WARNING in ip_recv_error

On 05/18/2018 05:08 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in ip_recv_error > (I resend the email since I mistakenly missed the subject in my previous > email. I'm sorry.) > > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which

Re: WARNING in ip_recv_error

On 05/18/2018 05:08 AM, DaeRyong Jeong wrote: > We report the crash: WARNING in ip_recv_error > (I resend the email since I mistakenly missed the subject in my previous > email. I'm sorry.) > > > This crash has been found in v4.17-rc1 using RaceFuzzer (a modified > version of Syzkaller), which

Re: [PATCH net-next ] net: mscc: Add SPDX identifier

From: Alexandre Belloni Date: Thu, 17 May 2018 21:23:05 +0200 > ocelot_qsys.h is missing the SPDX identfier, fix that. > > Signed-off-by: Alexandre Belloni Applied, thank you.

Re: [PATCH net-next ] net: mscc: Add SPDX identifier

From: Alexandre Belloni Date: Thu, 17 May 2018 21:23:05 +0200 > ocelot_qsys.h is missing the SPDX identfier, fix that. > > Signed-off-by: Alexandre Belloni Applied, thank you.

Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper

On Fri, 2018-05-18 at 07:58 -0700, Casey Schaufler wrote: > On 5/18/2018 4:30 AM, Mimi Zohar wrote: > > Having to define a separate LSM hook for each of the original, non > > kernel_read_file(), buffer based method callers, kind of makes sense, > > as the callers themselves are specific, but is

Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper

On Fri, 2018-05-18 at 07:58 -0700, Casey Schaufler wrote: > On 5/18/2018 4:30 AM, Mimi Zohar wrote: > > Having to define a separate LSM hook for each of the original, non > > kernel_read_file(), buffer based method callers, kind of makes sense, > > as the callers themselves are specific, but is

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

On 5/18/18 8:14 AM, Jens Axboe wrote: > On 5/17/18 2:38 PM, adam.manzana...@wdc.com wrote: >> From: Adam Manzanares >> >> This is the per-I/O equivalent of the ioprio_set system call. >> >> When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the >>

Re: [PATCH v4 3/3] fs: Add aio iopriority support for block_dev

On 5/18/18 8:14 AM, Jens Axboe wrote: > On 5/17/18 2:38 PM, adam.manzana...@wdc.com wrote: >> From: Adam Manzanares >> >> This is the per-I/O equivalent of the ioprio_set system call. >> >> When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the >> newly added kiocb ki_ioprio

<    4   5   6   7   8   9   10   11   12   13   >