RE: [PATCH 0/2] put_user_page*(): start converting the call sites

2018-12-05 Thread David Laight
From: John Hubbard > Sent: 05 December 2018 01:06 > On 12/4/18 9:10 AM, David Laight wrote: > > From: john.hubb...@gmail.com > >> Sent: 04 December 2018 00:17 > >> > >> Summary: I'd like these two patches to go into the next convenient cycle. > >&

RE: [PATCH 0/2] put_user_page*(): start converting the call sites

2018-12-04 Thread David Laight
From: john.hubb...@gmail.com > Sent: 04 December 2018 00:17 > > Summary: I'd like these two patches to go into the next convenient cycle. > I *think* that means 4.21. > > Details > > At the Linux Plumbers Conference, we talked about this approach [1], and > the primary lingering concern was

RE: [PATCH 2/8] lib/lzo: clean-up by introducing COPY16

2018-11-30 Thread David Laight
From: Dave Rodgman > Sent: 30 November 2018 11:48 > From: Matt Sealey > > Most compilers should be able to merge adjacent loads/stores of sizes > which are less than but effect a multiple of a machine word size (in > effect a memcpy() of a constant amount). However the semantics of the > macro

RE: [PATCH] x86/fpu: XRSTOR is expected to raise #GP

2018-11-28 Thread David Laight
From: H. Peter Anvin > Sent: 26 November 2018 19:50 > On 11/26/18 9:49 AM, Sebastian Andrzej Siewior wrote: > > On 2018-11-26 18:27:06 [+0100], Jann Horn wrote: > >> commit 75045f77f7a7 ("x86/extable: Introduce _ASM_EXTABLE_UA for uaccess > >> fixups") incorrectly replaced the fixup entry for

RE: [PATCH 3/3] lockdep: Use line-buffered printk() for lockdep messages.

2018-11-28 Thread David Laight
From: Steven Rostedt > > Steven told me on Plumbers conference that even few initial > > characters saved him a day few times. > > Yes, and that has happened more than once. I would reboot and retest > code that is crashing, and due to a triple fault, the machine would > reboot because of some

RE: Official Linux system wrapper library?

2018-11-28 Thread David Laight
From: David Newall > Sent: 23 November 2018 14:11 > > On 24/11/18 12:04 am, Florian Weimer wrote: > > But socketcall does not exist on all architectures. Neither does > > getpid, it's called getxpid on some architectures. > > ... > > I think it would be a poor approach to expose application

RE: [PATCH] arm: always update thread_info->syscall

2018-11-27 Thread David Laight
From: Russell King - ARM Linux > Sent: 27 November 2018 15:36 ... > There appears to be no documentation at all of this interface, so there > is no definition of how it is supposed to work or what it is supposed > to expose beyond what little information is in the original patch: > >

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-26 Thread David Laight
From: Linus Torvalds > Sent: 23 November 2018 16:36 ... > End result: we *used* to do this right. For the last eight years our > "memcpy_{to,from}io()" has been entirely broken, and apparently even > the people who noticed oddities like David, never reported it as > breakage but instead just

RE: [PATCH v4 2/5] nds32: Support FP emulation

2018-11-26 Thread David Laight
From: Vincent Chen > Sent: 26 November 2018 01:23 > On Fri, Nov 23, 2018 at 06:53:37PM +0800, David Laight wrote: > > From: Vincent Chen > > > Sent: 22 November 2018 03:15 > > > > > > The Andes FPU coprocessor does not support denormalized number handling. &g

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-26 Thread David Laight
From: Andy Lutomirski > Sent: 23 November 2018 19:11 > > On Nov 23, 2018, at 11:44 AM, Linus Torvalds > > wrote: > > > >> On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski > >> wrote: > >> > >> What is memcpy_to_io even supposed to do? I’m guessing it’s defined as > >> something like “copy

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-26 Thread David Laight
From: Linus Torvalds > Sent: 23 November 2018 16:36 > > On Fri, Nov 23, 2018 at 2:12 AM David Laight wrote: > > > > I've just patched my driver and redone the test on a 4.13 (ubuntu) kernel. > > Calling memcpy_fromio(kernel_buffer, PCIe_address, length) > > g

RE: [PATCH 4.19 00/42] 4.19.4-stable review

2018-11-23 Thread David Laight
From: Thomas Voegtle > Sent: 23 November 2018 15:41 > On Fri, 23 Nov 2018, Greg Kroah-Hartman wrote: > > > On Thu, Nov 22, 2018 at 09:53:35PM +0100, Thomas Voegtle wrote: > >> > >> Doesn't compile for me on OpenSuSE 15.0 (gcc 7.3.1): > >> > >> CALLscripts/checksyscalls.sh > >> DESCEND

RE: [PATCH] Add /proc/pid_generation

