RE: [PATCH 01/10] PCI: dwc: use DMA-API for allocating MSI data

From: Behalf Of Niklas Cassel > Sent: 13 October 2017 17:09 > Since it is a PCIe endpoint device, rather than the CPU, that is supposed > to write to this location, the proper way to get the address to this this > location is really to use the DMA API, rather than virt_to_phys. > > Using

RE: [PATCH net-next 5/5] net: dsa: split dsa_port's netdev member

From: Florian Fainelli > Sent: 13 October 2017 00:05 ... > How about using: > > union { > struct net_device *master; > struct net_device *slave; > } netdev; ... You can remove the 'netdev' all the compilers support unnamed unions. David

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

From: Vivien Didelot > Sent: 13 October 2017 02:41 > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > a random MAC address, and remove the .set_addr implementation. > > Signed-off-by: Vivien Didelot > --- >

RE: [PATCH v2] xdp: Sample xdp program implementing ip forward

From: Jesper Dangaard Brouer > Sent: 10 October 2017 20:06 ... > > + int src_ip = 0, dest_ip = 0; ... > > + key4.b8[4] = dest_ip % 0x100; > > + key4.b8[5] = (dest_ip >> 8) % 0x100; > > + key4.b8[6] = (dest_ip >> 16) % 0x100; > > +

RE: [PATCH] xhci: Cope with VIA VL805 readahead

From: Robin Murphy > Sent: 10 October 2017 19:09 > > The VIA VL805 host controller is well-known for causing problems on > systems with IOMMUs enabled, ranging from triggering endless streams of > fault messages to locking itself up completely. It appears that the root > of the problem might be

RE: [PATCH 3/7] PCI: Distribute available buses to hotplug capable PCIe downstream ports

From: Bjorn Helgaas > Sent: 12 October 2017 00:33 > Why do you limit it to PCIe? Isn't it conceivable that one could > hot-add a conventional PCI card that contained a bridge leading to > another hotplug slot? E.g., a PCI card with PCMCIA slot or something > on it? There are (maybe were!)

RE: [PATCH] PCI: dwc: designware: don't sleep in atomic context

From: Pankaj Dubey > Sent: 12 October 2017 08:55 > In pcie-designware.c many places we are calling "usleep_range" which > are in atomic context. This patch fixes these potential BUGs and > replaces "usleep_range" with mdelay calls. > > Signed-off-by: Pankaj Dubey > ---

RE: [PATCH net-next v2 02/10] net: dsa: debugfs: add tree

From: Vivien Didelot > Sent: 08 September 2017 15:57 ... > > > Also more important, you will notice what seems to be a bug to me: > > > I can read or write a file even if I didn't mask the corresponding mode > > > hence the double check in dsa_debugfs_show and dsa_debugfs_write. > > > > The mode

RE: [PATCH v5] usb: serial: add vid:pid for Cypress WICED dev board

> To: Jeffrey Chu .. > Patch is still corrupted :( > > Please try sending it to yourself first to verify you have your email > client set up correctly. If you are forced to send from outlook, try copy & paste from wordpad. David

RE: [PATCH] tipc: Use bsearch library function

From: David Miller > Sent: 11 September 2017 22:30 > From: Thomas Meyer > Date: Sat, 9 Sep 2017 05:18:19 +0200 > > > @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, > > struct hlist_head > *seq_hea > > return nseq; > > } > > > > +static int

RE: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN

From: Arnd Bergmann > Sent: 22 September 2017 22:29 ... > It seems that this is triggered in part by using strlcpy(), which the > compiler doesn't recognize as copying at most 'len' bytes, since strlcpy > is not part of the C standard. Neither is strncpy(). It'll almost certainly be a marker in

RE: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

