On Sat, Nov 25, 2017 at 08:44:19AM +1100, Tobin C. Harding wrote:
> There is currently very little documentation in the kernel on maintainer
> level tasks. In particular there are no documents on creating pull
> requests to submit to Linus.
>
> Quoting Greg Kroah-Hartman on LKML:
>
> Anyway,
Hi All,
I want to talk about a potential GPL misuse of the Linux open source
that is used by Tesla Model S. Some months ago, I have read that a
version information of Linux kernel that is deployed into the
commercial self-driving car such as Tesla Model S via (1) the twitter
web page of Tesla CEO
So far any changes with ebtables will reset the state of limit rules,
leading to spikes in traffic. This is especially noticeable if changes
are done frequently, for instance via a daemon.
This patch fixes this by bailing out from (re)setting if the limit
rule was initialized before.
When sending
From: Jiankang Chen
__get_free_pages will return an 64bit address in 64bit System
like arm64 or x86_64. And this comment really confuse new bigenner of
mm.
Signed-off-by: Jiankang Chen
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/
All attribute group created during sys_init_dir() should be removed
in sys_free_dir()
Signed-off-by: Arvind Yadav
---
drivers/staging/ccree/ssi_sysfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_sysfs.c
b/drivers/staging/ccree/ssi_sysfs.c
i
All attribute group created during ldlm_setup() should be removed
in ldlm_cleanup().
Signed-off-by: Arvind Yadav
---
drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c
b/drivers/s
All attribute group created during dim2_sysfs_probe() should be removed
in dim2_sysfs_destroy().
Signed-off-by: Arvind Yadav
---
drivers/staging/most/hdm-dim2/dim2_sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/most/hdm-dim2/dim2_sysfs.c
b/drivers/staging/most/hdm-d
Arvind Yadav (4):
[PATCH 1/4] staging: ccree: Remove a attribute group from a kobject
[PATCH 2/4] staging: lustre: ldlm: Remove a attribute group from a kobject
[PATCH 3/4] staging: lustre: obdclass: Remove a attribute group from a kobject
[PATCH 4/4] staging: most: Remove a attribute group
All attribute group created during class_procfs_init() should be
removed.
if class_procfs_init() will fail and also in class_procfs_clean().
Signed-off-by: Arvind Yadav
---
drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/
From: c00426987
__get_free_pages will return an 64bit address in 64bit System
like arm64 or x86_64. And this comment really
confuse new bigenner of mm.
reported-by: Hanjun Guo
Signed-off-by: Chen Jiankang
---
mm/page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
On Fri, Nov 24, 2017 at 2:36 AM, Reshetova, Elena
wrote:
>> On Fri, Oct 20, 2017 at 10:37:38AM +0300, Elena Reshetova wrote:
>> > } else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
>> > r = upgrade_mode(dd, mode, t->md);
>> > if (r)
>> > ret
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0,
Hi Baolin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/timers/core]
[also build test WARNING on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Sat, Nov 25, 2017 at 02:29:36AM +0100, ishraq.i.ash...@gmail.com wrote:
> +
> + ret = 0;
> +
Sorry, I wasn't clear before. When I said don't initialize "ret" to
zero, I just meant that in that specific case we initialized "ret" and
then immediately reassigned it with:
ret = some_f
Here, The function pdc_hardware_init always return zero. So it is not
necessary to check its return value. So make the function return void.
Fix these checkpatch.pl error:
ERROR: space prohibited after that '~' (ctx:WxW)
+ mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
ERROR: spaces requir
Hi Baolin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/timers/core]
[also build test WARNING on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Thanks for doing this.
This needs to be folded in with the earlier patch you send and then
resend it as a V2 patch.
https://kernelnewbies.org/FirstKernelPatch#head-5c81b3c517a1d0bbc24f92594cb734e155fcbbcb
I added Johannes to the CC list again because this is sort of his
fault... To be honest, I'
On Sat, 2017-11-25 at 09:45 +0530, Arvind Yadav wrote:
> Here, The function pdc_hardware_init always return zero. So it is not
> necessary to check its return value.
>
> Fix these checkpatch.pl error:
>
> ERROR: space prohibited after that '~' (ctx:WxW)
> + mask &= ~ (1 << (6 + ATA_SH
Here, The function pdc_hardware_init always return zero. So it is not
necessary to check its return value.
Fix these checkpatch.pl error:
ERROR: space prohibited after that '~' (ctx:WxW)
+ mask &= ~ (1 << (6 + ATA_SHIFT_UDMA));
ERROR: spaces required around that '?' (ctx:VxW)
+
On 11/24/2017 08:09 PM, Dave Hansen wrote:
> Doesn't this stack trace mean we started C-code page fault handing on
> the sysenter stack? Seems like we missed a switch to the process stack.
... and probably a KAISER switch to the kernel CR3.
On 11/24/2017 12:22 PM, Ingo Molnar wrote:
> [8.831002] RIP: 0010:page_fault+0x11/0x60
> [8.831002] RSP: :ff0e7fc8 EFLAGS: 00010046
> [8.831002] RAX: 819d4d77 RBX: 0001 RCX:
> 819d4d77
> [8.831002] RDX: 0003 RSI: 0010
On Fri, Nov 24, 2017 at 08:51:02AM -0800, Andi Kleen wrote:
> > I think e2fsck can fix this quite easily, and there really isn't
> > an easy way to revert to the old method if the large xattr feature
> > is enabled. If you are willing to run a new kernel, you should also
> > be willing to run a ne
Remove the variable page_idx which no one would miss.
Signed-off-by: Fan li
---
fs/f2fs/data.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index b0781ed..1a9 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1198,7 +1198,6 @@ stat
CR4 changes need to be performed while IRQs are disabled in order to
update the CR4 shadow and the actual register atomically. Actually, they
are needed regardless of CR4 shadowing, since CR4 are performed in a
read-modify-write manner.
Currently, however, this is not the case, as can be experienc
CR4 needs to be updated atomically with its shadow value, as CR4 updates are
performed in read-modify-write fashion which are based on the shadow value. If
CR4 is changed between the read and the write, CR4 might not be updated
correctly.
For this to happen, CR4 needs to be rewritten by an interru
Refactor the write to CR4 and its shadow value. This is done in
preparation for the addition of an assertion to check that IRQs are
disabled during CR4 update.
No functional change.
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-off-by
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri, Nov 24, 2017 at 5:31 AM, David Howells wrote:
>
> It doesn't seem useful to have the init_task in a header file rather than
> in a normal source file. We could consolidate init_task handling instead.
> Do want to do this? If so, this is probably something we'd want to do at
> the end of
On Fri, Nov 24, 2017 at 03:02:33PM +0100, Ingo Molnar wrote:
* kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-6):
commit: a6c70b8b30bf35045d14e352bfd1eb16aaee906f ("x86/mm/kaiser: Prepare assembly
for entry/exit CR3 switching")
https://git.kernel.org/cgit/lin
In Intel SDM Volume 3B (253669-063US, July 2017), SRAO could be
reported either via MCE or CMC:
In cases when SRAO is signaled via CMCI the error signature is
indicated via UC=1, PCC=0, S=0.
Type(*1) UC EN PCC S AR Signaling
--
Yes , your modification is much better! thanks.
在 2017/11/24 21:08, Michal Hocko 写道:
On Fri 24-11-17 20:51:29, 郭雪楠 wrote:
Sorry,I explained wrong before. But,I've tested using trinity in DAX
mode,and I'am sure it has possibility of triggering an soft lockup. I have
encountered the problem of e
> Sure, but not many people are going to be running a 4.14 kernel with
> a 2007 system.
It's not just root, but any disk. People could well have 10 year old
disks.
> Could you please run the updated find command to see
> whether this is an isolated case, or if it is a common case:
>
> find / -
From: Ishraq Ibne Ashraf
Commit 8bfb36766064 ("wireless: wext: remove ndo_do_ioctl fallback") breaks
private WEXT
IOCTL calls of this driver as these are not invoked through ndo_do_ioctl
interface anymore. As a result hostapd stops working with this driver. In
this patch this problem is solved b
On Wed, Nov 22, 2017 at 04:35:18PM -0800, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Currently, all of the checks for KAISER are compile-time checks.
>
> Runtime checks are needed for turning it on/off at runtime.
>
> Add a function to do that.
>
> Signed-off-by: Dave Hansen
> Cc: Moritz L
On Wed, Nov 22, 2017 at 04:35:21PM -0800, Dave Hansen wrote:
>
> From: Dave Hansen
>
> With KAISER Kernel PGDs that map userspace are "poisoned" with
> the NX bit. This ensures that if a kernel->user CR3 switch is
> missed, userspace crashes instead of running in an unhardened
> state.
>
> Thi
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sound/for-next]
[also build test ERROR on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Maciej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sound/for-next]
[also build test ERROR on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri, 24 Nov 2017, Greg Kroah-Hartman wrote:
> > >
> > > But what happens when the bus code is unloaded if it is built as a
> > > module? The devices will be removed then. Or they should be.
> > >
> >
> > This bus driver is not a module.
>
> It can not be built as a module ever?
>
That'
From: Ishraq Ibne Ashraf
Apply changes suggested by Dan Carpenter
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 1052
1 file changed, 536 insertions(+), 516 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_d
On Fri, 24 Nov 2017, Ingo Molnar wrote:
> @@ -1288,6 +1308,8 @@ ENTRY(error_entry)
>* from user mode due to an IRET fault.
>*/
> SWAPGS
> + /* We have user CR3. Change to kernel CR3. */
> + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax
>
> .Lerror_entry_from_usermode_after
Tim,
Your patch looks good, but your patch description needs some care:
Please do not write full sentences in the subject line. The subject line
should be a short and precise information about the patch. The format is:
[PATCH] subsystem: Short precise description.
in this case:
[
On Fri, 24 Nov 2017, Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 12:52 AM, Juergen Gross wrote:
> > Sorry, Andy, forgot to Cc: you...
> >
> > On 24/11/17 09:42, Juergen Gross wrote:
> >> Add early interrupt handlers activated by idt_setup_early_handler() to
> >> the handlers supported by Xen
* Andy Lutomirski wrote:
> > Note that if *any* of those 4 padding sequences is removed, the kernel
> > starts
> > crashing again. Also note that the exact size of the padding appears to be
> > not
> > material - it could be larger as well, i.e. it's not an alignment bug I
> > think.
> >
>
> On Nov 24, 2017, at 3:09 PM, Ingo Molnar wrote:
>
>
> * Ingo Molnar wrote:
>
>>
>> * Ingo Molnar wrote:
>>
>>> This is a repost of the latest entry-stack plus Kaiser bits from Andy
>>> Lutomirski
>>> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
>>> on to
On Fri, 2017-11-24 at 15:03 -0700, Andreas Dilger wrote:
> On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
> >
> >
> > >
> > > We checked old kernels, and old e2fsprogs, and didn't see any
> > > cases
> > > where fast (<= 60 chars) symlinks were created using external
> > > blocks.
> > > It seem
* Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > This is a repost of the latest entry-stack plus Kaiser bits from Andy
> > Lutomirski
> > (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
> > on top of latest tip:x86/urgent (12a78d43de76).
> >
> > This version
On Fri, Nov 24, 2017 at 11:02:41PM +0100, Martin Steigerwald wrote:
> I like this.
>
> I bet I may not be able help much further with it other than to possibly
> proofread it tomorrow.
>
> Thank you for considering my suggestion.
Not at all; your feedback has significantly improved this documen
mt9v032_power_on() leaves clk enabled in case of errors,
but it is not expected by its callers.
There is a similar problem in mt9v032_registered().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/i2c/mt9v032.c | 21 +
On Nov 24, 2017, at 9:51 AM, Andi Kleen wrote:
>
>> We checked old kernels, and old e2fsprogs, and didn't see any cases
>> where fast (<= 60 chars) symlinks were created using external blocks.
>> It seems that _something_ did create them, and it would be good to
>> figure that out so we can deter
Matthew Wilcox - 24.11.17, 22:18:
> On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote:
> > > The XArray is an abstract data type which behaves like an infinitely
> > > large array of pointers. The index into the array is an unsigned long.
> > > A freshly-initialised XArray contain
* Ingo Molnar wrote:
> > That's weird and definitely not intentional.
>
> Btw., can you reproduce the crash by disabling CONFIG_DEBUG_ENTRY with
> CONFIG_KAISER=y?
I've attached a .config that triggers the crash on bootup on just about any
hardware, before even hitting user-space. So I think
* Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 12:22 PM, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> >> This is a repost of the latest entry-stack plus Kaiser bits from Andy
> >> Lutomirski
> >> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123
> >> version),
>
There is currently very little documentation in the kernel on maintainer
level tasks. In particular there are no documents on creating pull
requests to submit to Linus.
Quoting Greg Kroah-Hartman on LKML:
Anyway, this actually came up at the kernel summit / maintainer
meeting a few weeks
On Fri, Nov 24, 2017 at 04:02:09PM +0300, Dan Carpenter wrote:
> On Fri, Nov 24, 2017 at 09:20:20AM +1100, Tobin C. Harding wrote:
> > My current favourite review of all time was done by you on a what was
> > at the time a pretty hard patch for me. It was
> >
> > Nope
> >
>
> Wow... I know
Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 24 Nov 2017 22:22:06 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/video/fbdev/stifb.c
On Fri, Nov 24, 2017 at 11:02:49AM -0800, Dan Williams wrote:
> On Tue, Nov 21, 2017 at 2:39 PM, Tobin C. Harding wrote:
> > There is currently very little documentation in the kernel on maintainer
> > level tasks. In particular there are no documents on creating pull
> > requests to submit to Lin
> -Original Message-
> From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
> Sent: Friday, November 24, 2017 1:09 PM
> To: Davidlohr Bueso
> Cc: James Yang ; Kim Phillips ;
> Peter Zijlstra ; Ingo Molnar ;
> Alexander Shishkin ; Jiri Olsa
> ; Namhyung Kim ; Thomas Gleixner
> ; Darren H
From: Markus Elfring
Date: Fri, 24 Nov 2017 22:22:06 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/stifb.c | 4 +---
1 file changed, 1 insertion(+),
Eric Biggers wrote:
> if (dest_keyring) {
> - construct_get_dest_keyring(&dest_keyring);
Actually, I think I have the order of these lines inverted.
construct_get_dest_keyring() can actually return without setting dest_keyring
to anything. This didn't used to b
On 11/24/2017 08:36 AM, Vivien Didelot wrote:
> Setting the refcount to 0 when allocating a tree to match the number of
> switch devices it holds may cause an 'increment on 0; use-after-free',
> if CONFIG_REFCOUNT_FULL is enabled.
>
> To fix this, do not decrement the refcount of a newly allocat
Eric Biggers wrote:
> > > - construct_get_dest_keyring(&dest_keyring);
> >
> > This will break. construct_get_dest_keyring() does other things than just
> > getting a ref on whatever dest_keyring points to.
> >
>
> Not if dest_keyring is non-NULL (i.e. explicitly specified), w
On Fri, Nov 24, 2017 at 07:01:31PM +0100, Martin Steigerwald wrote:
> > The XArray is an abstract data type which behaves like an infinitely
> > large array of pointers. The index into the array is an unsigned long.
> > A freshly-initialised XArray contains a NULL pointer at every index.
>
> Yes,
On Fri, Nov 24, 2017 at 12:22 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> This is a repost of the latest entry-stack plus Kaiser bits from Andy
>> Lutomirski
>> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
>> on top of latest tip:x86/urgent (12a78d43de76)
From: Markus Elfring
Date: Fri, 24 Nov 2017 21:36:39 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement in the affected functions.
Signed-off-by: Markus Elfring
---
driver
On Fri, Nov 24, 2017 at 3:34 PM, Souvik Kumar Chakravarty
wrote:
> This patchset fixes https://bugzilla.kernel.org/show_bug.cgi?id=197833, and
> other issues related to telemetry counters. It also cleans up formatting
> and removes redundant code.
>
> It is rebased on top of the TESTING branch.
>
From: Markus Elfring
Date: Fri, 24 Nov 2017 21:30:37 +0100
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was det
From: Markus Elfring
Date: Fri, 24 Nov 2017 21:22:25 +0100
* Return an error code without storing it in an intermediate variable.
* Delete the label "error" and local variable "retval"
which became unnecessary with this refactoring.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/udlf
From: Markus Elfring
Date: Fri, 24 Nov 2017 21:12:54 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/udlfb.c | 8 ++--
1 file changed, 2 insertio
From: Markus Elfring
Date: Fri, 24 Nov 2017 21:45:54 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Delete an error message for a failed memory allocation in two functions
Return an error code only as a constant in dlfb_realloc_fr
On Fri, Nov 24, 2017 at 03:52:05PM +, David Howells wrote:
> Eric Biggers wrote:
>
> > - construct_get_dest_keyring(&dest_keyring);
>
> This will break. construct_get_dest_keyring() does other things than just
> getting a ref on whatever dest_keyring points to.
>
Not if
Dear RT folks!
I'm pleased to announce the v4.14.1-rt3 patch set.
Changes since v4.14.1-rt2:
- The "memcontrol Prevent scheduling while atomic in cgroup code"
caused harm in a 4.4-RT kernel. Uppon investigation it turned out
that the patch was no longer required and reverting would av
* Ingo Molnar wrote:
> This is a repost of the latest entry-stack plus Kaiser bits from Andy
> Lutomirski
> (v3 series from today) and Dave Hansen (kaiser-414-tipwip-20171123 version),
> on top of latest tip:x86/urgent (12a78d43de76).
>
> This version is pretty well tested, at least on the usu
From: Rasmus Villemoes
Date: Tue, 21 Nov 2017 01:34:37 +0100
> dev_alloc_name_ns and dev_get_valid_name now do exactly the same
> thing. Let's expose this functionality as dev_alloc_name_ns
> (obviously, a core function like this won't return an invalid
> name...).
>
> Signed-off-by: Rasmus Vill
From: David Howells
Date: Fri, 24 Nov 2017 14:37:39 +
> Is it too late for this to go to Linus in this merge window?
These look predominantly like fixes so I'll pull this in.
Thanks.
On Fri, Nov 24, 2017 at 11:48:49AM -0800, Shakeel Butt wrote:
> Adding on to Martin's questions. Basically what is the motivation
> behind it? It seems like a replacement for radix tree, so, it would be
> good to write why radix tree was not good enough or which use cases
> radix tree could not sol
From: Markus Elfring
Date: Fri, 24 Nov 2017 20:42:08 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/vt8500lcdfb.c | 4 +---
1 file changed, 1 insertio
On Fri, Nov 24, 2017 at 10:01 AM, Martin Steigerwald
wrote:
> Hi Matthew.
>
> Matthew Wilcox - 24.11.17, 18:03:
>> On Fri, Nov 24, 2017 at 05:50:41PM +0100, Martin Steigerwald wrote:
>> > Matthew Wilcox - 24.11.17, 02:16:
>> > > ==
>> > > XArray
>> > > ==
>> > >
>> > > Overview
>> > >
From: Markus Elfring
Date: Fri, 24 Nov 2017 20:22:10 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/wm8505fb.c | 4 +---
1 file changed, 1 insertion(+
On Fri, Nov 24, 2017 at 9:21 AM, Andrey Ryabinin
wrote:
> From: Andy Lutomirski
>
> The cpu_entry_area will contain stacks. Make sure that KASAN has
> appropriate shadow mappings for them.
LGTM. I'll update my tree, and Ingo can pick it up as a replacement
if he wants.
On Fri, Nov 17, 2017 at 01:54:22PM -0800, Darren Hart wrote:
> On Mon, Nov 13, 2017 at 09:45:18PM +0200, Jarkko Sakkinen wrote:
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > MAINTAINERS | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2d3d7
On Fri, Nov 24, 2017 at 10:25 AM, Borislav Petkov wrote:
> On Fri, Nov 24, 2017 at 06:23:40PM +0100, Ingo Molnar wrote:
>> From: Andy Lutomirski
>>
>> When we start using an entry trampoline, a #GP from userspace will
>> be delivered on the entry stack, not on the task stack. Fix the
>> espfix64
On Fri, Nov 24, 2017 at 06:23:42PM +0100, Ingo Molnar wrote:
> From: Andy Lutomirski
>
> By itself, this is useless. It gives us the ability to run some final
> code before exit that cannnot run on the kernel stack. This could
> include a CR3 switch a la KAISER or some kernel stack erasing, for
Em Fri, Nov 24, 2017 at 04:16:52PM +0100, Daniel Borkmann escreveu:
> [ +Yonghong ]
>
> On 11/24/2017 03:47 PM, Arnaldo Carvalho de Melo wrote:
> > FYI, just noticed, recently updated clang to version 6, from its
> > upstream git repo.
>
> Do you recall what was your LLVM version prior to this wh
Em Fri, Nov 24, 2017 at 07:32:49AM -0800, Davidlohr Bueso escreveu:
> On Thu, 23 Nov 2017, Arnaldo Carvalho de Melo wrote:
>
> > Em Thu, Nov 23, 2017 at 12:09:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Wed, Nov 22, 2017 at 06:25:28PM -0600, Kim Phillips escreveu:
> > > > From: James Y
On Tue, Nov 21, 2017 at 2:39 PM, Tobin C. Harding wrote:
> There is currently very little documentation in the kernel on maintainer
> level tasks. In particular there are no documents on creating pull
> requests to submit to Linus.
>
> Quoting Greg Kroah-Hartman on LKML:
>
> Anyway, this actua
On Fri, Nov 24, 2017 at 06:23:41PM +0100, Ingo Molnar wrote:
> From: Andy Lutomirski
>
> Historically, IDT entries from usermode have always gone directly
> to the running task's kernel stack. Rearrange it so that we enter on
> a percpu trampoline stack and then manually switch to the task's sta
On Fri, 2017-11-24 at 11:43 -0700, David Ahern wrote:
> On 11/24/17 11:32 AM, Eric Dumazet wrote:
> > On Fri, 2017-11-24 at 10:14 -0700, David Ahern wrote:
> > > On 11/22/17 5:30 PM, Solio Sarabia wrote:
> > > > The netdevice gso_max_size is exposed to allow users fine-
> > > > control
> > > > on
>
On Fri, 24 Nov 2017, Ingo Molnar wrote:
> * Mikulas Patocka wrote:
>
> > A small patch for schedule(), so that the code goes straght in the common
> > case.
> >
> > Signed-off-by: Mikulas Patocka
> >
> > ---
> > include/linux/blkdev.h |2 +-
> > kernel/sched/core.c|2 +-
> > 2
On Fri, 2017-11-24 at 11:26 +0100, Uladzislau Rezki wrote:
>
> I guess there is misunderstanding here. The main goal is not to cover
> pinned case, for sure. I was thinking more about below points:
>
> - Extend a claim_wake_up logic for making an ILB/NO_HZ decision more
> predictable (that is g
On 11/24/17 11:32 AM, Eric Dumazet wrote:
> On Fri, 2017-11-24 at 10:14 -0700, David Ahern wrote:
>> On 11/22/17 5:30 PM, Solio Sarabia wrote:
>>> The netdevice gso_max_size is exposed to allow users fine-control
>>> on
>>> systems with multiple NICs with different GSO buffer sizes, and
>>> where
>
On Fri, 2017-11-24 at 10:14 -0700, David Ahern wrote:
> On 11/22/17 5:30 PM, Solio Sarabia wrote:
> > The netdevice gso_max_size is exposed to allow users fine-control
> > on
> > systems with multiple NICs with different GSO buffer sizes, and
> > where
> > the virtual devices like bridge and veth,
On Fri, Nov 24, 2017 at 06:23:40PM +0100, Ingo Molnar wrote:
> From: Andy Lutomirski
>
> When we start using an entry trampoline, a #GP from userspace will
> be delivered on the entry stack, not on the task stack. Fix the
> espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than
> ass
On Fri 24-11-17 15:54:59, Andrea Reale wrote:
> On Fri 24 Nov 2017, 16:43, Michal Hocko wrote:
> > On Fri 24-11-17 14:49:17, Andrea Reale wrote:
> > > Hi Rafael,
> > >
> > > On Fri 24 Nov 2017, 15:39, Rafael J. Wysocki wrote:
> > > > On Fri, Nov 24, 2017 at 11:22 AM, Andrea Reale
> > > > wrote:
On Fri, Nov 24, 2017 at 06:10:56PM +, Mark Rutland wrote:
> On Wed, Nov 15, 2017 at 06:00:20PM +, Will Deacon wrote:
> > On Mon, Oct 30, 2017 at 04:23:15PM +, Mark Rutland wrote:
> > > As a heads-up, while fuzzing arm64 v4.14-rc{4,7} with Syzkaller, I hit a
> > > KASAN splat in event_sc
On Wed, Nov 15, 2017 at 06:00:20PM +, Will Deacon wrote:
> On Mon, Oct 30, 2017 at 04:23:15PM +, Mark Rutland wrote:
> > As a heads-up, while fuzzing arm64 v4.14-rc{4,7} with Syzkaller, I hit a
> > KASAN splat in event_sched_out():
> >
> > [ 133.225742]
> > ==
Hi Matthew.
Matthew Wilcox - 24.11.17, 18:03:
> On Fri, Nov 24, 2017 at 05:50:41PM +0100, Martin Steigerwald wrote:
> > Matthew Wilcox - 24.11.17, 02:16:
> > > ==
> > > XArray
> > > ==
> > >
> > > Overview
> > >
> > >
> > > The XArray is an array of ULONG_MAX entries. Each entr
From: Masami Hiramatsu
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:8103dd2c
Warning: 8103dd82: f6 09 d8 testb $0xd8,(%rcx)
Warning: objdump says 3 bytes, but insn_get_length() says 2
Warning: decoded and c
From: Andy Lutomirski
get_stack_info() doesn't currently know about the SYSENTER stack, so
unwinding will fail if we entered the kernel on the SYSENTER stack
and haven't fully switched off. Teach get_stack_info() about the
SYSENTER stack.
With future patches applied that run part of the entry c
From: Andy Lutomirski
We currently have CPU 0's GDT at the top of the GDT range and
higher-numbered CPUs at lower addresses. This happens because the
fixmap is upside down (index 0 is the top of the fixmap).
Flip it so that GDTs are in ascending order by virtual address.
This will simplify a fu
On Mon, 2017-11-20 at 14:02 +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers infinite stream of the following
> output
> on console. The program is unkillable and this effectively brings the
> machine down:
>
>
> ** 16 printk messages dropped ** [12875.022917] xs_tcp_setup
1 - 100 of 537 matches
Mail list logo
