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

On May 18, 2018 11:25:32 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > >> Will it be ok just to use a global inline asm to set an “.include” >directive >> that gas would later process? (I can probably wrap it

[PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports

Move remaining sata configuration to stingray-sata.dtsi and enable ports based on NUM_SATA defined. Now, all that needs to be done is define NUM_SATA per board. Signed-off-by: Scott Branden --- .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64

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

On May 18, 2018 11:25:32 AM PDT, Linus Torvalds wrote: >On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > >> Will it be ok just to use a global inline asm to set an “.include” >directive >> that gas would later process? (I can probably wrap it in a C macro so >it >> won’t be too disgusting)

[PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports

Move remaining sata configuration to stingray-sata.dtsi and enable ports based on NUM_SATA defined. Now, all that needs to be done is define NUM_SATA per board. Signed-off-by: Scott Branden --- .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On Fri, May 18, 2018 at 11:13 AM Marc Zyngier wrote: > What I'd really like is to apply that patch knowing that: > - you have checked that with a released version of the compiler, you > don't observe any absolute address in any of the objects that are going > to be executed

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On Fri, May 18, 2018 at 11:13 AM Marc Zyngier wrote: > What I'd really like is to apply that patch knowing that: > - you have checked that with a released version of the compiler, you > don't observe any absolute address in any of the objects that are going > to be executed at EL2 on a mainline

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 02:03:25PM -0400, Josef Bacik wrote: > There's nothing stopping us from doing that, it just uses a kprobe to override > the function with our helper, so we could conceivably put it anywhere in the > function. The reason I limited it to individual functions was because it

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 02:03:25PM -0400, Josef Bacik wrote: > There's nothing stopping us from doing that, it just uses a kprobe to override > the function with our helper, so we could conceivably put it anywhere in the > function. The reason I limited it to individual functions was because it

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

On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > Will it be ok just to use a global inline asm to set an “.include” directive > that gas would later process? (I can probably wrap it in a C macro so it > won’t be too disgusting) Maybe. I'd almost prefer it to be the

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

On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote: > Will it be ok just to use a global inline asm to set an “.include” directive > that gas would later process? (I can probably wrap it in a C macro so it > won’t be too disgusting) Maybe. I'd almost prefer it to be the automatic kind of thing

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 11:14:45AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 01:09:48PM +0200, Thomas-Mich Richter escreveu: > > On 05/18/2018 12:29 PM, Sandipan Das wrote: > > > Can you please apply these two patches as well and then re-test? > > > > [1]

Re: [PATCH] perf tests: Fix regex for record+probe_libc_inet_pton.sh

Em Fri, May 18, 2018 at 11:14:45AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Fri, May 18, 2018 at 01:09:48PM +0200, Thomas-Mich Richter escreveu: > > On 05/18/2018 12:29 PM, Sandipan Das wrote: > > > Can you please apply these two patches as well and then re-test? > > > > [1]

[PATCH] selftests: bpf: config: enable NET_SCH_INGRESS for xdp_meta.sh

When running bpf's selftest test_xdp_meta.sh it fails: ./test_xdp_meta.sh Error: Specified qdisc not found. selftests: test_xdp_meta [FAILED] Need to enable CONFIG_NET_SCH_INGRESS and CONFIG_NET_CLS_ACT to get the test to pass. Fixes: 22c8852624fc ("bpf: improve selftests and add tests for meta

[PATCH] selftests: bpf: config: enable NET_SCH_INGRESS for xdp_meta.sh

When running bpf's selftest test_xdp_meta.sh it fails: ./test_xdp_meta.sh Error: Specified qdisc not found. selftests: test_xdp_meta [FAILED] Need to enable CONFIG_NET_SCH_INGRESS and CONFIG_NET_CLS_ACT to get the test to pass. Fixes: 22c8852624fc ("bpf: improve selftests and add tests for meta

Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH] hwrng: n2: fix spelling mistake: "restesting" -> "retesting"

Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] hwrng: n2: fix spelling mistake: "restesting" -> "retesting"

Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Sometimes unusable i2c-hid devices in 4.17-rcX

On Thu, May 17, 2018 at 4:44 PM, wrote: >> -Original Message- >> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com] >> Sent: Thursday, May 17, 2018 9:28 AM >> To: Limonciello, Mario >> Cc: linux-input; linux-kernel@vger.kernel.org >> Subject: Re:

