From: Yue Hu
> Sent: 21 August 2020 03:44
>
> From: Yue Hu
>
> We observed warning about kzalloc() when register thermal cooling device
> in backlight_device_register(). backlight display can be a cooling device
> since reducing screen brightness will can help reduce temperature.
>
> However,
From: Petr Mladek
> Sent: 20 August 2020 11:16
...
> Now that I think about it. This is the biggest problem with any temporary
> buffer
> for pr_cont() lines. I am more and more convinced that we should just
> _keep the current behavior_. It is not ideal. But sometimes mixed
> messages are always
From: Joe Perches
> Sent: 20 August 2020 09:00
>
> On Thu, 2020-08-20 at 07:44 +0000, David Laight wrote:
> > I've no idea how you'd 'size' the number of buffers.
>
> I believe they are static and assume no more than 10
> simultaneous uses of printk_begin
What I mean
From: Joe Perches
> Sent: 20 August 2020 01:34
>
> On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
> > Implement a new buffering mechanism for pr_cont messages.
> >
> > Old mechanism syntax:
> >
> > printk(KERN_INFO "text");
> > printk(KERN_CONT " continued");
> >
From: Josh Poimboeuf
> Sent: 19 August 2020 18:02
>
> On Wed, Aug 19, 2020 at 09:39:10AM -0700, Andy Lutomirski wrote:
> > On Wed, Aug 19, 2020 at 7:50 AM Josh Poimboeuf wrote:
> > > +/*
> > > + * Sanitize a uaccess pointer such that it becomes NULL if it's not a
> > > valid
> > > + * user
From: Matthew Wilcox
> Sent: 19 August 2020 16:45
>
> On Wed, Aug 19, 2020 at 03:41:48PM +0000, David Laight wrote:
> > Does linux have an O(1) (or do I mean o(1)) pid allocator?
> > Or does it have to do a linear scan to find a gap??
>
> O(log(n)). It us
From: Eric W. Biederman
> Sent: 19 August 2020 16:01
...
> >> Further the design decisions of pids keeps us densly using pids. So I
> >> expect it will be a while before we even come close to using 30 bits of
> >> pid space.
> >
> > Also because it's simply annoying to have to type really large
From: Bernd Petrovitsch
> Sent: 19 August 2020 11:22
>
> On 19/08/2020 10:16, Muni Sekhar wrote:
> > On Tue, Aug 18, 2020 at 11:45 PM peter enderborg
> > wrote:
> [...]
> >> On the 4.4 kernel you dont have
> >>
> >> +CONFIG_RETPOLINE=y
> >> +CONFIG_INTEL_RDT=y
> > Thanks! That is helpful. Yes, I
From: Arnd Bergmann
> Sent: 19 August 2020 09:38
...
> If you are really worried about the write protection being bypassed by
> a different driver or code injection, the best way would seem to be to
> only enable writing in the mtd write callback and disable it immediately
> after the write is
From: Arvind Sankar
> Sent: 18 August 2020 23:26
...
> gcc-10 optimizes the generic memset implementation in there into a call
> to memset. Now that's on x86 which doesn't use the generic
> implementation, but this is just waiting to bite us.
>
> https://godbolt.org/z/6EhG15
Gah, if I want a
From: Nick Desaulniers
> Sent: 18 August 2020 21:59
>
> On Tue, Aug 18, 2020 at 1:27 PM Nick Desaulniers
> wrote:
...
> > > -ffreestanding as it stands today does have __builtin_memcpy and
> > > friends. But you need to then use #define memcpy __builtin_memcpy etc,
> > > which is messy and also
From: Pavel Machek
> Sent: 18 August 2020 10:51
>
> On Mon 2020-08-17 17:16:22, Greg Kroah-Hartman wrote:
> > From: Jim Cromie
> >
> > [ Upstream commit f678ce8cc3cb2ad29df75d8824c74f36398ba871 ]
> >
> > ddebug_describe_flags() currently fills a caller provided string buffer,
> > after testing
> I'm a big fan of -Wdeclaration-after-statement and I think C++ style
> mixed variables/statements code has several disadvantages:
Agreed.
Personally I think declarations should either be either right
at the top of a function or in a very small code block.
Otherwise they are annoying to find.
From: Christoph Hellwig
> Sent: 17 August 2020 08:32
>
> Stop providing the possibility to override the address space using
> set_fs() now that there is no need for that any more. To properly
> handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> x86 a new alternative is
From: Joe Perches
> Sent: 15 August 2020 00:52
...
> > This is why I think any discussion that says "people should buffer
> > their lines themselves and we should get rid if pr_cont()" is
> > fundamentally broken.
> >
> > Don't go down that hole. I won't take it. It's wrong.
>
> I don't think
From: Nick Desaulniers
> Sent: 15 August 2020 01:24
>
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings.
>
>
From: Luis Henriques
> Sent: 14 August 2020 10:38
>
> Since there's a return immediately after the 'break', there's no need for
> this extra 'return' in the S_IFDIR case.
>
> Signed-off-by: Luis Henriques
> ---
> fs/ceph/file.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
From: Josef Bacik
> Sent: 13 August 2020 18:19
...
> We wouldn't even need the extra +1 part, since we're only copying in how much
> the user wants anyway, we could just go ahead and convert this to
>
> left -= snprintf(buffer, left, "0x%04x\n", *(unsigned int *) table->data);
>
> and be fine,
From: Josef Bacik
> Sent: 13 August 2020 15:53
>
> sysctl: pass kernel pointers to ->proc_handler
>
> we have been pre-allocating a buffer to copy the data from the proc
> handlers into, and then copying that to userspace. The problem is this
> just blind kmalloc()'s the buffer size passed in
From: Daniel Axtens
> Sent: 13 August 2020 12:37
>
> >> Seem like this could simply use a copy_to_user to further simplify
> >> things?
> >
> > I'll benchmark it and find out.
>
> I tried this:
>
> for (walk = head; walk; walk = walk->next) {
> - struct pollfd *fds =
From: Xu Yilun
> Sent: 13 August 2020 10:04
>
> On Thu, Aug 13, 2020 at 08:28:05AM +0000, David Laight wrote:
> > From: Xu Yilun
> > > Sent: 13 August 2020 08:59
> > > On Wed, Aug 12, 2020 at 08:52:39AM +, David Laight wrote:
> > > > From: Moritz
From: Christoph Hellwig
> Sent: 13 August 2020 08:32
>
> On Thu, Aug 13, 2020 at 05:11:20PM +1000, Daniel Axtens wrote:
> > When returning results to userspace, do_sys_poll repeatedly calls
> > put_user() - once per fd that it's watching.
> >
> > This means that on architectures that support some
From: Nick Desaulniers
> Sent: 13 August 2020 01:13
>
> On Thu, Aug 6, 2020 at 3:11 PM Thomas Gleixner wrote:
> >
> > Arnd Bergmann writes:
> > > When using the clang integrated assembler, we get a reference
> > > to __force_order that should normally get ignored in a few
> > > rare cases:
> >
From: Xu Yilun
> Sent: 13 August 2020 08:59
> On Wed, Aug 12, 2020 at 08:52:39AM +, David Laight wrote:
> > From: Moritz Fischer
> > > Sent: 12 August 2020 04:56
> > >
> > > On Mon, Aug 10, 2020 at 10:41:10AM +0800, Xu Yilun wrote:
> > > > Th
From: Miles Chen
> Sent: 12 August 2020 10:16
>
> On Tue, 2020-08-11 at 11:44 +0000, David Laight wrote:
> > > On Tue, Aug 11, 2020 at 06:27:04PM +0800, Miles Chen wrote:
> > > > From: Miles Chen
> > > >
> > > > sockptr_
From: Moritz Fischer
> Sent: 12 August 2020 04:56
>
> On Mon, Aug 10, 2020 at 10:41:10AM +0800, Xu Yilun wrote:
> > The feature id is stored in a 12 bit field in DFH. So a u16 variable is
> > enough for feature id.
> >
> > This patch changes all feature id related places to fit u16.
How much
> On Tue, Aug 11, 2020 at 02:47:03PM +0000, David Laight wrote:
> > From: Andi Kleen
> > > On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> > > > On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> > > >
> > > > >
From: Andi Kleen
> On Mon, Aug 10, 2020 at 10:36:32PM +0200, Peter Zijlstra wrote:
> > On Mon, Aug 10, 2020 at 07:45:18AM -0700, Andi Kleen wrote:
> >
> > > Unfortunately we're kind of stuck with the old NFILE=1024 default
> > > even though it makes little sense on modern servers.
> >
> > Why
> On Tue, Aug 11, 2020 at 06:27:04PM +0800, Miles Chen wrote:
> > From: Miles Chen
> >
> > sockptr_is_kernel() uses (sockptr.kernel >= TASK_SIZE) to tell
> > if the pointer is kernel space or user space. When user space uses
> > the "top byte ignored" feature such as HWAsan, we must untag
> > the
> On 11/08/2020 00:28, Al Viro wrote:
> > On Mon, Aug 10, 2020 at 10:09:09PM +0000, David Laight wrote:
> >>> On Mon, Aug 10, 2020 at 10:11:53PM +0200, Mickaël Salaün wrote:
> >>>> It seems that there is no more complains nor questions. Do you want me
> >&
> On Mon, Aug 10, 2020 at 10:11:53PM +0200, Mickaël Salaün wrote:
> > It seems that there is no more complains nor questions. Do you want me
> > to send another series to fix the order of the S-o-b in patch 7?
>
> There is a major question regarding the API design and the choice of
> hooking that
From: pet...@infradead.org
> Sent: 10 August 2020 12:58
>
...
> > > --- a/include/linux/entry-common.h
> > > +++ b/include/linux/entry-common.h
> > > @@ -310,6 +310,7 @@ void irqentry_exit_to_user_mode(struct p
> > > #ifndef irqentry_state
> > > typedef struct irqentry_state {
> > > bool
> Thanks for your explanation and review. I haven't realized using strncpy() on
> NUL-terminated strings
> is deprecated
> and just trying to avoid the compile warnings. The website you provide helps
> me a lot. Thank you very
> much!
Never try to remove compile-time warnings without
From: Eric Dumazet
> Sent: 07 August 2020 19:29
>
> On 8/7/20 2:18 AM, David Laight wrote:
> > From: Eric Dumazet
> >> Sent: 06 August 2020 23:21
> >>
> >> On 7/22/20 11:09 PM, Christoph Hellwig wrote:
> >>> Rework the remaining setsockopt
From: luobin (L)
> Sent: 08 August 2020 04:37
>
> On 2020/8/7 17:32, David Laight wrote:
> > From: Luo bin
> >> Sent: 07 August 2020 03:09
> >>
> >> fix the compile warnings of 'strncpy' output truncated before
> >> terminating nul copying N byte
From: Christoph Hellwig
> Sent: 31 July 2020 13:22
>
> Fold the misaligned u64 workarounds into the main quotactl flow instead
> of implementing a separate compat syscall handler.
>
...
> +static int compat_copy_fs_quota_stat(struct compat_fs_quota_stat __user *to,
> + struct
From: Luo bin
> Sent: 07 August 2020 03:09
>
> fix the compile warnings of 'strncpy' output truncated before
> terminating nul copying N bytes from a string of the same length
>
> Signed-off-by: Luo bin
> Reported-by: kernel test robot
> ---
> V0~V1:
> - use the strlen()+1 pattern consistently
From: Eric Dumazet
> Sent: 06 August 2020 23:21
>
> On 7/22/20 11:09 PM, Christoph Hellwig wrote:
> > Rework the remaining setsockopt code to pass a sockptr_t instead of a
> > plain user pointer. This removes the last remaining set_fs(KERNEL_DS)
> > outside of architecture specific code.
> >
> >
From: Christoph Hellwig
> Sent: 31 July 2020 13:22
>
> Fold the misaligned u64 workarounds into the main quotactl flow instead
> of implementing a separate compat syscall handler.
>
...
> diff --git a/fs/quota/compat.h b/fs/quota/compat.h
> new file mode 100644
> index
> > > If you look at the libffi reference patch I have included, the
> > > architecture
> > > specific changes to use trampfd just involve a single C function call to
> > > a common code function.
>
> No idea what libffi is, but it must surely be simpler to
> rewrite it to avoid nested function
> > If you look at the libffi reference patch I have included, the architecture
> > specific changes to use trampfd just involve a single C function call to
> > a common code function.
No idea what libffi is, but it must surely be simpler to
rewrite it to avoid nested function definitions.
Or
From: James Bottomley
> Sent: 03 August 2020 16:43
>
> On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
> [...]
> > What is wrong with live migration between one qemu process and
> > another qemu process on the same machine not work for this use case?
> >
> > Just reusing live
From: Madhavan T. Venkataraman
> Sent: 03 August 2020 17:03
>
> On 8/3/20 3:27 AM, David Laight wrote:
> > From: Mark Rutland
> >> Sent: 31 July 2020 19:32
> > ...
> >>> It requires PC-relative data references. I have not worked on all
> >>>
> Maybe. We still need to preserve an anonymous segment, though. MADV_DOEXEC,
> or mshare,
> or something else. And I think the ability to preserve memory containing
> pointers to itself
> is an interesting use case, though not ours.
Why does all this remind me of the old sendmail code.
From: Mark Rutland
> Sent: 31 July 2020 19:32
...
> > It requires PC-relative data references. I have not worked on all
> > architectures.
> > So, I need to study this. But do all ISAs support PC-relative data
> > references?
>
> Not all do, but pretty much any recent ISA will as it's a
From: Madhavan T. Venkataraman
> Sent: 02 August 2020 19:55
> To: Andy Lutomirski
> Cc: Kernel Hardening ; Linux API
> ;
> linux-arm-kernel ; Linux FS Devel
> fsde...@vger.kernel.org>; linux-integrity ;
> LKML ker...@vger.kernel.org>; LSM List ;
> Oleg Nesterov
> ; X86 ML
> Subject: Re:
From: Pavel Machek
> Sent: 02 August 2020 12:56
> Hi!
>
> > > This is quite clever, but now I???m wondering just how much kernel help
> > > is really needed. In your series, the trampoline is an non-executable
> > > page. I can think of at least two alternative approaches, and I'd
> > > like to
From: Joerg Roedel
> Sent: 30 July 2020 16:44
>
> From: Borislav Petkov
>
> Use the shorthand to make it more readable.
...
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 8744817358bf..6b4b43f68f4b 100644
> --- a/arch/x86/include/asm/svm.h
> +++
> This is quite clever, but now I’m wondering just how much kernel help
> is really needed. In your series, the trampoline is an non-executable
> page. I can think of at least two alternative approaches, and I'd
> like to know the pros and cons.
>
> 1. Entirely userspace: a return trampoline
From: Madhavan T. Venkataraman
> Sent: 28 July 2020 19:52
...
> trampfd faults are instruction faults that go through a different code path
> than
> the one that calls handle_mm_fault(). Perhaps, it is the handle_mm_fault()
> that
> is time consuming. Could you clarify?
Given that the
From: madve...@linux.microsoft.com
> Sent: 28 July 2020 14:11
...
> The kernel creates the trampoline mapping without any permissions. When
> the trampoline is executed by user code, a page fault happens and the
> kernel gets control. The kernel recognizes that this is a trampoline
> invocation.
From: Peilin Ye
> Sent: 28 July 2020 12:52
> Currently `struct drm_buf_desc` is defined as follows:
>
> struct drm_buf_desc {
> int count;
> int size;
> int low_mark;
> int high_mark;
> enum {
> _DRM_PAGE_ALIGN = 0x01,
> _DRM_AGP_BUFFER =
From: Christian Eggers
> Sent: 28 July 2020 11:30
>
> On Tuesday, 28 July 2020, 11:52:05 CEST, David Laight wrote:
> > From: Christian Eggers
> >
> > > Sent: 28 July 2020 10:30
> > >
> > > SPI eeproms are addressed by byte.
> >
> > T
From: Christian Eggers
> Sent: 28 July 2020 10:30
>
> SPI eeproms are addressed by byte.
They also support multi-byte writes - possibly with alignment
restrictions.
So forcing 4-byte writes (at aligned addresses) would typically
speed up writes by a factor of 4 over byte writes.
So does this
From: Christoph Hellwig
> Sent: 27 July 2020 17:24
>
> On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote:
> > Maybe sockptr_advance should have some safety checks and sometimes
> > return -EFAULT? Or you should always use the implementation where
> > being a kernel address is an
From: Al Viro
> Sent: 27 July 2020 14:48
>
> On Mon, Jul 27, 2020 at 09:51:45AM +0000, David Laight wrote:
>
> > I'm sure there is code that processes options in chunks.
> > This probably means it is possible to put a chunk boundary
> > at the end of userspace an
From: Ido Schimmel
> Sent: 27 July 2020 13:15
> On Thu, Jul 23, 2020 at 08:09:01AM +0200, Christoph Hellwig wrote:
> > Pass a sockptr_t to prepare for set_fs-less handling of the kernel
> > pointer from bpf-cgroup.
> >
> > Note that the get case is pretty weird in that it actually copies data
> >
From: David Miller
> Sent: 24 July 2020 23:44
>
> From: Christoph Hellwig
> Date: Thu, 23 Jul 2020 08:08:42 +0200
>
> > setsockopt is the last place in architecture-independ code that still
> > uses set_fs to force the uaccess routines to operate on kernel pointers.
> >
> > This series adds a
From: Sebastian Gottschall
> Sent: 25 July 2020 16:42
> >> i agree. i just can say that i tested this patch recently due this
> >> discussion here. and it can be changed by sysfs. but it doesnt work for
> >> wifi drivers which are mainly using dummy netdev devices. for this i
> >> made a small
From: Al Viro
> Sent: 23 July 2020 16:21
...
> The point is, your "~4.5 cycles per vector" is pretty much noise and the
> difference between the 3-argument and 4-argument variants could easily be
> in the same range. It might be a valid microoptimization, it might be not.
> 3-argument variant is
From: Al Viro
> Sent: 23 July 2020 15:54
> On Thu, Jul 23, 2020 at 01:54:47PM +, David Laight wrote:
> > From: Al Viro
> > > Sent: 22 July 2020 18:39
> > > I would love to see your patch, anyway, along with the testcases and
> > > performance
> &g
From: 'Christoph Hellwig'
> Sent: 23 July 2020 15:45
>
> On Thu, Jul 23, 2020 at 02:42:11PM +0000, David Laight wrote:
> > From: Christoph Hellwig
> > > Sent: 23 July 2020 07:09
> > >
> > > The bpfilter user mode helper processes the optval address
From: Christoph Hellwig
> Sent: 23 July 2020 07:09
>
> The bpfilter user mode helper processes the optval address using
> process_vm_readv. Don't send it kernel addresses fed under
> set_fs(KERNEL_DS) as that won't work.
What sort of operations is the bpf filter doing on the sockopt buffers?
> I had to replace the ror32() with __builtin_bswap32().
> The kernel object do contain the 'ror' instruction - even though I
> didn't find the asm for it.
Looking at some instruction timings ror32() and bswap32()
seem to need one of the same execution ports.
However on Intel cpus bswap64() takes
From: Al Viro
> Sent: 22 July 2020 18:39
> I would love to see your patch, anyway, along with the testcases and
> performance
> comparison.
See attached program.
Compile and run (as root): csum_iov 1
Unpatched (as shipped) 16 vectors of 1 byte take ~430 clocks on my haswell cpu.
With dsl_patch
From: Christoph Hellwig
> Sent: 23 July 2020 07:09
>
> This is mostly to prepare for cleaning up the callers, as bpfilter by
> design can't handle kernel pointers.
You've failed to fix the sense of the above...
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton
From: Catalin Marinas
> Sent: 23 July 2020 11:19
> On Thu, Jul 23, 2020 at 08:37:27AM +, David Laight wrote:
> > From: Catalin Marinas
> > > Sent: 22 July 2020 17:54
> > > On Wed, Jul 22, 2020 at 01:14:21PM +, David Laight wrote:
> > > > From: Ca
From: Catalin Marinas
> Sent: 22 July 2020 17:54
>
> On Wed, Jul 22, 2020 at 01:14:21PM +0000, David Laight wrote:
> > From: Catalin Marinas
> > > Sent: 22 July 2020 12:37
> > > On Sun, Jul 19, 2020 at 12:34:11PM -0700, Linus Torvalds wrote:
> > > > On
From: Al Viro
> Sent: 22 July 2020 18:39
> On Wed, Jul 22, 2020 at 04:17:02PM +, David Laight wrote:
> > > David, do you *ever* bother to RTFS? I mean, competent supercilious twits
> > > are annoying, but at least with those you can generally assume that what
&g
From: Al Viro > Sent: 22 July 2020 16:55
> To: David Laight
> Cc: Linus Torvalds ;
> linux-kernel@vger.kernel.org; linux-
> a...@vger.kernel.org
> Subject: Re: [PATCH 04/18] csum_and_copy_..._user(): pass 0x instead
> of 0 as initial sum
>
> On Wed, Jul 2
From: Al Viro
> Sent: 22 July 2020 15:42
>
> On Wed, Jul 22, 2020 at 09:27:32AM +0000, David Laight wrote:
> > From: Al Viro
> > > Sent: 21 July 2020 21:26
> > > Preparation for the change of calling conventions; right now all
> > > callers pass 0 a
From: Catalin Marinas
> Sent: 22 July 2020 12:37
>
> On Sun, Jul 19, 2020 at 12:34:11PM -0700, Linus Torvalds wrote:
> > On Sun, Jul 19, 2020 at 12:28 PM Linus Torvalds
> > wrote:
> > > I think we should try to get rid of the exact semantics.
> >
> > Side note: I think one of the historical
From: Linus Torvalds
> Sent: 21 July 2020 21:55
> On Tue, Jul 21, 2020 at 1:25 PM Al Viro wrote:
> >
> > Preparation for the change of calling conventions; right now all
> > callers pass 0 as initial sum. Passing 0x instead yields
> > the values comparable mod 0x and guarantees that
From: Al Viro
> Sent: 21 July 2020 21:26
> Preparation for the change of calling conventions; right now all
> callers pass 0 as initial sum. Passing 0x instead yields
> the values comparable mod 0x and guarantees that 0 will not
> be returned on success.
>
> Signed-off-by: Al Viro
>
From: Andrew Lunn
> Sent: 21 July 2020 18:25
>
> On Tue, Jul 21, 2020 at 10:44:19PM +0530, Rakesh Pillai wrote:
> > NAPI gets scheduled on the CPU core which got the
> > interrupt. The linux scheduler cannot move it to a
> > different core, even if the CPU on which NAPI is running
> > is heavily
From: Christoph Hellwig
> Sent: 22 July 2020 07:31
...
> > I agree that MSG_CMSG_COMPAT is nasty, but I think the concept is
> > sound -- rather than tracking whether we're compat by using a
> > different function or a per-thread variable, actually explicitly
> > tracking the mode seems sensible.
From: 'Christoph Hellwig'
> Sent: 22 July 2020 09:07
> On Tue, Jul 21, 2020 at 09:38:23AM +, David Laight wrote:
> > From: Christoph Hellwig
> > > Sent: 20 July 2020 13:47
> > >
> > > setsockopt is the last place in architecture-independ code that still
From: Thomas Gleixner
> Sent: 21 July 2020 17:11
>
> Frederic Weisbecker writes:
> > On Thu, Jul 16, 2020 at 10:19:25PM +0200, Thomas Gleixner wrote:
> >> --- a/kernel/time/posix-cpu-timers.c
> >> +++ b/kernel/time/posix-cpu-timers.c
> >> @@ -25,7 +25,7 @@ void posix_cputimers_group_init(struct
From: Christoph Hellwig
> Sent: 20 July 2020 13:47
>
> setsockopt is the last place in architecture-independ code that still
> uses set_fs to force the uaccess routines to operate on kernel pointers.
>
> This series adds a new sockptr_t type that can contained either a kernel
> or user pointer,
From: Christoph Hellwig
> Sent: 20 July 2020 13:47
>
> Add a uptr_t type that can hold a pointer to either a user or kernel
> memory region, and simply helpers to copy to and from it. For
> architectures like x86 that have non-overlapping user and kernel
> address space it just is a union and
From: Eric Biggers
> Sent: 20 July 2020 17:38
...
> How does this not introduce a massive security hole when
> CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE?
>
> AFAICS, userspace can pass in a pointer >= TASK_SIZE,
> and this code makes it be treated as a kernel pointer.
One thought I've had is
From: Christoph Hellwig
> Sent: 20 July 2020 13:47
>
> setsockopt is the last place in architecture-independ code that still
> uses set_fs to force the uaccess routines to operate on kernel pointers.
>
> This series adds a new sockptr_t type that can contained either a kernel
> or user pointer,
From: Christoph Hellwig
> Sent: 20 July 2020 13:47
>
> This is mostly to prepare for cleaning up the callers, as bpfilter by
> design can't handle kernel pointers.
^^^ user ??
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
From: lebon zhou
> Sent: 20 July 2020 05:35
> To: da...@davemloft.net; k...@kernel.org
> Cc: linux-kernel@vger.kernel.org; net...@vger.kernel.org
> Subject: [PATCH] Fix memory overwriting issue when copy an address to user
> space
>
> When application provided buffer size less than
From: Adrian Bunk
> Sent: 19 July 2020 19:19
...
> The correct range for a mandatory tool are the 6 to 12 years for gcc.
>
> Debian stable and Ubuntu LTS are providing (different) mechanisms
> for installing the kernel from the next stable/LTS release 2 years
> later[1] for supporting new
From: Kees Cook
> Sent: 17 July 2020 18:43
> In preparation for further refactoring of kernel_read_file*(), rename
> the "max_size" argument to the more accurate "buf_size", and correct
> its type to size_t. Add kerndoc to explain the specifics of how the
> arguments will be used. Note that with
From: js1...@gmail.com
> Sent: 15 July 2020 06:05
> From: Joonsoo Kim
>
> Currently, preventing cma area in page allocation is implemented by using
> current_gfp_context(). However, there are two problems of this
> implementation.
...
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index
From: Benjamin Herrenschmidt
> Sent: 15 July 2020 23:49
> On Wed, 2020-07-15 at 17:12 -0500, Bjorn Helgaas wrote:
> > > I've 'played' with PCIe error handling - without much success.
> > > What might be useful is for a driver that has just read ~0u to
> > > be able to ask 'has there been an error
From: Kees Cook
> Sent: 15 July 2020 16:09
>
> On Wed, Jul 15, 2020 at 02:55:50PM +0000, David Laight wrote:
> > From: Christoph Hellwig
> > > Sent: 15 July 2020 07:43
> > > Subject: Re: [PATCH 7/7] exec: Implement kernel_execve
> > >
> > >
From: Christoph Hellwig
> Sent: 15 July 2020 07:43
> Subject: Re: [PATCH 7/7] exec: Implement kernel_execve
>
> On Tue, Jul 14, 2020 at 02:49:23PM -0700, Kees Cook wrote:
> > On Tue, Jul 14, 2020 at 08:31:40AM -0500, Eric W. Biederman wrote:
> > > +static int count_strings_kernel(const char
From: Oliver O'Halloran
> Sent: 15 July 2020 05:19
>
> On Wed, Jul 15, 2020 at 8:03 AM Arnd Bergmann wrote:
...
> > - config space accesses are very rare compared to memory
> > space access and on the hardware side the error handling
> > would be similar, but readl/writel don't return
From: Adrian Bunk
> Sent: 12 July 2020 21:45
> Rust gets updated frequently.
> Sometimes this also changes the LLVM version used by Rust.
> Debian stable supports targets like ARMv5 and 32bit MIPS.
> Distribution kernel updates are often automatically installed
> on user hardware.
This
> From: Saheed Olayemi Bolarinwa
> Sent: 10 July 2020 22:20
> To: helg...@kernel.org
> From: Bolarinwa Olayemi Saheed
>
> On failure pcie_capability_read_dword() sets it's last parameter,
> val to 0.
> However, with Patch 14/14, it is possible that val is set to ~0 on
> failure. This would
From: Linus Torvalds
> Sent: 10 July 2020 23:37
> On Tue, Jul 7, 2020 at 5:35 AM David Laight wrote:
> >
> >
> > So separate copy and checksum passes should easily exceed 4 bytes/clock,
> > but I suspect that doing them together never does.
> > (Unless th
From: Al Viro
> Sent: 04 July 2020 03:12
...
> BTW, looking at csum_and_copy_{to,from}_user() callers (all 3 of them,
> all in lib/iov_iter.c) we have this:
> 1) len is never 0
> 2) sum (initial value of csum) is always 0
> 3) failure (reported via *err_ptr) is always treateds as
From: Pavel Machek
> Sent: 02 July 2020 22:17
> > > during a FLASH write or erase can cause from weakened cells, to much
> > > larger damage. It is possible to harden the chip or the design against
> > > this, but it is *expensive*. And even if warded off by hardening and no
> > > FLASH damage
From: Kars Mulder
> Sent: 02 July 2020 22:48
>
> On Thursday, July 02, 2020 09:55 CEST, David Laight wrote:
> > Hmm... sscanf() is also horrid.
> > Surprisingly difficult to use correctly.
> >
> > It is usually best to use strchr() (and maybe str[c]scn())
> >
From: Paul E. McKenney
> Sent: 01 July 2020 17:06
...
> > Would an asm statement that uses the same 'register' for input and
> > output but doesn't actually do anything help?
> > It won't generate any code, but the compiler ought to assume that
> > it might change the value - so can't do
From: Kars Mulder
> Sent: 02 July 2020 00:03
> On Saturday, June 27, 2020 12:24 CEST, David Laight wrote:
> > The code quoted (using strset()) is almost certainly wrong.
> > The caller is unlikely to expect the input be modified.
> > Since it doesn't fault the string must
From: Peter Zijlstra
> Sent: 01 July 2020 10:11
> On Tue, Jun 30, 2020 at 01:30:16PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 30, 2020 at 10:12:43PM +0200, Peter Zijlstra wrote:
>
> > > I'm not convinced C11 memory_order_consume would actually work for us,
> > > even if it would work. That
601 - 700 of 2838 matches
Mail list logo