2018-11-23 Thread David Laight
From: Kevin Easton > Sent: 22 November 2018 11:20 > > On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote: > > This change adds a per-pid-namespace 64-bit generation number, > > incremented on PID rollover, and exposes it via a new proc file > > /proc/pid_generation. By examining

RE: [PATCH v4 2/5] nds32: Support FP emulation

2018-11-23 Thread David Laight
From: Vincent Chen > Sent: 22 November 2018 03:15 > > The Andes FPU coprocessor does not support denormalized number handling. > According to the specification, FPU generates a denorm input exception > that requires the kernel to deal with this instrution operation when it > encounters

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread David Laight
From: David Laight > Sent: 23 November 2018 09:35 > From: Linus Torvalds > > Sent: 22 November 2018 18:58 > ... > > Oh, and I just noticed that on x86 we expressly use our old "safe and > > sane" functions: see __inline_memcpy(), and its use in > > __

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread David Laight
From: Linus Torvalds > Sent: 22 November 2018 18:58 ... > Oh, and I just noticed that on x86 we expressly use our old "safe and > sane" functions: see __inline_memcpy(), and its use in > __memcpy_{from,to}io(). > > So the "falls back to memcpy" was always a red herring. We don't > actually do

RE: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread David Laight
From: Denys Vlasenko > Sent: 21 November 2018 13:44 ... > I also tested this while working for string ops code in musl. > > I think at least 128 bytes would be the minimum where "REP insn" > are more efficient. In my testing, it's more like 256 bytes... What happens for misaligned copies? I had