Re: Sometimes unusable i2c-hid devices in 4.17-rcX

On Thu, May 17, 2018 at 4:44 PM, wrote: >> -Original Message- >> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com] >> Sent: Thursday, May 17, 2018 9:28 AM >> To: Limonciello, Mario >> Cc: linux-input; linux-kernel@vger.kernel.org >> Subject: Re: Sometimes unusable i2c-hid

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

- On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: [...] >> > I think you're right. So we have to introduce callsite to rseq_syscall() >> > in syscall path, something like: >> > >> > diff --git a/arch/powerpc/kernel/entry_64.S >> > b/arch/powerpc/kernel/entry_64.S >> >

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

- On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: [...] >> > I think you're right. So we have to introduce callsite to rseq_syscall() >> > in syscall path, something like: >> > >> > diff --git a/arch/powerpc/kernel/entry_64.S >> > b/arch/powerpc/kernel/entry_64.S >> >

Re: [PATCHv2][SMB3] Add kernel trace support

On Fri, May 18, 2018 at 1:00 AM, ronnie sahlberg wrote: > Fair enough. > > Onto a second point then, for future patches. > > There are a lot of places where we do not (yet) pass a tcon as argument. > Can we make a policy decision to mandate that every tracepoint MUST >

Re: [PATCHv2][SMB3] Add kernel trace support

On Fri, May 18, 2018 at 1:00 AM, ronnie sahlberg wrote: > Fair enough. > > Onto a second point then, for future patches. > > There are a lot of places where we do not (yet) pass a tcon as argument. > Can we make a policy decision to mandate that every tracepoint MUST > log tid, sid? > > And thus,

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On 18/05/18 18:56, Nick Desaulniers wrote: > + Andrey > > On Fri, May 18, 2018 at 10:45 AM Marc Zyngier wrote: >> On 18/05/18 18:40, Nick Desaulniers wrote: >>> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier > wrote: I'm going to ask the question

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On 18/05/18 18:56, Nick Desaulniers wrote: > + Andrey > > On Fri, May 18, 2018 at 10:45 AM Marc Zyngier wrote: >> On 18/05/18 18:40, Nick Desaulniers wrote: >>> On Fri, May 18, 2018 at 10:30 AM Marc Zyngier > wrote: I'm going to ask the question I've asked before when this patch cropped

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 01:49:12PM -0400, Kent Overstreet wrote: > On Fri, May 18, 2018 at 01:45:36PM -0400, Josef Bacik wrote: > > On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > > > These are all the remaining patches in my bcachefs tree that touch stuff > > > outside > > >

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 01:49:12PM -0400, Kent Overstreet wrote: > On Fri, May 18, 2018 at 01:45:36PM -0400, Josef Bacik wrote: > > On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > > > These are all the remaining patches in my bcachefs tree that touch stuff > > > outside > > >

Re: [PATCHv2] drm/i2c: tda998x: Remove VLA usage

On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The vla in reg_write_range is based on the length of data > passed. The one use of a non-constant size for this range is bounded by

Re: [PATCHv2] drm/i2c: tda998x: Remove VLA usage

On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The vla in reg_write_range is based on the length of data > passed. The one use of a non-constant size for this range is bounded by > the size buffer

[PATCH v11 0/2] blk-mq: Rework blk-mq timeout handling again

Hello Jens, This patch series reworks blk-mq timeout handling by introducing a state machine per request. Please consider this patch series for inclusion in the upstream kernel. Bart. Changes compared to v10: - In patch 1/2, added "default y if 64BIT" to the "config ARCH_HAVE_CMPXCHG64" entry