From: Segher Boessenkool > Sent: 25 September 2017 08:37 > On Sun, Sep 24, 2017 at 12:17:51PM -0700, Kees Cook wrote: > > On Thu, Sep 21, 2017 at 2:37 AM, Christophe Leroy > > wrote: > > > On powerpc, RODATA_TEST fails with message the following messages: > > > > > > [

RE: [PATCH v2 02/16] thunderbolt: Add support for XDomain properties

From: Mika Westerberg > Sent: 27 September 2017 12:33 ... > Just for my education, is there some rule which tells when __packed is > to be used? For example the above structures are all 32-bit aligned but > how about something like: > > struct foo { > u32 value1; > u8 value2; > }; >

RE: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

From: Andrew Lunn > Sent: 27 September 2017 14:07 > To: David Laight > On Wed, Sep 27, 2017 at 09:06:01AM +0000, David Laight wrote: > > From: Vivien Didelot > > > Sent: 26 September 2017 19:57 > > > mv88e6xxx_g2_irq_free locks the registers mutex, but not &

RE: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Matt Redfearn > Sent: 26 September 2017 14:58 ... > > As long as you use the dma_{map,unamp}_single() and sync to/from > > deivce interfaces properly, the cacheline issues will be handled properly > > and the cpu and the device will see proper uptodate memory contents. > > I interpret the

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

From: Andrew Lunn > Sent: 28 September 2017 20:34 ... > > There are 34 counters. In normal case using generic bus I/O or PCI to read > > them > > is very quick, but the switch is mostly accessed using SPI, or even I2C. > > As the SPI > > access is very slow. > > How slow is it? The Marvell

RE: [PATCH net v2] net: dsa: mv88e6xxx: lock mutex when freeing IRQs

From: Vivien Didelot > Sent: 26 September 2017 19:57 > mv88e6xxx_g2_irq_free locks the registers mutex, but not > mv88e6xxx_g1_irq_free, which results in a stack trace from > assert_reg_lock when unloading the mv88e6xxx module. Fix this. > > Fixes: 3460a5770ce9 ("net: dsa: mv88e6xxx: Mask g1

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

From: Christoph Hellwig > Sent: 03 October 2017 11:43 > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > make any sense to do any work in dma_cache_sync given that it must be a > no-op when dma_alloc_attrs returns coherent memory. I believe it is just about possible to

RE: [PATCH net] ethernet: xircom: small clean up in setup_xirc2ps_cs()

From: Dan Carpenter > Sent: 21 August 2017 10:48 > The get_options() function takes the whole ARRAY_SIZE(). It doesn't > matter here because we don't use more than 7 elements. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c

RE: [PATCH v2 0/2] enable hires timer to timeout datagram socket

From: Vallish Vaidyeshwara > Sent: 27 August 2017 21:47 ... > I respect the decision not to upstream this patch series, however I > wanted to provide additional details. Application wanting high > resolution events with real guarantees is not the case, but the case > here is regression in system

RE: [PATCH] rtl8xxxu: mark expected switch fall-throughs

From: Joe Perches > Sent: 11 October 2017 11:21 > On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > > where we are expecting to fall through. > > perhaps use Arnaldo's idea: > >

RE: [PATCH] xhci: Cope with VIA VL805 readahead

From: Mathias Nyman > Sent: 11 October 2017 15:41 .. > If possible I'd like to try and find some other solution before chopping the > Segment > size to smaller than 256. > I think that your first proposal of adding the guard page to the segment pool > could be an option. Would be a waste of a

RE: [PATCH v2] isdn/gigaset: Convert timers to use timer_setup()

From: Kees Cook > Sent: 06 October 2017 20:40 ... > I'm in no rush for any specific change. There are about 900 call sites > I'm making my way through, about 2/3rd are pretty trivial, and the > less obvious is what I've started sending out now, since I expect some > will need some more careful

RE: [PATCH v1 RFC 1/7] Replace license with GPL

From: tristram...@microchip.com > Sent: 06 October 2017 21:33 > Replace license with GPL. Don't you need permission from all the people who have updated the files in order to make this change? David

RE: [PATCH] PCI/AER: update AER status string print to match other AER logs

From: Tyler Baicar [mailto:tbai...@codeaurora.org] > Sent: 17 October 2017 18:14 > On 10/17/2017 12:00 PM, David Laight wrote: > > From: Tyler Baicar > >> Sent: 17 October 2017 16:42 > >> Currently the AER driver uses cper_print_bits() to print the AER status >

RE: [PATCH] PCI/AER: update AER status string print to match other AER logs

From: Tyler Baicar > Sent: 17 October 2017 16:42 > Currently the AER driver uses cper_print_bits() to print the AER status > string. This causes the status string to not include the proper PCI device > name prefix that the other AER prints include. Also, it has a different > print level than all

RE: Adjusting further size determinations?

From: SF Markus Elfring > Unpleasant consequences are possible in both cases. > >> How much do you care to reduce the failure probability further? > > > > Zero. > > I am interested to improve the software situation a bit more here. There are probably better places to spend your time! If

RE: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

From: Ard Biesheuvel > Sent: 18 October 2017 16:45 > Even though calling dql_completed() with a count that exceeds the > queued count is a serious error, it still does not justify bringing > down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() > instead. > > Signed-off-by: Ard

RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

From: Jim Quinlan > Sent: 20 October 2017 16:28 > On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig wrote: > > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote: > >> I am not sure I understand your comment -- the size of the request > >> shouldn't be a factor. Let's

RE: [PATCH] PCI: dwc: designware: don't sleep in atomic context

From: Bjorn Helgaas > Sent: 20 October 2017 19:19 > On Fri, Oct 13, 2017 at 09:10:38AM +0530, Pankaj Dubey wrote: > > > > > > On 10/12/2017 04:09 PM, David Laight wrote: > > >From: Pankaj Dubey > > >>Sent: 12 October 2017 08:55 > > >>In p

RE: [PATCH 0/5] add printk specifier %px, unique identifier

From: Eric W. Biederman > Sent: 28 November 2017 06:27 > Linus Torvalds writes: > > > On Mon, Nov 27, 2017 at 4:03 PM, Linus Torvalds > > wrote: > >> > >> So the big remaining ones for me are the /proc//stack (stack > >> pointers)

RE: [PATCH v3 3/3] PCI: endpoint: Fix find_first_zero_bit() usage

From: Niklas Cassel > Sent: 27 November 2017 15:50 > find_first_zero_bit()'s parameter 'size' is defined in bits, > not in bytes. > > Calling find_first_zero_bit() with the wrong size unit > will lead to insidious bugs. > > Fix this by calling find_first_zero_bit() with size > BITS_PER_LONG,

RE: [PATCH 0/5] add printk specifier %px, unique identifier

From: Linus Torvalds > Sent: 28 November 2017 17:33 > > On Mon, Nov 27, 2017 at 10:26 PM, Eric W. Biederman > wrote: > >> > >> Oh well, I just did /proc//stack by making it just print 0 > >> unconditionally rather than the hex number. > > > > Patch? > > Oh, apparently I

RE: [RFC v2] dma-coherent: introduce no-align to avoid allocation failure and save memory

From: Jaewon Kim > Sent: 24 November 2017 05:59 > > dma-coherent uses bitmap APIs which internally consider align based on the > requested size. If most of allocations are small size like KBs, using > alignment scheme seems to be good for anti-fragmentation. But if large > allocation are commonly

RE: [PATCH v3 14/19] x86/entry/64: Create a percpu SYSCALL entry trampoline

From: Andy Lutomirski > Sent: 24 November 2017 04:33 ... > + /* > + * x86 lacks a near absolute jump, and we can't jump to the real > + * entry text with a relative jump, so we fake it using retq. > + */ > + pushq $entry_SYSCALL_64_after_hwframe > + retq Don't some of

RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

From: Salvatore Mesoraca [mailto:s.mesorac...@gmail.com] > Sent: 24 November 2017 11:44 > > 2017-11-24 11:53 GMT+01:00 David Laight <david.lai...@aculab.com>: > > From: Alan Cox > >> Sent: 22 November 2017 16:52 > >> > >> On Wed, 22 Nov 2017 0

RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

From: Alan Cox > Sent: 22 November 2017 16:52 > > On Wed, 22 Nov 2017 09:01:46 +0100 > Salvatore Mesoraca wrote: > > > Disallows O_CREAT open missing the O_EXCL flag, in world or > > group writable directories, even if the file doesn't exist yet. > > With few exceptions

memcpy_to/fromio() is badly optimised on x86

I believe that it is valid to use memcpy_to/fromio() to copy data to/from memory BARs on PCIe cards. However on x86 they are both aliases for memcpy(). The x86 kernel has several implementations of memcpy(). The 'best' one for the current cpu is selected during boot. For more recent Intel cpus

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

From: Linus Torvalds > Sent: 29 November 2017 02:29 > > On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding wrote: > > > >Let's add specifier %px as a > > clear, opt-in, way to print a pointer and maintain some level of > > isolation from all the other hex integer output within

RE: [PATCH] trace/xdp: fix compile warning: ‘struct bpf_map’ declared inside parameter list

From: Xie XiuQi > Sent: 29 November 2017 08:35 > > We meet this compile warning, which caused by missing bpf.h in xdp.h. > > In file included from ./include/trace/events/xdp.h:10:0, > from ./include/linux/bpf_trace.h:6, > from

RE: [PATCH] x86/entry/64: Fix native_load_gs_index() SWAPGS handling with IRQ state tracing enabled

From: Andy Lutomirski > Sent: 29 November 2017 14:34 > > On Nov 29, 2017, at 4:47 AM, Peter Zijlstra wrote: > > > >> On Wed, Nov 29, 2017 at 08:09:51AM +0100, Ingo Molnar wrote: > >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > >> index

RE: [PATCH] x86/entry/64: Fix native_load_gs_index() SWAPGS handling with IRQ state tracing enabled

From: Andy Lutomirski > Sent: 29 November 2017 16:23 > > I can't remember what happens when swapgs itself faults. ... > SWAPGS never faults. Ah yes, I remember, it only restores the offset. For 32bit processes you need to do a 'pop %gs' to recover the segment register itself - and that can fault.

RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

From: Salvatore Mesoraca > Sent: 22 November 2017 08:02 > > Disallows O_CREAT open missing the O_EXCL flag, in world or > group writable directories, even if the file doesn't exist yet. > With few exceptions (e.g. shared lock files based on flock()) > if a program tries to open a file, in a

RE: [PATCH V11 0/5] hash addresses printed with %p

From: Andrew Morton > Sent: 29 November 2017 23:21 > > > > The added advantage of hashing %p is that security is now opt-out, if > > you _really_ want the address you have to work a little harder and use > > %px. You need a system-wide opt-out that prints the actual values. Otherwise developers

RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Wu Hao > Sent: 27 November 2017 06:42 > From: Zhang Yi > > The Intel FPGA device appears as a PCIe device on the system. This patch > implements the basic framework of the driver for Intel PCIe device which > is located between CPU and Accelerated Function Units

RE: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4

From: Steven Rostedt > Sent: 30 November 2017 02:59 > Subject: [BUILD FAILURE] nfs4state.c fails to compile with gcc 4.5.4 FWIW I can't build the current kernel with gcc 4.7.3-1ubuntu1 under ubuntu 13.04. The compiler generates some object files that binutils (objdump/ld) 2.23.2 says are

RE: [PATCH V11 4/5] vsprintf: add printk specifier %px

From: Kees Cook > Sent: 29 November 2017 22:28 > On Wed, Nov 29, 2017 at 2:07 AM, David Laight <david.lai...@aculab.com> wrote: > > From: Linus Torvalds > >> Sent: 29 November 2017 02:29 > >> > >> On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding <

RE: [PATCH v3 2/2] Protected O_CREAT open in sticky directories

From: Solar Designer > Sent: 30 November 2017 17:52 > > On Thu, Nov 30, 2017 at 04:53:06PM +0000, David Laight wrote: > > From: Salvatore Mesoraca > > > if a program tries to open a file, in a sticky directory, > > > with the O_CREAT flag and without

RE: [patch 11/16] x86/ldt: Force access bit for CS/SS

From: Andy Lutomirski > Sent: 12 December 2017 19:27 ... > > Why is the iret exception unrecoverable anyway? Does anybody even know? > > > > Weird microcode shit aside, a fault on IRET will return to kernel code with > kernel GS, and then the > next time we enter the kernel we're backwards. We

RE: [PATCH v2 0/2] mm: introduce MAP_FIXED_SAFE

From: Edward Napierala > Sent: 14 December 2017 14:55 > > On 1214T1415, Michal Hocko wrote: > > On Thu 14-12-17 12:44:17, Edward Napierala wrote: > > > Regarding the name - how about adopting MAP_EXCL? It was introduced in > > > FreeBSD, > > > and seems to do exactly this; quoting mmap(2): > > >

RE: [PATCH] crypto: x86/twofish-3way - Fix %rbp usage

From: Juergen Gross > Sent: 19 December 2017 08:05 .. > > Exchanging 2 registers can be done without memory access via: > > xor reg1, reg2 > xor reg2, reg1 > xor reg1, reg2 That'll generate horrid data dependencies. ISTR that there are some optimisations for the stack, so even 'push reg1', 'mov

RE: BUG: bad usercopy in memdup_user

From: Al Viro > Sent: 19 December 2017 21:49 > > I suspect that an "offset and size within the kernel object" value > > might make sense. But what does the _pointer_ tell you? > > Well, for example seeing a 0xfff4 where a pointer to object > must have been is a pretty strong hint to

kernel build generates invalid object files on Ubuntu 13.10

I've just updated a linux source tree to the latest version (probably from Linus's public tree) and then tried to compile it (for x86_64) using gcc 4.7.3 and binutils 2.32.2 on a system running Ubuntu 13.10. While not the newest gcc, it isn't that old. The linker is reporting that some of the

RE: [PATCH 3/7] net: core: eliminate dev_alloc_name{,_ns} code duplication

From: Rasmus Villemoes > Sent: 12 November 2017 23:15 > dev_alloc_name contained a BUG_ON(), which I moved to dev_alloc_name_ns; > the only other caller of that already has the same BUG_ON. > > Signed-off-by: Rasmus Villemoes > --- > net/core/dev.c | 12 ++-- >

RE: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG

From: Paul E. McKenney > Sent: 20 November 2017 20:54 > > On Mon, Nov 20, 2017 at 08:32:56PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 20, 2017 at 06:05:55PM +, Will Deacon wrote: > > > Although the current direction of the C++ committee is to prefer > > > that dependencies are explicitly

RE: [PATCH 3/4] RISC-V: Flush I$ when making a dirty page executable

From: Palmer Dabbelt > Sent: 20 November 2017 18:58 > > The RISC-V ISA allows for instruction caches that are not coherent WRT > stores, even on a single hart. As a result, we need to explicitly flush > the instruction cache whenever marking a dirty page as executable in > order to preserve the

RE: [PATCH] PCI: endpoint: use ffz() instead of find_first_zero_bit()

From: Niklas Cassel > Sent: 17 November 2017 09:43 > find_first_zero_bit()'s parameter 'size' is defined in bits, > not in bytes. > > Calling find_first_zero_bit() with the wrong size unit > will lead to insidious bugs. > > Fix this by using replacing find_first_zero_bit() with ffz(), > since

RE: [PATCH x86 v2] uprobe: emulate push insns for uprobe on x86

From: Yonghong Song > Sent: 09 November 2017 00:55 > > Uprobe is a tracing mechanism for userspace programs. > Typical uprobe will incur overhead of two traps. > First trap is caused by replaced trap insn, and > the second trap is to execute the original displaced > insn in user space. > > To

RE: [PATCH v4] scripts: add leaking_addresses.pl

From: Tobin C. Harding > Sent: 07 November 2017 10:32 > > Currently we are leaking addresses from the kernel to user space. This > script is an attempt to find some of those leakages. Script parses > `dmesg` output and /proc and /sys files for hex strings that look like > kernel addresses. ...

RE: [PATCH] LDT improvements

From: Andy Lutomirski > Sent: 08 December 2017 13:20 ... > >> - It would also be a cleaner approach all around, and would avoid the > >> fixmap > >> complications and the scheduler muckery. > > > > The error code of such an access is always 0x03. So I added a special > > handler, which checks

RE: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

From: Michael Ellerman > Sent: 08 December 2017 11:08 ... > If we had a time machine, the right set of flags would be: > > - MAP_FIXED: don't treat addr as a hint, fail if addr is not free > - MAP_REPLACE: replace an existing mapping (or force or clobber) > > But the two were conflated for

RE: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

From: Andrew Morton > Sent: 07 December 2017 23:25 > On Thu, 7 Dec 2017 16:31:23 +0300 Andrey Ryabinin > wrote: > > > On 12/07/2017 03:49 AM, Andrew Morton wrote: > > > (correcting Andrey's email address) > > > > > > > > > From: Ding Tianhong >

RE: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

From: Andrey Ryabinin > Sent: 08 December 2017 10:49 ... > CONFIG_UBSAN_ALIGNMENT is already disabled by default for > HAVE_EFFICIENT_UNALIGNED_ACCESS=y because it's noisy, > but we still allow users to enable it if they want to. > > I don't think we should completely forbid enabling it for >

RE: [PATCH] drm/i915: Use copy_from_user() in fence copying

From: Kees Cook > Sent: 06 December 2017 20:29 > > There's no good reason to separate the access_ok() from the copy, > especially since the access_ok() size is hard-coded instead of using > sizeof(). Instead, just use copy_from_user() directly. Looks like an optimisation to save doing the

RE: [PATCH] LDT improvements

From: Andy Lutomirski > Sent: 08 December 2017 16:48 ... > I mean: if the user CS or SS is not accessed and the LDT is RO, then > we get #PF on the IRET instruction, I think. Dealing with that is > truly awful. Any fault in-kernel on the IRET is horrid. Doesn't really matter which one. Same goes

RE: [PATCH] LDT improvements

From: Andy Lutomirski > Sent: 08 December 2017 16:34 > #GP on IRET is a failure, and we have disgusting code to handle it. Is that the trap in kernel space when the on-stack segment registers are invalid? Definitely needs horrid code... > #PF on IRET would not be a failure -- it's a case where

RE: [PATCH] ubsan: don't handle misaligned address when support unaligned access

From: Ding Tianhong > Sent: 01 December 2017 11:32 > To: a...@linux-foundation.org; aryabi...@virtuozzo.co; > linux-kernel@vger.kernel.org; LinuxArm > Subject: [PATCH] ubsan: don't handle misaligned address when support > unaligned access > > The ubsan always report Warning just like: > >

RE: [GIT PULL] hash addresses printed with %p

From: Ard Biesheuvel > Sent: 04 December 2017 10:03 ... > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes > the .store member as well, which does not exists, and so it cannot be > used directly. > > So we should either add a .store member that is always NULL, or we > should

RE: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK

From: Paul E. McKenney > Sent: 01 December 2017 20:09 > > Because %p prints "(null)" and %pK prints "" or (on > 32-bit systems) "", this commit adjusts torture-test scripting > accordingly. Surely NULL v not-NULL is one bit of info that the message needs to contain?

RE: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK

From: Paul E. McKenney > Sent: 04 December 2017 13:42 > On Mon, Dec 04, 2017 at 12:32:30PM +, David Laight wrote: > > From: Paul E. McKenney > > > Sent: 01 December 2017 20:09 > > > > > > Because %p prints "(null)" and %pK prints "00

RE: [PATCH 11/13] irq debug: do not use print_symbol()

From: Sergey Senozhatsky > Sent: 11 December 2017 12:50 > print_symbol() uses extra stack space to sprintf() symbol > information and then to feed that buffer to printk() > > char buffer[KSYM_SYMBOL_LEN]; > > sprint_symbol(buffer, address); > printk(fmt, buffer); > > Replace

RE: [PATCH] drm/i915: Use copy_from_user() in fence copying

From: Kees Cook > Sent: 08 December 2017 21:10 > >> There's no good reason to separate the access_ok() from the copy, > >> especially since the access_ok() size is hard-coded instead of using > >> sizeof(). Instead, just use copy_from_user() directly. > > > > Looks like an optimisation to save

RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Wu Hao > Sent: 05 December 2017 03:34 ... > > I don't see anything Intel specific here. This could all be named dfl-* > > The maybe some device specific things, e.g Intel FPGA devices supported by > this > driver always have FME DFL at the beginning on the BAR0 for PF device. Since when

RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Alan Tull > Sent: 04 December 2017 19:47 > > On Mon, Nov 27, 2017 at 9:15 PM, Wu Hao <hao...@intel.com> wrote: > > On Mon, Nov 27, 2017 at 10:28:04AM +, David Laight wrote: > >> From: Wu Hao > >> > Sent: 27 November 2017 06:42 &

RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Wu Hao > Sent: 06 December 2017 05:30 ... > > Regarding file names, it seems like the files added to drivers/fpga > > could be uniformly named dfl-*.[ch]. Some are fpga-dfl-*.[ch] while > > other are currently dfl-*.[ch] currently. They don't even want to do into a drivers/fgpa directory.

RE: [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device

From: Alan Tull > Sent: 06 December 2017 15:30 > On Wed, Dec 6, 2017 at 3:44 AM, David Laight <david.lai...@aculab.com> wrote: > > From: Wu Hao > >> Sent: 06 December 2017 05:30 > > ... > >> > Regarding file names, it seems like the files added to dri

RE: [PATCH v2] exec: avoid gcc-8 warning for get_task_comm

From: Arnd Bergmann > Sent: 05 December 2017 15:17 > gcc-8 warns about using strncpy() with the source size as the limit: Hmmm... Someone 'fixed' some of those in the NetBSD tree a few years back. There was one place where the code was correct. A potentially unterminated string was being copied

RE: [PATCH V11 3/5] printk: hash addresses printed with %p

From: David Miller > Sent: 05 December 2017 20:31 ... > > Would it make sense to keep the 3 lowest bits of the address? > > > > Currently printed pointers no longer have any correlation with the actual > > alignment in memory of the object, which is a typical cause of a class of > > bugs. > >

RE: [PATCH v3 01/21] docs: fpga: add a document for Intel FPGA driver overview

From: Alan Tull > Sent: 04 December 2017 19:56 > > +=== > > +Intel FPGA driver Overview > > This doesn't look Intel specific to me. This could all be 'DFL FPGA > Framework' I've not read the

RE: [PATCH v4 0/3] Fix find_first_zero_bit() usage

From: Niklas Cassel > find_first_zero_bit()'s parameter 'size' is defined in bits, > not in bytes. > > Calling find_first_zero_bit() with the wrong size unit > will lead to insidious bugs. > > Fix all uses of find_first_zero_bit() called with > sizeof() as size argument in drivers/pci. ...

RE: [PATCH v4 0/3] Fix find_first_zero_bit() usage

From: Lorenzo Pieralisi > Sent: 12 December 2017 15:24 > > On Tue, Dec 12, 2017 at 02:33:52PM +0000, David Laight wrote: > > From: Niklas Cassel > > > find_first_zero_bit()'s parameter 'size' is defined in bits, > > > not in bytes. > > > > > >

RE: [PATCH] lib/string: avoid reading beyond src buffer in strscpy

From: Andrey Ryabinin > Sent: 11 December 2017 16:44 ... > I suppose that depends on which one strscpy() caller you'd want to test. > Briefly looking at all current users, it doesn't look like they process huge > amounts > of data through strscpy(), thus we shouldn't suffer from a slight >

RE: [PATCH] USB: serial: io_edgeport: mark expected switch fall-throughs

From: Bjørn Mork > Sent: 28 October 2017 11:57 > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > > where we are expecting to fall through. > > > > Notice that in this particular case I replaced "...drop on through" > > comments with a proper "fall through" comment on its

RE: [PATCH] usb: gadget: goku_udc: mark expected switch fall-throughs

From: Gustavo A. R. Silva > Sent: 24 October 2017 04:46 > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > Addresses-Coverity-ID: 145713 > Signed-off-by: Gustavo A. R. Silva > --- >

RE: Enabling peer to peer device transactions for PCIe devices

Please don't top post, write shorter lines, and add the odd blank line. Big blocks of text are hard to read quickly. > From: Petrosyan, Ludwig [mailto:ludwig.petros...@desy.de] > Yes I agree it has to be started with the write transaction, according of > PCIe standard all write > transaction are

RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

From: Jim Quinla > Sent: 24 October 2017 19:08 ... > Hi David, Christoph was also concerned about this: > > "For the block world take a look at __blk_segment_map_sg which does the > merging > of contiguous pages into a single SG segment. You'd have to override > BIOVEC_PHYS_MERGEABLE to

RE: [PATCH 4/8] PCI: host: brcmstb: add dma-ranges for inbound traffic

From: Jim Quinlan > Sent: 24 October 2017 19:16 > The Broadcom STB PCIe host controller is intimately related to the > memory subsystem. This close relationship adds complexity to how cpu > system memory is mapped to PCIe memory. Ideally, this mapping is an > identity mapping, or an identity

RE: [PATCH v10 1/3] lib: Add strongly typed 64bit int_sqrt

From: Crt Mori > Sent: 20 December 2017 14:20 > > There is no option to perform 64bit integer sqrt on 32bit platform. > Added stronger typed int_sqrt64 enables the 64bit calculations to > be performed on 32bit platforms. Although int_sqrt() is a rough > approximation, the same algorithm is used

RE: [PATCH v10 1/3] lib: Add strongly typed 64bit int_sqrt

From: Crt Mori > Sent: 20 December 2017 16:17 > > On 20 December 2017 at 17:00, Peter Zijlstra <pet...@infradead.org> wrote: > > On Wed, Dec 20, 2017 at 02:39:26PM +, David Laight wrote: > > > >> With minor changes it ought to be possible to remove most of

RE: [PATCH v10 1/3] lib: Add strongly typed 64bit int_sqrt

From: Crt Mori > Sent: 20 December 2017 17:30 > >> OK, is there any more easy optimizations you see? > > > > I think this version works. > > It doesn't have the optimisation for small values. > > > > unsigned int sqrt64(unsigned long long x) > > { > > unsigned int x_hi = x >> 32; > > > >

RE: [PATCH v10 1/3] lib: Add strongly typed 64bit int_sqrt

From: Crt Mori > Sent: 20 December 2017 17:30 > I did a quick run through unit tests for the sensor and the results > are way off > ... Try this version instead: unsigned int sqrt64(unsigned long long x_in) { unsigned int x = x_in >> 32; unsigned int b = 0; unsigned int y

RE: [PATCH v10 1/3] lib: Add strongly typed 64bit int_sqrt

From: Joe Perches > Sent: 20 December 2017 17:20 ... > > I think this version works. > > It doesn't have the optimisation for small values. > > > > unsigned int sqrt64(unsigned long long x) > > { > > unsigned int x_hi = x >> 32; > > > > unsigned int b = 0; > > unsigned int

RE: [PATCH] x86: pad assembly functions with INT3

From: H. Peter Anvin > Sent: 11 May 2018 19:54 > > On 05/10/18 09:39, David Laight wrote: > > From: Alexey Dobriyan > >> Sent: 07 May 2018 22:38 > >> > >> Use INT3 instead of NOP. All that padding between functions is > >> an illegal area, no

RE: [PATCH v2] net: dsa: drop some VLAs in switch.c

From: Salvatore Mesoraca > Sent: 07 May 2018 20:03 ... > This optimization will save us an allocation when number of ports is > less than 32 or 64 (depending on arch). > IMHO it's useful, if you consider that, right now, DSA works only with > 12-ports switches. Why not just error out if the

RE: Kernel build with gcc 8 a lot of warnings

From: damian > Sent: 05 May 2018 20:21 > is something special to note when kernel build with gcc 8? I receive various > warnings from the > objtool: Someone ought to persuade the gcc folks to try compiling the Linux kernel before releasing a new compiler :-) David

RE: [PATCH] x86: pad assembly functions with INT3

From: Alexey Dobriyan > Sent: 07 May 2018 22:38 > > Use INT3 instead of NOP. All that padding between functions is > an illegal area, no legitimate code should jump into it. > > I've checked x86_64 allyesconfig disassembly, all changes looks sane: > INT3 is only used after RET or unconditional

RE: [PATCH 0/6] Macrofying inline assembly for better compilation

From: Nadav Amit > Sent: 17 May 2018 17:14 > This patch-set deals with an interesting yet stupid problem: kernel code > that does not get inlined despite its simplicity. There are several > causes for this behavior: "cold" attribute on __init, different function > optimization levels; conditional

RE: [PATCH] staging: lustre: add error handling for try_module_get

From: Zhouyang Jia > Sent: 12 June 2018 05:49 > > When try_module_get fails, the lack of error-handling code may > cause unexpected results. > > This patch adds error-handling code after calling try_module_get. ... > +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c > @@ -2422,7 +2422,10

RE: [PATCH 1/3] perf alias: Remove trailing newline when reading sysfs files

From: Paul Clarke > Sent: 14 June 2018 14:18 ... > > + /* Remove trailing newline from sysfs file */ > > + cp = strrchr(buf, '\n'); > > + if (cp) > > + *cp = '\0'; > > A nit, perhaps, but this will search backwards through the entire string if a > newline is not found, > which is

RE: include/linux/string.h:246:9: warning: '__builtin_strncpy' output truncated before terminating nul copying 4 bytes from a string of the same length

From: Josh Poimboeuf > Sent: 05 June 2018 16:30 ... > What about just changing it to a memcpy? Seems like that would be > cleaner anyway, since the whole point of strncpy is to add the > terminating NULL, which isn't need here. Not really, the point of strncpy is to copy strings that might not

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