RE: [PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread David Laight
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 21 November 2018 14:42 > To: David Laight > Cc: mi...@elte.hu; t...@linutronix.de; Boris Ostrovsky; Juergen Gross; > linux-kernel@vger.kernel.org; > h...@zytor.com > Subject: RE: [

RE: [PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread David Laight
From: Jan Beulich > Sent: 21 November 2018 13:03 > > >>> On 21.11.18 at 12:55, wrote: > > From: Jan Beulich > >> Sent: 21 November 2018 10:11 > >> > >> Add missing insn suffixes and use rmwcc.h just like was (more or less) > >> recently done for bitops.h as well. > > > > Why? bts (etc) on memory

RE: [PATCH v2] x86: modernize sync_bitops.h

2018-11-21 Thread David Laight
From: Jan Beulich > Sent: 21 November 2018 10:11 > > Add missing insn suffixes and use rmwcc.h just like was (more or less) > recently done for bitops.h as well. Why? bts (etc) on memory don't really have an 'operand size'. IIRC the suffix determines the width of the %cx register that selects

RE: [PATCH] proc: allow killing processes via file descriptors

2018-11-19 Thread David Laight
From: > Christian Brauner > Sent: 18 November 2018 11:18 > > With this patch an open() call on /proc/ will give userspace a handle > to struct pid of the process associated with /proc/. This allows to > maintain a stable handle on a process. My 3c... You need to add a version of fork() that

RE: [PATCH] arm64: Explicitly mark 64-bit constant as unsigned long

2018-11-19 Thread David Laight
From: Olof Johansson > Sent: 17 November 2018 01:55 ... > -#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0x > +#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0xul > #error "Inconsistent SCTLR_EL2 set/clear bits" > #endif Wouldn't this be clearer if written: #if

RE: [PATCH] mm/usercopy: Use memory range to be accessed for wraparound check

2018-11-14 Thread David Laight
From: William Kucharski > Sent: 14 November 2018 10:35 > > > On Nov 13, 2018, at 5:51 PM, Isaac J. Manjarres > > wrote: > > > > diff --git a/mm/usercopy.c b/mm/usercopy.c > > index 852eb4e..0293645 100644 > > --- a/mm/usercopy.c > > +++ b/mm/usercopy.c > > @@ -151,7 +151,7 @@ static inline void

RE: [RFC PATCH v2 1/2] x86/fpu: detect AVX task

2018-11-13 Thread David Laight
From: Li, Aubrey > Sent: 13 November 2018 13:07 ... > > Isn't there an obvious optimisation to execute VZEROALL during system call > > entry? > > I'm not aware of this in the kernel, maybe you are talking about some > optimization in glibc? I've not seen it anywhere either. IIRC all the xmm and

RE: [RFC PATCH v2 1/2] x86/fpu: detect AVX task

2018-11-13 Thread David Laight
From: Li, Aubrey > Sent: 12 November 2018 01:41 ... > VZEROUPPER instruction resets the init state. If context switch happens > to occur exactly after VZEROUPPER instruction, XINUSE bitmap is empty(all > zeros), which indicates the task is not using AVX. That's why the state > decay count is used

RE: [PATCH] slab.h: Avoid using & for logical and of booleans

2018-11-12 Thread David Laight
From: Vlastimil Babka [mailto:vba...@suse.cz] > Sent: 09 November 2018 19:16 ... > This? Not terribly elegant, but I don't see a nicer way right now... Maybe just have two copies of the function body? static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags) { #ifndef

RE: [PATCH v2] x86/cpu: fix prototype warning

2018-11-09 Thread David Laight
From: Thomas Gleixner > Sent: 08 November 2018 15:36 > On Thu, 8 Nov 2018, Borislav Petkov wrote: > > And frankly, I don't see why we should be fixing all those. So what if a > > global function does't have a previous prototype declaration?! > > Global function declarations must have a prototype

RE: [PATCH v6 1/3] printk: Add line-buffered printk() API.

2018-11-07 Thread David Laight
From: Tetsuo Handa > Sent: 07 November 2018 10:53 > > On 2018/11/06 23:35, Sergey Senozhatsky wrote: > >> Since we want to remove "struct cont" eventually, we will try to remove > >> both "implicit printk() users who are expecting KERN_CONT behavior" and > >> "explicit pr_cont()/printk(KERN_CONT)

RE: [PATCH] slab.h: Avoid using & for logical and of booleans

2018-11-07 Thread David Laight
From: Vlastimil Babka > Sent: 06 November 2018 12:51 > > On 11/6/18 12:07 PM, David Laight wrote: > > From: Vlastimil Babka [mailto:vba...@suse.cz] > >> Sent: 06 November 2018 10:22 > > ... > >>>> -return type_dma + (is_reclaimable & !

RE: [PATCH v16 18/22] platform/x86: Intel SGX driver

2018-11-07 Thread David Laight
From: Jarkko Sakkinen > Sent: 06 November 2018 13:46 > > Intel Software Guard eXtensions (SGX) is a set of CPU instructions that > can be used by applications to set aside private regions of code and > data. The code outside the enclave is disallowed to access the memory > inside the enclave by

RE: [PATCH] slab.h: Avoid using & for logical and of booleans

2018-11-06 Thread David Laight
From: Vlastimil Babka [mailto:vba...@suse.cz] > Sent: 06 November 2018 10:22 ... > >> - return type_dma + (is_reclaimable & !is_dma) * KMALLOC_RECLAIM; > >> + return type_dma + is_reclaimable * !is_dma * KMALLOC_RECLAIM; > > > > ISTM that changing is_dma and is_reclaimable from int to bool will

RE: [PATCH] slab.h: Avoid using & for logical and of booleans

2018-11-06 Thread David Laight
From: Bart Van Assche > Sent: 05 November 2018 20:40 > > This patch suppresses the following sparse warning: > > ./include/linux/slab.h:332:43: warning: dubious: x & !y > > Fixes: 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable caches") > Cc: Vlastimil Babka > Cc: Mel Gorman > Cc:

RE: [RFC PATCH] Implement /proc/pid/kill

2018-11-01 Thread David Laight
From: Sent: 31 October 2018 13:28 ... > * I actually have a local variant of the patch that would have you > open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers > have different permission checks. I think you'd need the open() to specify some specific unusual open modes.

RE: [PATCH] pinctrl: generic: Avoid several implicit enum conversions

2018-11-01 Thread David Laight
From: Nathan Chancellor > Sent: 01 November 2018 00:04 ... > > A slightly lesser evil variant is to add a few PIN_CONFIG_CUSTOM_1 > > PIN_CONFIG_CUSTOM_2 etc at the end of the enum and just > > #define MY_CONFIG PIN_CONFIG_CUSTOM_1 > > in all drivers that use these. > > > > Some drivers actually

RE: [PATCH v3] Implement /proc/pid/kill

2018-11-01 Thread David Laight
From: Daniel Colascione > Sent: 31 October 2018 19:33 ... > You can't do it today with kill. The idea that keeping a open file > descriptor to a /proc/pid or a file within it prevents PID reuse is > widespread, but incorrect. Is there a real good reason why that shouldn't be the case? ie Holding

RE: [RFC PATCH] Minimal non-child process exit notification support

2018-10-31 Thread David Laight
From: Daniel Colascione > Sent: 31 October 2018 12:56 > On Wed, Oct 31, 2018 at 12:27 PM, David Laight > wrote: > > From: Daniel Colascione > >> Sent: 29 October 2018 17:53 > >> > >> This patch adds a new file under /proc/pid, /proc/pid/exithand. >

RE: [RFC PATCH] Minimal non-child process exit notification support

2018-10-31 Thread David Laight
From: Daniel Colascione > Sent: 29 October 2018 17:53 > > This patch adds a new file under /proc/pid, /proc/pid/exithand. > Attempting to read from an exithand file will block until the > corresponding process exits, at which point the read will successfully > complete with EOF. The file

RE: [PATCH] RDMA/cxgb3: Fix unintended sign extension

2018-10-25 Thread David Laight
From: Colin King > Sent: 25 October 2018 15:32 > > From: Colin Ian King > > In the expression "utx_len << 28", utx_len starts as u8, but is promoted > to a signed int, then sign-extended to u64. If utx_len is 0xf8 or greater > then the sign extension will set all the upper bits of utx_cmd

RE: [tip:irq/core] genirq: Fix race on spurious interrupt detection

2018-10-19 Thread David Laight
From: Lukas Wunner > Sent: 19 October 2018 16:34 > > genirq: Fix race on spurious interrupt detection > > Commit 1e77d0a1ed74 ("genirq: Sanitize spurious interrupt detection of > threaded irqs") made detection of spurious interrupts work for threaded > handlers by: > > a) incrementing a counter

RE: [PATCH 1/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS

2018-10-19 Thread David Laight
From: Masahiro Yamada > Sent: 18 October 2018 17:39 > > On Thu, Oct 18, 2018 at 6:18 PM Borislav Petkov wrote: > > > > On Wed, Oct 17, 2018 at 09:40:53PM -0300, Leonardo Bras wrote: > > > The idea was to put it as default and fix all the shadowing warnings. > > > What do you think? I am open to

RE: [PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

2018-10-18 Thread David Laight
From: Dan Carpenter > Sent: 18 October 2018 07:33 > > On Thu, Oct 18, 2018 at 05:09:32AM +, k...@linuxonhyperv.com wrote: > > From: Dexuan Cui > > > > The patch fixes: > > > > hv_kvp_daemon.c: In function 'kvp_set_ip_info': > > hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and

RE: [mm PATCH v3 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

2018-10-17 Thread David Laight
From: Pavel Tatashin > Sent: 17 October 2018 16:12 > On 10/17/18 11:07 AM, Alexander Duyck wrote: > > On 10/17/2018 1:47 AM, Michal Hocko wrote: > >> On Mon 15-10-18 13:26:56, Alexander Duyck wrote: > >>> This change makes it so that we use the same approach that was > >>> already in > >>> use on

RE: [PATCH 1/3] x86/mm/pat: Disable preemption around __flush_tlb_all()

2018-10-17 Thread David Laight
From: 'Sebastian Andrzej Siewior' > Sent: 17 October 2018 11:39 > On 2018-10-17 09:54:38 [+0000], David Laight wrote: > > Can it make any sense to flush the tlb with preemption enabled? > it might. Usually it is disabled for other reasons. That's what I mean, it should be disable

RE: [PATCH] fs: ufs: Remove switch statement from ufs_set_de_type function

2018-10-17 Thread David Laight
From: Phillip Potter > Sent: 17 October 2018 11:08 > > Remove switch statement from ufs_set_de_type function in fs/ufs/util.h > header and replace with simple assignment. For each case, S_IFx >> 12 > is equal to DT_x, so in valid cases (mode & S_IFMT) >> 12 should give > us the correct file type.

RE: [PATCH 1/3] x86/mm/pat: Disable preemption around __flush_tlb_all()

2018-10-17 Thread David Laight
From: Sebastian Andrzej Siewior > Sent: 16 October 2018 21:25 > I've seen the WARN_ON_ONCE(__read_cr3() != build_cr3()) in > switch_mm_irqs_off() every once in a while during a snapshotted system > upgrade. > I also saw the warning early during which was introduced in commit > decab0888e6e

RE: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-16 Thread David Laight
From: Nick Desaulniers > Sent: 15 October 2018 22:54 > On Mon, Oct 15, 2018 at 2:26 AM David Laight wrote: > > > > From: ndesaulni...@google.com > > > Sent: 11 October 2018 21:31 > > ... > > > by swapping h2 and h3. > > > > > >

RE: [PATCH] x86/entry/32: Fix setup of CS high bits

2018-10-15 Thread David Laight
From: Jan Kiszka > On 15.10.18 15:14, David Laight wrote: > > From: Jan Kiszka > >> Sent: 15 October 2018 14:09 > > ... > >>> Those fields are genuinely 16 bit. So the comment should say > >>> something like "Those high bits are us

RE: [PATCH] x86/entry/32: Fix setup of CS high bits

2018-10-15 Thread David Laight
From: Jan Kiszka > Sent: 15 October 2018 14:09 ... > > Those fields are genuinely 16 bit. So the comment should say > > something like "Those high bits are used for CS_FROM_ENTRY_STACK and > > CS_FROM_USER_CR3". > > /* > * The high bits of the CS dword (__csh) are used for > *

RE: [PATCH] KEYS: trusted: fix -Wvarags warning

2018-10-15 Thread David Laight
From: ndesaulni...@google.com > Sent: 11 October 2018 21:31 ... > by swapping h2 and h3. > > security/keys/trusted.c:146:17: warning: passing an object that > undergoes default > argument promotion to 'va_start' has undefined behavior [-Wvarargs] > va_start(argp, h3); >

RE: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function"

2018-10-09 Thread David Laight
From: Masami Hiramatsu > Sent: 09 October 2018 04:44 ... > I think we can replace the first 5 bytes of the default function > to jmp instruction (to alternative function) instead of making > this trampoline. Or have a trampoline that is just a jump instruction and overwrite the target address at

RE: [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk

2018-10-08 Thread David Laight
From: Bin Meng > Sent: 08 October 2018 10:44 ... > Correct, disable the shared interrupt line keeps all devices using > that line from working, which is current kernel's behavior w/o this > quirk handling: it disables the (shared) interrupt line after 100.000+ > generated interrupts. But the side

RE: [PATCH] usbnet: smsc95xx: simplify tx_fixup code

2018-10-03 Thread David Laight
From: Ben Dooks > Sent: 02 October 2018 17:56 > > The smsc95xx_tx_fixup is doing multiple calls to skb_push() to > put an 8-byte command header onto the packet. It would be easier > to do one skb_push() and then copy the data in once the push is > done. > > Signed-off-by: Ben Dooks > --- >

RE: [PATCH 0/3] namei: implement various scoping AT_* flags

2018-10-03 Thread David Laight
From: Aleksa Sarai > Sent: 01 October 2018 17:16 > > On 2018-10-01, David Laight wrote: ... > > > * Mountpoint crossings are blocked by AT_XDEV. > > > > You might want a mountpoint flag that allows crossing into the mounted > > filesystem (you ma

RE: [PATCH 0/3] namei: implement various scoping AT_* flags

2018-10-01 Thread David Laight
From: Aleksa Sarai > Sent: 29 September 2018 11:35 > > The need for some sort of control over VFS's path resolution (to avoid > malicious paths resulting in inadvertent breakouts) has been a very > long-standing desire of many userspace applications. This patchset is a > revival of Al Viro's old

RE: [RFC][PATCH 3/3] locking/qspinlock: Optimize for x86

2018-09-27 Thread David Laight
From: Peter Zijlstra > Sent: 26 September 2018 12:01 > > On x86 we cannot do fetch_or with a single instruction and end up > using a cmpxchg loop, this reduces determinism. Replace the fetch_or > with a very tricky composite xchg8 + load. > > The basic idea is that we use xchg8 to test-and-set

RE: [PATCH] tty/sysrq: Make local variable 'killer' in sysrq_handle_crash() global

2018-09-18 Thread David Laight
From: Matthias Kaehlcke > Sent: 17 September 2018 22:33 > > sysrq_handle_crash() dereferences a NULL pointer on purpose to force > an exception, the local variable 'killer' is assigned to NULL and > dereferenced later. Clang detects the NULL pointer dereference at compile > time and emits a BRK

RE: [PATCH v2 04/17] ceph: fix compat_ioctl for ceph_dir_operations

2018-09-12 Thread David Laight
From: Arnd Bergmann > Sent: 12 September 2018 16:01 > > The ceph_ioctl function is used both for files and directories, but only > the files support doing that in 32-bit compat mode. > > For consistency, add the same compat handler to the dir operations > as well. Have you verified that all the

RE: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault

2018-09-10 Thread David Laight
From: Linus Torvalds > ... > You could literally do something like > > /* Make it canonical in case we flipped the high bit */ > addr = (long)(addr<<1)>>1; Isn't it safer to use a mask and let the compiler decide if two shifts are a good implementation? addr &= ~HIGH_MAGIC_BIT;

RE: [PATCH] perf event-parse: Use fixed size string for comms

2018-08-30 Thread David Laight
From: cphlip...@gmail.com > Sent: 30 August 2018 03:20 > > Some implementations of libc do not support the 'm' width modifier > as part of the scanf string format specifier. This can cause the > parsing to fail. Since the parser never checks if the scanf > parsing was successesful, this can

RE: Linux 4.19-rc1

2018-08-29 Thread David Laight
From: Linus Torvalds > Sent: 26 August 2018 22:49 > > So two weeks have passed, and the merge window for 4.19 is over. > > This was a fairly frustrating merge window, partly because 4.19 looks > to be a pretty big release (no single reason), and partly just due to > random noise. ... Time for

RE: [PATCH 06/13] proc: convert /proc/self to _print_integer()

2018-08-29 Thread David Laight
From: Alexey Dobriyan > Sent: 28 August 2018 00:15 > --- > fs/proc/self.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/fs/proc/self.c b/fs/proc/self.c > index 127265e5c55f..b2279412237b 100644 > --- a/fs/proc/self.c > +++ b/fs/proc/self.c > @@ -14,6 +14,7 @@

RE: [PATCH v1 2/7] extcon: Switch to use kasprintf() instead of open coded

2018-08-29 Thread David Laight
From: Andy Shevchenko > Sent: 27 August 2018 16:36 > > Switch to use kasprintf() instead of open coded variant. > No functional change intended. > > Signed-off-by: Andy Shevchenko > --- > drivers/extcon/extcon.c | 13 +++-- > 1 file changed, 3 insertions(+), 10 deletions(-) > > diff

RE: [PATCH] fs: fix local var type

2018-08-23 Thread David Laight
From: Michal Hocko > Sent: 23 August 2018 12:14 > > On Thu 23-08-18 01:59:14, Weikang Shi wrote: > > In the seq_hex_dump function,the remaining variable is int, but it receive > > a type of size_t > argument. > > So I change the type of remaining > > The changelog should explain _why_ we need

RE: [PATCH 3/4] memory: jz4780-nemc: Reduce size of const array

2018-08-23 Thread David Laight
From: Paul Cercueil > Sent: 22 August 2018 18:30 > The maximum value found in that array is 15, there's no need to store > these values as uint32_t, a uint8_t is enough. > > Signed-off-by: Paul Cercueil > --- > drivers/memory/jz4780-nemc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3

RE: [PATCH] mtd: m25p80: consider max message size when use the spi_mem_xx() API

2018-08-20 Thread David Laight
From: Chuanhua Han > Sent: 20 August 2018 13:44 > > Signed-off-by: Chuanhua Han > --- > Changes in v3: > Rename variable name "val" to "opcode_addr_dummy_sum". > Place the legitimacy of the transfer size(i.e., > "pi_max_message_size(mem->spi)" and > "opcode_addr_dummy_sum") into "if (!

RE: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

2018-08-16 Thread David Laight
From: James Bottomley > Sent: 16 August 2018 16:57 > On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote: > > James Bottomley wrote: > > > > > > The problem with that is that it means you can't load third party > > > > modules - such as the NVidia driver.  That's fine if you > > > > absolutely

RE: [GIT PULL] gcc-plugin updates for v4.19-rc1

2018-08-16 Thread David Laight
From: Linus Torvalds > Sent: 15 August 2018 21:19 ... > But if people run things on real machines, then BUG() is absolutely > the last thing you EVER want to do for "debugging". I'm not sure you want it on a live system either. Live systems are where the 'hard' bugs show up. I've just spent a

RE: Build failures with gcc 4.5 and older

2018-08-16 Thread David Laight
From: Linus Torvalds > Sent: 15 August 2018 17:34 > To: David Laight > Cc: Guenter Roeck; Linux Kernel Mailing List; Rik van Riel; Mike Galbraith; > Dave Hansen; Andrew Morton > Subject: Re: Build failures with gcc 4.5 and older > > On Wed, Aug 15, 2018 at 9:16 A

RE: Build failures with gcc 4.5 and older

2018-08-15 Thread David Laight
From: Linus Torvalds > Sent: 15 August 2018 16:44 > On Wed, Aug 15, 2018 at 5:38 AM David Laight wrote: > > > > Never mind the version of gcc, the x86 kernel doesn't build with the > > default kernel options because the ORC unwinder hits a bug in libelf > > (in obj

RE: Build failures with gcc 4.5 and older

2018-08-15 Thread David Laight
From: Guenter Roeck > Sent: 14 August 2018 18:09 ... > Does that mean that gcc 4.5 and older are now officially no longer > supported for compiling the kernel ? Never mind the version of gcc, the x86 kernel doesn't build with the default kernel options because the ORC unwinder hits a bug in

RE: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

2018-08-14 Thread David Laight
From: Arnd Bergmann > Sent: 14 August 2018 12:08 ... > > There are also a whole load of crappy __packed in that header file. > > There might be one or two 64bit items on 32bit boundaries but > > that can be solved without using __packed. > > Agreed, this likely causes problems on architectures

RE: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning

2018-08-14 Thread David Laight
From: Johannes Berg > Sent: 14 August 2018 08:57 ... > > How about fixing the root cause > > in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ? > > > > > > #define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK 0x1eULL > > > > > > enum iwl_rx_he_phy looks really strange. > > Why? I don't

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-08 Thread David Laight
From: Arnd Bergmann > Sent: 08 August 2018 17:31 .. > > They do modify the same byte, but with the same value. Suppose that you > > want to copy a piece of data that is between 8 and 16 bytes long. You can > > do this: > > > > add src_end, src, len > > add dst_end, dst, len > > ldr x0, [src] > >

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-08 Thread David Laight
From: Mikulas Patocka > Sent: 08 August 2018 14:47 ... > The problem on ARM is that I see data corruption when the overlapping > unaligned writes are done just by a single core. Is this a sequence of unaligned writes (that shouldn't modify the same physical locations) or an aligned write followed

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-08 Thread David Laight
From: Catalin Marinas > Sent: 08 August 2018 13:17 ... > I think hazarding is what goes wrong here, especially since with > overlapping unaligned addresses. However, I disagree that it is > impossible to implement this properly on a platform with PCIe so that > Normal NC mappings can be used.

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-07 Thread David Laight
From: Mikulas Patocka > Sent: 07 August 2018 15:07 ... > Unaccelerated scrolling is still painfully slow > even on modern computers because of slow framebuffer read. I solved that many years ago on a strongarm system by mapping the screen memory at two separate virtual addresses. One uncached

RE: [PATCH] platform/x86: acer-wmi: use true and false for boolean values

2018-08-06 Thread David Laight
From: Andy Shevchenko > Sent: 05 August 2018 11:26 > > On Sun, Aug 5, 2018 at 3:18 AM, Gustavo A. R. Silva > wrote: > > Return statements in functions returning bool should use true or false > > instead of an integer value. > > > > This code was detected with the help of Coccinelle. > > >

RE: [PATCH] x86/irqflags: provide a declaration for native_save_fl

2018-08-06 Thread David Laight
> Indeed, it seems that: > extern inline unsigned long native_save_fl(void) { return 0; } > > compiled with -Werror=missing-prototypes produces this warning in gcc < > 4.9, but not gcc >= 4.9. > > Cc: sta...@vger.kernel.org # 4.17, 4.14, 4.9, 4.4 > Reported-by:

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-06 Thread David Laight
From: Mikulas Patocka > Sent: 05 August 2018 15:36 > To: David Laight ... > There's an instruction movntdqa (and vmovntdqa) that can actually do > prefetch on write-combining memory type. It's the only instruction that > can do it. > > It this instruction is used on non-w

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread David Laight
From: Mikulas Patocka > Sent: 03 August 2018 13:05 ... > > Even on x86 using memcpy() on PCIe memory (maybe mmap()ed into userspace) > > isn't a good idea. > > In the kernel memcpy_to/fromio() ought to be a better choice but that > > is just an alternate name for memcpy(). > > > > The problem on

RE: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread David Laight
From: Ard Biesheuvel > Sent: 03 August 2018 10:30 ... > The discussion about whether memcpy() should rely on unaligned > accesses, and whether you should use it on device memory is orthogonal > to that, and not the heart of the matter IMO Even on x86 using memcpy() on PCIe memory (maybe mmap()ed

RE: AW: PROBLEM: Kernel Oops in UDP stack

2018-08-02 Thread David Laight
From: Marcel Hellwig > Sent: 01 August 2018 11:36 > >> [] (udp_recvmsg+0x284/0x33c) from [] > >> (inet_recvmsg+0x38/0x4c): > net/ipv4/udp.c:1234 > > > > sin->sin_addr.s_addr = ip_hdr(skb)->saddr; > > > >Unaligned access trap (virtual address c14fe63a), so either sin or >

RE: [RFC PATCH] checkpatch: check for function calls with struct or union on stack

2018-07-27 Thread David Laight
From: Joe Perches > Sent: 27 July 2018 11:09 > On Fri, 2018-07-27 at 10:04 +, David Laight wrote: > > From: Andrew Morton > > > Sent: 26 July 2018 20:28 > > > On Thu, 26 Jul 2018 12:25:33 -0700 Andrew Morton > > > wrote: > >

RE: [RFC PATCH] checkpatch: check for function calls with struct or union on stack

2018-07-27 Thread David Laight
From: Andrew Morton > Sent: 26 July 2018 20:28 > On Thu, 26 Jul 2018 12:25:33 -0700 Andrew Morton > wrote: > > > I'll give it a spin, see how noisy it is. > > Actually, I would prefer if the message, changelog and title > used the term "passed by value". It's a more familiar term > and it is

[PATCH v2] scripts: Detect invalid .o files created by objtool.

2018-07-26 Thread David Laight
. Signed-off-by: David Laight --- v2: Add missing $ escaping $$obj_headers scripts/Makefile.build | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index e7889f4..200b02c 100644 --- a/scripts/Makefile.build +++ b

RE: [RFC PATCH] sched/debug: Use terse backtrace for idly sleeping threads.

2018-07-20 Thread David Laight
From: Tetsuo Handa > Sent: 20 July 2018 14:27 > > On 2018/07/19 22:46, Peter Zijlstra wrote: > > On Thu, Jul 19, 2018 at 10:37:23PM +0900, Tetsuo Handa wrote: > >> This patch can be applied before proposing abovementioned changes. > >> Since there are many kernel threads whose backtrace is boring

[PATCH] Detect invalid .o files created by objtool.

2018-07-20 Thread David Laight
unwinder. Signed-off-by: David Laight --- scripts/Makefile.build | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index e7889f4..200b02c 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -193,7 +193,9

RE: [PATCH] mm: Cleanup in do_shrink_slab()

2018-07-19 Thread David Laight
From: Kirill Tkhai > Sent: 19 July 2018 17:05 > > Group long variables together to minimize number of occupied lines > and place all definitions in back Christmas tree order. Grouping together unrelated variables doesn't really make the code any more readable. IMHO One variable per line is

Enabling the ORC unwinder generates invalid .o files.

2018-07-18 Thread David Laight
As was discovered last september (https://lkml.org/lkml/2017/9/14/561) running objtool to generate the orc unwind data will generate invalid object files on an systems where libelf.so hasn't been patched. I've just spent a day debugging the same issue - as far as the corrupted section headers -

RE: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3

2018-07-11 Thread David Laight
From: Peter Zijlstra > Sent: 11 July 2018 12:10 .. > Adding SYNC to WRITE_ONCE()/atomic* will hurt performance lots and will > ultimately not guarantee anything more; and as Will said, keep you > chasing dragons where people forgot to use WRITE_ONCE() where they maybe > should've. Also

RE: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3

2018-07-11 Thread David Laight
From: Paul Burton > Sent: 10 July 2018 18:11 ... > I'm not sure which is the intent (I can ask if someone's interested), > but you could either: > > 1) Consider the store buffer a cache, in which case loads need to > check all store buffers from all CPUs because of the "all caches" >

RE: [PATCH] x86: Avoid pr_cont() in show_opcodes()

2018-07-10 Thread David Laight
From: Josh Poimboeuf > Sent: 09 July 2018 20:12 > On Mon, Jul 09, 2018 at 10:49:53AM +0200, Peter Zijlstra wrote: > > On Sat, Jul 07, 2018 at 10:54:28PM +0900, Tetsuo Handa wrote: > > > >> Since syzbot is confused by concurrent printk() messages [1], > > > >> this patch changes show_opcodes() to

RE: [PATCH] x86: Avoid pr_cont() in show_opcodes()

2018-07-09 Thread David Laight
From: Peter Zijlstra > Sent: 09 July 2018 09:50 > On Sat, Jul 07, 2018 at 10:54:28PM +0900, Tetsuo Handa wrote: > > >> Since syzbot is confused by concurrent printk() messages [1], > > >> this patch changes show_opcodes() to use snprintf(). snprintf() is probably the wrong function. You want the

RE: [PATCH v2] leds: ledtrig-morse: send out morse code

2018-07-05 Thread David Laight
... > > Well, just like we have LED and LED triggers in the kernel, I think having > > a generic way to use patterns could be nice and in this case Morse could be > > one such pattern, but if that means it's limited to userland to configure > > it then it sadly voids all of its benefits. I've

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

2018-07-03 Thread David Laight
From: Denys Vlasenko > Sent: 03 July 2018 12:59 > > On 07/03/2018 10:46 AM, David Laight wrote: > > From: Jan Beulich > >> Sent: 03 July 2018 09:36 > > ... > >> As said there, omitting suffixes from instructions in AT mode is bad > >>

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

2018-07-03 Thread David Laight
From: Jan Beulich > Sent: 03 July 2018 11:07 > >>> On 03.07.18 at 10:46, wrote: > > From: Jan Beulich > >> Sent: 03 July 2018 09:36 > > ... > >> As said there, omitting suffixes from instructions in AT mode is bad > >> practice when operand size cannot be determined by the assembler from > >>

RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes

2018-07-03 Thread David Laight
From: Jan Beulich > Sent: 03 July 2018 09:36 ... > As said there, omitting suffixes from instructions in AT mode is bad > practice when operand size cannot be determined by the assembler from > register operands, and is likely going to be warned about by upstream > gas in the future (mine does

RE: [PATCH] lib/string.c: fix a typo in comment: 'iff' -->'if'

2018-06-29 Thread David Laight
From: YueHaibing > Sent: 29 June 2018 04:45 > > On 2018/6/29 11:35, Randy Dunlap wrote: > > On 06/28/2018 08:33 PM, YueHaibing wrote: > >> Signed-off-by: YueHaibing > >> --- > >> lib/string.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Hi, > > > > This isn't a typo.

RE: [RFC PATCH 1/8] x86/cpufeatures: Enumerate MOVDIRI instruction

2018-06-25 Thread David Laight
From: Fenghua Yu > Sent: 19 June 2018 22:37 > To: Thomas Gleixner > Cc: Fenghua Yu; Ingo Molnar; H Peter Anvin; Ashok Raj; Alan Cox; Ravi V > Shankar; linux-kernel; x86 > Subject: Re: [RFC PATCH 1/8] x86/cpufeatures: Enumerate MOVDIRI instruction > > On Tue, Jun 19, 2018 at 10:57:44AM +0200,

RE: [PATCH v2] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask()

2018-06-25 Thread David Laight
From: Matthias Kaehlcke > Sent: 19 June 2018 20:25 > To: Paolo Bonzini; Radim Krčmář; Thomas Gleixner; H . Peter Anvin > Cc: x...@kernel.org; k...@vger.kernel.org; linux-kernel@vger.kernel.org; Nick > Desaulniers; Joe Perches; > Matthias Kaehlcke > Subject: [PATCH v2] kvm: x86: mmu: Add cast to

  1   2   3   4   5   6   7   8   9   >