[PATCH v11 0/2] blk-mq: Rework blk-mq timeout handling again

Hello Jens, This patch series reworks blk-mq timeout handling by introducing a state machine per request. Please consider this patch series for inclusion in the upstream kernel. Bart. Changes compared to v10: - In patch 1/2, added "default y if 64BIT" to the "config ARCH_HAVE_CMPXCHG64" entry

[PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

The next patch in this series introduces a call to cmpxchg64() in the block layer core for those architectures on which this functionality is available. Make it possible to test whether cmpxchg64() is available by introducing CONFIG_ARCH_HAVE_CMPXCHG64. Signed-off-by: Bart Van Assche

[PATCH v11 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

The next patch in this series introduces a call to cmpxchg64() in the block layer core for those architectures on which this functionality is available. Make it possible to test whether cmpxchg64() is available by introducing CONFIG_ARCH_HAVE_CMPXCHG64. Signed-off-by: Bart Van Assche Cc: Catalin

[PATCH v11 2/2] blk-mq: Rework blk-mq timeout handling again

Recently the blk-mq timeout handling code was reworked. See also Tejun Heo, "[PATCHSET v4] blk-mq: reimplement timeout handling", 08 Jan 2018 (https://www.mail-archive.com/linux-block@vger.kernel.org/msg16985.html). This patch reworks the blk-mq timeout handling code again. The timeout handling

[PATCH v11 2/2] blk-mq: Rework blk-mq timeout handling again

Recently the blk-mq timeout handling code was reworked. See also Tejun Heo, "[PATCHSET v4] blk-mq: reimplement timeout handling", 08 Jan 2018 (https://www.mail-archive.com/linux-block@vger.kernel.org/msg16985.html). This patch reworks the blk-mq timeout handling code again. The timeout handling

Hello,

Hello, Good day, How are you today and your family, i hope you are in good health, My name is Mrs. Annabelle, i saw your email on Web. Media, I have something to discuss with you, please reply me for more information, Mrs. Annabelle Ed

Hello,

Hello, Good day, How are you today and your family, i hope you are in good health, My name is Mrs. Annabelle, i saw your email on Web. Media, I have something to discuss with you, please reply me for more information, Mrs. Annabelle Ed

Re: [PATCH] drm/gma500: Remove VLA

On Mon, Apr 9, 2018 at 2:06 PM, Laura Abbott wrote: > > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. Switch to a reasonable upper bound for the VLAs in > the gma500 driver. > > [1] https://lkml.org/lkml/2018/3/7/621 > >

Re: [PATCH] drm/gma500: Remove VLA

On Mon, Apr 9, 2018 at 2:06 PM, Laura Abbott wrote: > > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. Switch to a reasonable upper bound for the VLAs in > the gma500 driver. > > [1] https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Laura Abbott

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

On Fri, 2018-05-18 at 08:56 -0700, Christoph Hellwig wrote: > > --- 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; > > +

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

On Fri, 2018-05-18 at 08:56 -0700, Christoph Hellwig wrote: > > --- 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; > > +

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey On Fri, May 18, 2018 at 10:45 AM Marc Zyngier wrote: > On 18/05/18 18:40, Nick Desaulniers wrote: > > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > >> I'm going to ask the question I've asked before when this patch cropped > >> up

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey On Fri, May 18, 2018 at 10:45 AM Marc Zyngier wrote: > On 18/05/18 18:40, Nick Desaulniers wrote: > > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > >> I'm going to ask the question I've asked before when this patch cropped > >> up (must be the 4th time now): The previous

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

On Sat, 2018-05-19 at 03:13 +1000, James Morris wrote: > On Thu, 17 May 2018, Eric W. Biederman wrote: > > > Nacked-by: "Eric W. Biederman" > > > > Nack on this sharing nonsense. These two interfaces do not share any > > code in their implementations other than the if

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

On Sat, 2018-05-19 at 03:13 +1000, James Morris wrote: > On Thu, 17 May 2018, Eric W. Biederman wrote: > > > Nacked-by: "Eric W. Biederman" > > > > Nack on this sharing nonsense. These two interfaces do not share any > > code in their implementations other than the if statement to distinguish

Re: [PATCH] kvm: rename HINTS_DEDICATED to KVM_HINTS_REALTIME

On Fri, May 18, 2018 at 07:18:57PM +0200, Paolo Bonzini wrote: > On 18/05/2018 19:13, Eduardo Habkost wrote: > >> As much as we'd like to be helpful and validate input, you need a real > >> time host too. I'm not sure how we'd find out - I suggest we do not > >> bother for now. > > I'm worried

Re: [PATCH] kvm: rename HINTS_DEDICATED to KVM_HINTS_REALTIME

On Fri, May 18, 2018 at 07:18:57PM +0200, Paolo Bonzini wrote: > On 18/05/2018 19:13, Eduardo Habkost wrote: > >> As much as we'd like to be helpful and validate input, you need a real > >> time host too. I'm not sure how we'd find out - I suggest we do not > >> bother for now. > > I'm worried

htmldocs: include/linux/skbuff.h:850: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3acf4e395260e3bd30a6fa29ba7eada4bf7566ca commit: bf66337140c64c27fa37222b7abca7e49d63fb57 inet: frags: get rid of ipfrag_skb_cb/FRAG_CB date: 7 weeks ago reproduce: make htmldocs All warnings (new ones

htmldocs: include/linux/skbuff.h:850: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3acf4e395260e3bd30a6fa29ba7eada4bf7566ca commit: bf66337140c64c27fa37222b7abca7e49d63fb57 inet: frags: get rid of ipfrag_skb_cb/FRAG_CB date: 7 weeks ago reproduce: make htmldocs All warnings (new ones

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

On Fri, 2018-05-18 at 14:22 +, Nadav Amit wrote: > It is hard to make the code readable in C, readable in the generated asm, > and to follow the coding style imposed by checkpatch (e.g., no space between > the newline and the asm argument before it). Ignore checkpatch when you know better.

[PATCHv8] gpio: Remove VLA from gpiolib

The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix this but kmalloc is still more expensive than stack allocation. Introduce a fast path with a fixed size stack array to cover most

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

On Fri, 2018-05-18 at 14:22 +, Nadav Amit wrote: > It is hard to make the code readable in C, readable in the generated asm, > and to follow the coding style imposed by checkpatch (e.g., no space between > the newline and the asm argument before it). Ignore checkpatch when you know better.

[PATCHv8] gpio: Remove VLA from gpiolib

The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix this but kmalloc is still more expensive than stack allocation. Introduce a fast path with a fixed size stack array to cover most

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

From: Andrea Greco Date: Fri, 18 May 2018 14:18:41 +0200 > In com20020.c found this: > /* FIXME: do this some other way! */ > if (!dev->dev_addr[0]) > dev->dev_addr[0] = arcnet_inb(ioaddr, 8); > > NODE-ID, must be univoque, for all arcnet network. > My previews

Re: [PATCH 1/4] arcnet: com20020: Add com20020 io mapped version

From: Andrea Greco Date: Fri, 18 May 2018 14:18:41 +0200 > In com20020.c found this: > /* FIXME: do this some other way! */ > if (!dev->dev_addr[0]) > dev->dev_addr[0] = arcnet_inb(ioaddr, 8); > > NODE-ID, must be univoque, for all arcnet network. > My previews idea was take random value but,

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

On Fri, May 18, 2018 at 09:18:14AM +0200, Ingo Molnar wrote: > The concept of built-in kernel tooling working at the machine code level is > just > so powerful - we should have added our own KCC compiler 20 years ago. ...for two very serious reasons * C as a language moves very slowly, last

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

On Fri, May 18, 2018 at 09:18:14AM +0200, Ingo Molnar wrote: > The concept of built-in kernel tooling working at the machine code level is > just > so powerful - we should have added our own KCC compiler 20 years ago. ...for two very serious reasons * C as a language moves very slowly, last

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

> Was this tested with uas or usb-storage? On both. dd works either way. > Are you certain Oliver's new code was executed? If you put > US_FL_NO_WP_DETECT only in unusual_devs.h and not in ususual_uas.h then > it would not affect the uas driver. Yes, the code ran. Further debugging shows

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

> Was this tested with uas or usb-storage? On both. dd works either way. > Are you certain Oliver's new code was executed? If you put > US_FL_NO_WP_DETECT only in unusual_devs.h and not in ususual_uas.h then > it would not affect the uas driver. Yes, the code ran. Further debugging shows

Re: [PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

Punit Agrawal writes: > Tsukada-san, > > I am not familiar with memcg so can't comment about whether the patchset > is the right way to solve the problem outlined in the cover letter but > had a couple of comments about this patch. > > TSUKADA Koutaro

Re: [PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

Punit Agrawal writes: > Tsukada-san, > > I am not familiar with memcg so can't comment about whether the patchset > is the right way to solve the problem outlined in the cover letter but > had a couple of comments about this patch. > > TSUKADA Koutaro writes: > >> The current memcg

Re: [PATCH] idr: fix invalid ptr dereference on item delete

It'd be nice if you cc'd the person who wrote the code you're patching. You'd get a response a lot quicker than waiting until I happened to notice the email in a different forum. Thanks for finding the situation that leads to the bug. Your fix is incorrect; it's legitimate to store a NULL value

Re: [PATCH] idr: fix invalid ptr dereference on item delete

It'd be nice if you cc'd the person who wrote the code you're patching. You'd get a response a lot quicker than waiting until I happened to notice the email in a different forum. Thanks for finding the situation that leads to the bug. Your fix is incorrect; it's legitimate to store a NULL value

Re: seq_putc is preferable to seq_puts

On Fri, 2018-05-18 at 07:09 -0700, Matthew Wilcox wrote: > Hi Joe, > > A nice checkpatch addition would be to look for seq_puts(x, "s") > and recommend the author use seq_putc(x, 's') instead. The primary > offender is seq_puts(x, "\n") (a hundred or so, scattered throughout > the kernel), but

Re: seq_putc is preferable to seq_puts

On Fri, 2018-05-18 at 07:09 -0700, Matthew Wilcox wrote: > Hi Joe, > > A nice checkpatch addition would be to look for seq_puts(x, "s") > and recommend the author use seq_putc(x, 's') instead. The primary > offender is seq_puts(x, "\n") (a hundred or so, scattered throughout > the kernel), but

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > I never understood the need for this direction. And if memory serves me > right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to think carefully about this: dma_map_single(,

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > I never understood the need for this direction. And if memory serves me > right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to think carefully about this: dma_map_single(,

Re: [PATCH] PM / devfreq: Fix handling of min/max_freq == 0

On Fri, May 18, 2018 at 08:27:55AM +0900, Chanwoo Choi wrote: > Hi, > > Please resend the patch with related other patches. > It is hard to check the dependency/sequence of your patches. The three patches (excluding the RFC) I sent in the past days are independent from each other and can be

Re: [PATCH] PM / devfreq: Fix handling of min/max_freq == 0

On Fri, May 18, 2018 at 08:27:55AM +0900, Chanwoo Choi wrote: > Hi, > > Please resend the patch with related other patches. > It is hard to check the dependency/sequence of your patches. The three patches (excluding the RFC) I sent in the past days are independent from each other and can be

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 01:45:36PM -0400, Josef Bacik wrote: > On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > > These are all the remaining patches in my bcachefs tree that touch stuff > > outside > > fs/bcachefs. Not all of them are suitable for inclusion as is, I wanted to

Re: [PATCH] net: mvpp2: typo and cosmetic fixes

From: Antoine Tenart Date: Fri, 18 May 2018 14:34:51 +0200 > This patch on the Marvell PPv2 driver is only cosmetic. Two typos are > removed as well as other cosmetic fixes, such as extra new lines or tabs > vs spaces. > > Suggested-by: Stefan Chulski

Re: [PATCH] net: mvpp2: typo and cosmetic fixes

From: Antoine Tenart Date: Fri, 18 May 2018 14:34:51 +0200 > This patch on the Marvell PPv2 driver is only cosmetic. Two typos are > removed as well as other cosmetic fixes, such as extra new lines or tabs > vs spaces. > > Suggested-by: Stefan Chulski > Signed-off-by: Antoine Tenart Applied,

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 01:45:36PM -0400, Josef Bacik wrote: > On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > > These are all the remaining patches in my bcachefs tree that touch stuff > > outside > > fs/bcachefs. Not all of them are suitable for inclusion as is, I wanted to

Re: [PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

Tsukada-san, I am not familiar with memcg so can't comment about whether the patchset is the right way to solve the problem outlined in the cover letter but had a couple of comments about this patch. TSUKADA Koutaro writes: > The current memcg implementation assumes that

Re: [PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

Tsukada-san, I am not familiar with memcg so can't comment about whether the patchset is the right way to solve the problem outlined in the cover letter but had a couple of comments about this patch. TSUKADA Koutaro writes: > The current memcg implementation assumes that the compound page is

Re: [PATCH] hippi: fix spelling mistake: "Framming" -> "Framing"

From: Colin King Date: Fri, 18 May 2018 11:09:22 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in printk message text > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH] hippi: fix spelling mistake: "Framming" -> "Framing"

From: Colin King Date: Fri, 18 May 2018 11:09:22 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in printk message text > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > These are all the remaining patches in my bcachefs tree that touch stuff > outside > fs/bcachefs. Not all of them are suitable for inclusion as is, I wanted to get > some discussion first. > > * pagecache add lock > > This is

Re: [PATCH 00/10] RFC: assorted bcachefs patches

On Fri, May 18, 2018 at 03:48:58AM -0400, Kent Overstreet wrote: > These are all the remaining patches in my bcachefs tree that touch stuff > outside > fs/bcachefs. Not all of them are suitable for inclusion as is, I wanted to get > some discussion first. > > * pagecache add lock > > This is

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

On Fri, May 18, 2018 at 08:53:30AM -0700, Christoph Hellwig wrote: > 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

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

On Fri, May 18, 2018 at 08:53:30AM -0700, Christoph Hellwig wrote: > 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

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On 18/05/18 18:40, Nick Desaulniers wrote: > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: >> I'm going to ask the question I've asked before when this patch cropped >> up (must be the 4th time now): > >> Is it guaranteed that this is the only case where LLVM/clang

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On 18/05/18 18:40, Nick Desaulniers wrote: > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: >> I'm going to ask the question I've asked before when this patch cropped >> up (must be the 4th time now): > >> Is it guaranteed that this is the only case where LLVM/clang is going to >> generate

Re: [PATCH] net/atheros: fix spelling mistake: "Ddescription" -> "Description"

From: Colin King Date: Fri, 18 May 2018 10:22:06 +0100 > From: Colin Ian King > > Trivial fix to spelling mistakes in name field text > > Signed-off-by: Colin Ian King > --- >

Re: [PATCH] net/atheros: fix spelling mistake: "Ddescription" -> "Description"

From: Colin King Date: Fri, 18 May 2018 10:22:06 +0100 > From: Colin Ian King > > Trivial fix to spelling mistakes in name field text > > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/atheros/atl1e/atl1e_param.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

On 05/17/2018 09:01 PM, Joonsoo Kim wrote: On Thu, May 17, 2018 at 10:53:32AM -0700, Laura Abbott wrote: On 05/17/2018 10:08 AM, Michal Hocko wrote: On Thu 17-05-18 18:49:47, Michal Hocko wrote: On Thu 17-05-18 16:58:32, Ville Syrjälä wrote: On Thu, May 17, 2018 at 04:36:29PM +0300, Ville

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

On 05/17/2018 09:01 PM, Joonsoo Kim wrote: On Thu, May 17, 2018 at 10:53:32AM -0700, Laura Abbott wrote: On 05/17/2018 10:08 AM, Michal Hocko wrote: On Thu 17-05-18 18:49:47, Michal Hocko wrote: On Thu 17-05-18 16:58:32, Ville Syrjälä wrote: On Thu, May 17, 2018 at 04:36:29PM +0300, Ville

Re: [GIT PULL] tpmdd updates for v4.18

s/jjs/linux-tpmdd.git tags/tpmdd-next-20180518 > > for you to fetch changes up to 424eaf910c329ab06ad03a527ef45dcf6a328f00: > > tpm: reduce polling time to usecs for even finer granularity (2018-05-18 > 10:00:01 +0300) Pulled to git://git.kernel.org/pub/scm/linux/kernel/git/

Re: [GIT PULL] tpmdd updates for v4.18

s/jjs/linux-tpmdd.git tags/tpmdd-next-20180518 > > for you to fetch changes up to 424eaf910c329ab06ad03a527ef45dcf6a328f00: > > tpm: reduce polling time to usecs for even finer granularity (2018-05-18 > 10:00:01 +0300) Pulled to git://git.kernel.org/pub/scm/linux/kernel/git/

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

On May 18, 2018 6:29:59 PM GMT+02:00, Nadav Amit wrote: >Funny. I found in my mailbox that you once wrote me: "It is a dumb >idea, it >doesn't bring us anything besides some superficial readability which >you >don't really need.” How about a proper quotation with the Message-id

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

On May 18, 2018 6:29:59 PM GMT+02:00, Nadav Amit wrote: >Funny. I found in my mailbox that you once wrote me: "It is a dumb >idea, it >doesn't bring us anything besides some superficial readability which >you >don't really need.” How about a proper quotation with the Message-id you're referring

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey (who reported testing this patch in https://github.com/ClangBuiltLinux/linux/issues/11) On Fri, May 18, 2018 at 10:40 AM Nick Desaulniers wrote: > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > > I'm going to ask the question I've

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

+ Andrey (who reported testing this patch in https://github.com/ClangBuiltLinux/linux/issues/11) On Fri, May 18, 2018 at 10:40 AM Nick Desaulniers wrote: > On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > > I'm going to ask the question I've asked before when this patch cropped > > up

Re: [PATCH v3 0/5]

> Marc Zyngier hat am 18. Mai 2018 um 18:41 geschrieben: > > > [/me beats himself for not writing a subject line...] > > On 18/05/18 17:29, Vince Weaver wrote: > > On Fri, 18 May 2018, Marc Zyngier wrote: > > > >> There is also the case of people natively running 32bit

Re: [PATCH v3 0/5]

> Marc Zyngier hat am 18. Mai 2018 um 18:41 geschrieben: > > > [/me beats himself for not writing a subject line...] > > On 18/05/18 17:29, Vince Weaver wrote: > > On Fri, 18 May 2018, Marc Zyngier wrote: > > > >> There is also the case of people natively running 32bit kernels on > >> 64bit

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > I'm going to ask the question I've asked before when this patch cropped > up (must be the 4th time now): > Is it guaranteed that this is the only case where LLVM/clang is going to > generate absolute addresses instead

Re: [PATCH] arm64: kvm: use -fno-jump-tables with clang

On Fri, May 18, 2018 at 10:30 AM Marc Zyngier wrote: > I'm going to ask the question I've asked before when this patch cropped > up (must be the 4th time now): > Is it guaranteed that this is the only case where LLVM/clang is going to > generate absolute addresses instead of using relative

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