strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
On Sun, Jan 31, 2021 at 2:40 AM Thomas Gleixner wrote:
>
> A single fix for the single step reporting regression caused by getting the
> condition wrong when moving SYSCALL_EMU away from TIF flags.
Manual pr-tracker-bot says thanks,
Linus
Am 31.01.21 um 18:39 schrieb Joe Perches:
On Wed, 2021-02-03 at 14:26 +0100, Christian König wrote:
Am 30.01.21 um 19:47 schrieb Joe Perches:
On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
Use semicolons and braces.
Ping?
Signed-off-by: Joe Perches
Reviewed-by: Christian König
Do
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
On Sun, Jan 31, 2021 at 1:43 AM Pavel Machek wrote:
>
> This pull is due to "leds: trigger: fix potential deadlock with
> libata" -- people find the warn annoying. It also contains new driver
> (still should be okay late in -rcs, right?) and two trivial fixes.
I've pulled it, but please don't add
The recent rework of probe_kernel_read() and its conversion to
get_kernel_nofault() inadvertently broke is_prefetch(). We were using
probe_kernel_read() as a sloppy "read user or kernel memory" helper, but it
doens't do that any more. The new get_kernel_nofault() reads *kernel*
memory only, which
The name no_context() has never been very clear. It's only called for
faults from kernel mode, so rename it and change the no-longer-useful
user_mode(regs) check to a WARN_ON_ONCE.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 28 ++---
bad_area() and its relatives are called from many places in fault.c, and
exactly one of them wants the F00F workaround.
__bad_area_nosemaphore() no longer contains any kernel fault code, which
prepares for further cleanups.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
The BPF team reported a warning in the x86 page fault code. This caused me
to read said code, and it was quite tangled. This series attempts to
mostly disentangle it and fixes a whole bunch of corner cases. In my
opinion, the control flow and the semantics of the various page fault
functions are
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6642d600b541b81931fb1ab0c041b0d68f77be7e
commit: 0060ef3b4e6dd1410da164d48a595eadb2fb02f7 mm: support THPs in
zero_user_segments
date: 7 weeks ago
config: powerpc64-randconfig-r026-20210131 (attached as
If fault_signal_pending() returns true, then the core mm has unlocked the
mm for us. Add a comment to help future readers of this code.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --g
Not all callers of no_context() want to run exception fixups.
Separate the OOPS code out from the fixup code in no_context().
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 116 +++-
1 file changed, 62 inserti
A SMAP-violating kernel access is not a recoverable condition. Imagine
kernel code that, outside of a uaccess region, dereferences a pointer to
the user range by accident. If SMAP is on, this will reliably generate
as an intentional user access. This makes it easy for bugs to be
overlooked if co
On Sun, Jan 31, 2021 at 2:40 AM Thomas Gleixner wrote:
>
> please pull the latest timers/urgent branch from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> timers-urgent-2021-01-31
Manual pr-tracker-bot says thanks again.
Linus
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
On Sat, Jan 9, 2021 at 5:51 AM AngeloGioacchino Del Regno
wrote:
>
> The VCO rate was being miscalculated due to a big overlook during
> the process of porting this driver from downstream to upstream:
> here we are really recalculating the rate of the VCO by reading
> the appropriate registers and
On Sun, Jan 31, 2021 at 11:35 AM wrote:
>
> The pull request you sent on Sun, 31 Jan 2021 10:42:55 +0100:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/
> > for-rc-5.11
>
> has been merged into torvalds/linux.git:
Oh, look, one out of three (so far) did get a timely au
On Sun, Jan 31, 2021 at 2:57 AM Borislav Petkov wrote:
>
> A single fix for objtool to generate proper unwind info for newer
> toolchains which do not generate section symbols anymore. And a cleanup
> ontop.
Manual pr-tracker-bot says thanks.
Oh, and I'm about to merge your EFI pull request too,
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
Andy Shevchenko writes:
> On Thursday, January 28, 2021, Mans Rullgard wrote:
>
>> On systems that do not have the traditional PC ISA serial ports, the
>> 8250 driver still creates non-functional device nodes. This change
>> makes only ports that actually exist (PCI, DT, ...) get device nodes.
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>
> From: Nadav Amit
>
> x86 currently has a TLB-generation tracking logic that can be used by
> additional architectures (as long as they implement some additional
> logic).
>
> Extract the relevant pieces of code from x86 to general TLB code. Th
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
On Sat, Jan 30, 2021 at 6:25 PM Marek Marczykowski-Górecki
wrote:
>
> On Fri, Jan 29, 2021 at 03:16:52PM +0100, Jürgen Groß wrote:
> > On 29.01.21 15:13, Michael Labriola wrote:
> > > On Fri, Jan 29, 2021 at 12:26 AM Jürgen Groß wrote:
> > > > If the buggy patch has been put into stable this Fixe
On 08/01/2021 15:39, Milan Broz wrote:
> On 08/01/2021 14:41, Michal Hocko wrote:
>> On Wed 06-01-21 16:20:15, Milan Broz wrote:
>>> Hi,
>>>
>>> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code
>>> and someone tried to use it with hardened memory allocator library.
>>>
>>
On Sun, Jan 31, 2021 at 4:06 AM Michael Ellerman wrote:
>
> Please pull another powerpc fix for 5.11:
Manual pr-tracker-bot says thanks,
Linus
Am 30.01.21 um 19:47 schrieb Joe Perches:
On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
Use semicolons and braces.
Ping?
Signed-off-by: Joe Perches
Reviewed-by: Christian König
Do you have commit rights to drm-misc-next?
---
drivers/dma-buf/st-dma-fence.c | 7 +--
1 fi
On 1/28/2021 11:02 PM, Alex Williamson wrote:
On Thu, 28 Jan 2021 17:29:30 +0100
Cornelia Huck wrote:
On Tue, 26 Jan 2021 15:27:43 +0200
Max Gurtovoy wrote:
On 1/26/2021 5:34 AM, Alex Williamson wrote:
On Mon, 25 Jan 2021 20:45:22 -0400
Jason Gunthorpe wrote:
On Mon, Jan 25, 2021 a
On Wed, 2021-02-03 at 14:26 +0100, Christian König wrote:
> Am 30.01.21 um 19:47 schrieb Joe Perches:
> > On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
> > > Use semicolons and braces.
> > Ping?
> > > Signed-off-by: Joe Perches
> Reviewed-by: Christian König
>
> Do you have commit rights
[ I'm checking lkml for at least some of the emails that I'm cc'd on ]
On Sun, Jan 31, 2021 at 2:59 AM Alexander Popov wrote:
>
> There are multiple similar bugs implicitly introduced by the
> commit [...]
Note: this got eaten or delayed by the mailing list issues that seem
to be plaguing lkml -
On Sun, 2021-01-31 at 15:14 +0100, Jan Lübbe wrote:
> On Sun, 2021-01-31 at 07:09 -0500, Mimi Zohar wrote:
> > On Sat, 2021-01-30 at 19:53 +0200, Jarkko Sakkinen wrote:
> > > On Thu, 2021-01-28 at 18:31 +0100, Ahmad Fatoum wrote:
> > > > Hello,
> > > >
> > > > I've been looking into how a migratio
On Sun, Jan 31, 2021 at 3:40 AM Wolfram Sang wrote:
>
> one I2C driver update this time.
Pulled (manual notification because the automation seems very flaky).
Linus
The pull request you sent on Sun, 31 Jan 2021 10:42:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/
> for-rc-5.11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/29bd2d2100dcd98455c5f2dff391a88c5b44a6b2
Thank you!
--
Deet-doot-dot, I
A netdev xmit function should return NETDEV_TX_OK or NETDEV_TX_BUSY.
Signed-off-by: Martin Kaiser
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
strlcpy is marked as deprecated in Documentation/process/deprecated.rst,
and there is no functional difference when the caller expects truncation
(when not checking the return value). strscpy is relatively better as it
also avoids scanning the whole source string.
This silences the related checkpa
Am 31.01.21 um 02:03 schrieb David Rientjes:
On Sat, 30 Jan 2021, David Rientjes wrote:
On Sun, 31 Jan 2021, Mikhail Gavrilov wrote:
The 5.11-rc5 (git 76c057c84d28) brought a new issue.
Now the kernel log is flooded with the message "page allocation failure".
Trace:
msedge:cs0: page allocati
On Sat, Jan 30, 2021 at 05:30:14PM +, Timon Baetz wrote:
> Get regulator from parent device's node and extcon by name.
>
> Signed-off-by: Timon Baetz
> ---
> drivers/power/supply/max8997_charger.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/
On Fri, Jan 29, 2021 at 11:49:45AM +0800, Jason Wang wrote:
>
> On 2021/1/28 下午9:41, Eli Cohen wrote:
> > When a change of memory map occurs, the hardware resources are destroyed
> > and then re-created again with the new memory map. In such case, we need
> > to restore the hardware available and
I didn't understand Kyle's point at first, so I asked for clarification
and will record my understanding below for posterity.
ARCH_SYSCALL_EXIT_WORK was a flag that was checked by various functions
(via SYSCALL_EXIT_WORK) before calling syscall_exit_work, which is what
reports single steps. This
On Sun, Jan 31, 2021 at 8:59 AM Trond Myklebust wrote:
>
> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.11-3
Merged. However, it looks like you won't get a pr-tracker-bot reply
because I'm not seeing this email on lore.
So I'm doing these manual replies for now, it loo
On Fri, Dec 18, 2020 at 2:27 AM Kalyan Thota wrote:
>
> Set the flag vblank_disable_immediate = true to turn off vblank irqs
> immediately as soon as drm_vblank_put is requested so that there are
> no irqs triggered during idle state. This will reduce cpu wakeups
> and help in power saving.
>
> To
On Sun, Jan 31, 2021 at 10:54 AM Yuxuan Shui wrote:
>
> But renaming the definition in x86 is not enough, as TIF_SINGLESTEP is
> set in current_thread_info()->flags, and the same commit has removed the
> code that checks those flags. We have to also migrate TIF_SINGLESTEP from
> thread info flags
Linus Torvalds writes:
> On Sun, Jan 31, 2021 at 10:54 AM Yuxuan Shui wrote:
>>
>> But renaming the definition in x86 is not enough, as TIF_SINGLESTEP is
>> set in current_thread_info()->flags, and the same commit has removed the
>> code that checks those flags. We have to also migrate TIF_SINGL
On Fri, Jan 29, 2021 at 02:09:05PM -0800, Linus Torvalds wrote:
> On Fri, Jan 29, 2021 at 11:03 AM Catalin Marinas
> wrote:
> >
> > arm64 fixes:
> >
> > - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses.
>
> That's a really odd fix.
>
> It went from an incorrect bitwise oper
"Serge E. Hallyn" writes:
> On Fri, Jan 29, 2021 at 04:55:29PM -0600, Eric W. Biederman wrote:
>> "Serge E. Hallyn" writes:
>>
>> > On Thu, Jan 28, 2021 at 02:19:13PM -0600, Eric W. Biederman wrote:
>> >> "Serge E. Hallyn" writes:
>> >>
>> >> > On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W
Hi Jyoti
a few remarks down below, but beside those, while testing this series on
a JUNO board (so lacking any GYRO/ACCEL sensor, a limited test case for
now) I spotted that you missed in this series to add a matching device
to the SCMI core. (as spotted by Jonathan too in his v4 review)
In other
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote:
>
> From: Nadav Amit
>
> To detect deferred TLB flushes in fine granularity, we need to keep
> track on the completed TLB flush generation for each mm.
>
> Add logic to track for each mm the tlb_gen_completed, which tracks the
> completed TLB gene
On Sun, 2021-01-31 at 11:26 +, Jonathan Cameron wrote:
> On Fri, 29 Jan 2021 00:35:49 +0800
> "Ye, Xiang" wrote:
>
> > Hi Srinivas andd Jonathan
> >
> > Thanks for the review.
> >
> > On Sun, Jan 24, 2021 at 08:20:12AM -0800, Srinivas Pandruvada
> > wrote:
> > > On Sun, 2021-01-24 at 13:14
Hi
a clarification down below regarding something I pointed out in the
other thread (just to be sure I have not pointed out something
plain wrong :D)
Thanks
Cristian
On Sun, Jan 31, 2021 at 01:11:41PM +, Jonathan Cameron wrote:
> On Fri, 29 Jan 2021 22:18:18 +
> Jyoti Bhayana wrote:
>
From: Dmitrii Wolf
Fixed a coding style issues.
Signed-off-by: Dmitrii Wolf
---
drivers/staging/wimax/i2400m/debugfs.c | 2 +-
drivers/staging/wimax/i2400m/netdev.c | 2 +-
drivers/staging/wimax/i2400m/rx.c | 23 +++
drivers/staging/wimax/i2400m/usb.c | 2 +-
4
Remove a lot of boilerplate code. Also address boot issues on imx25 with
fw_devlink=on that were reported by Martin.
Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
Reported-by: Martin Kaiser
Signed-off-by: Saravana Kannan
---
I've compile tested this for imx25 and imx27. But
Hi,
On 1/31/21 3:04 PM, Limonciello, Mario wrote:
>
>
>> -Original Message-
>> From: Hans de Goede
>> Sent: Saturday, January 30, 2021 15:44
>> To: Limonciello, Mario; Mark Gross
>> Cc: LKML; platform-driver-...@vger.kernel.org
>> Subject: Re: [PATCH] platform/x86: dell-wmi-sysman: fix
We can drop an indentation level and remove the last user_mode(regs) == true
caller of no_context() by directly OOPSing for implicit kernel faults from
usermode.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 59 -
On Sun, Jan 31, 2021 at 8:38 AM Martin Kaiser wrote:
>
> Dear all,
>
> Thus wrote Saravana Kannan (sarava...@google.com):
>
> > Sending again because I messed up the To/Cc for the coverletter.
>
> > This series combines two patches [1] [2] that'd conflict.
>
> > Greg,
>
> > Can you please pull thi
On Sun, Jan 31, 2021 at 12:20 PM Gabriel Krisman Bertazi
wrote:
>
>
> I think we should migrate TIF_SINGLESTEP to a SYSCALL_WORK flag as that
> is just a simple refactor.
That makes no sense at all to me.
A single-step has absolutely nothing to do with system calls, and it's
also not what any ot
On Sun, Jan 31, 2021 at 09:22:31AM +0100, Jan Henrik Weinstock wrote:
> On 31/01/2021 00:03, Stafford Horne wrote:
>
> > This looks good, one small comment below. Can you send the next patch as a
> > v2?
> >
> > Using 'git format-patch -v2 ...'
>
> Sorry, was not aware of that, will do better
On Sat, Jan 30, 2021 at 9:39 AM Dmitry Osipenko wrote:
>
> 22.01.2021 22:35, Saravana Kannan пишет:
> > There are multiple instances of GPIO device tree nodes of the form:
> >
> > foo {
> > compatible = "acme,foo";
> > ...
> >
> > gpio0: gpio0@ {
> > compati
Btw Kyle, do you have a good simple test-case for this? Clearly this
is some weird special case use, and regular single-stepping works
fine.
Linus
On Fri, Jan 29, 2021 at 8:03 PM Saravana Kannan wrote:
>
> This patch series solves two general issues with fw_devlink=on
>
> Patch 1/2 addresses the issue of firmware nodes that look like they'll
> have struct devices created for them, but will never actually have
> struct devices added for them.
On Sun, Jan 31, 2021 at 12:04 AM Mike Rapoport wrote:
>
> >
> > That's *particularly* true when the very line above it did a
> > "memblock_reserve()" of the exact same range that the memblock_add()
> > "adds".
>
> The most correct thing to do would have been to
>
> memblock_add(0, end_of_f
Convert the RN5T618 binding to DT schema format. Also
clearly state which regulators are available.
Signed-off-by: Andreas Kemnade
Reviewed-by: Rob Herring
---
https://lore.kernel.org/lkml/cal_jsqjwt91+azwaweuvjobqgsyw6gbhqmohwu_t5qzabxx...@mail.gmail.com/
Changes in v2:
- drop irq description
Things look a little calmer than last week, and over-all very average
for rc6. So - like always this late in the release schedule - I'd
certainly have liked things to be even calmer, but nothing here really
stands out.
The diffstat is quite flat, meaning lots of small fixes, with the
exception of
> On Jan 31, 2021, at 1:30 PM, Linus Torvalds
> wrote:
>
> Btw Kyle, do you have a good simple test-case for this? Clearly this
> is some weird special case use, and regular single-stepping works
> fine.
>
>
Indeed, and I have tests for this.
TBH, the TIF_SINGLESTEP code makes no sense,
On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski wrote:
> Indeed, and I have tests for this.
Do you mean you already have a test case or that you would like a
minimized test case?
- Kyle
If we get a SMEP violation or a fault that would have been a SMEP
violation if we had SMEP, we shouldn't run fixups. Just OOPS.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ar
In general, page fault errors for WRUSS should be just like get_user(),
etc. Fix three bugs in this area:
We have a comment that says that, if we can't handle a page fault on a user
address due to OOM, we will skip the OOM-kill-and-retry logic. The code
checked kernel *privilege*, not kernel mod
> On Jan 31, 2021, at 2:08 PM, Kyle Huey wrote:
>
> On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski wrote:
>> Indeed, and I have tests for this.
>
> Do you mean you already have a test case or that you would like a
> minimized test case?
A smallish test that we could stick in selftests wou
On Sun, Jan 31, 2021 at 09:13:15AM +0800, DENG Qingfang wrote:
> This bug is exposed when I try your patch series on kernel 5.4
> https://lore.kernel.org/netdev/20210106095136.224739-1-olte...@gmail.com/
> https://lore.kernel.org/netdev/20210116012515.3152-1-tob...@waldekranz.com/
>
> Without this
On Sun, Jan 31, 2021 at 2:20 PM Andy Lutomirski wrote:
>
>
>
> > On Jan 31, 2021, at 2:08 PM, Kyle Huey wrote:
> >
> > On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski
> > wrote:
> >> Indeed, and I have tests for this.
> >
> > Do you mean you already have a test case or that you would like a
>
On Thu, Jan 28, 2021 at 09:34:17AM +0800, Jin Yao wrote:
> Uncore becomes die-scope on Xeon Cascade Lake-AP and perf has supported
> --per-die aggregation yet.
>
> One issue is found in check_per_pkg() for uncore events running on
> AP system. On cascade Lake-AP, we have:
>
> S0-D0
> S0-D1
> S1-D
On Fri, Jan 29, 2021 at 02:48:58PM +0900, Namhyung Kim wrote:
> Hello,
>
> This is to optimize the event synthesis during perf record.
>
> The first patch is to reduce memory usage when many threads are used.
> The second is to avoid unncessary syscalls for kernel threads. And
> the last one is
On Fri, Jan 29, 2021 at 02:49:00PM +0900, Namhyung Kim wrote:
> To synthesize information to resolve sample IPs, it needs to scan task
> and mmap info from the /proc filesystem. For each process, it
> opens (and reads) status and maps file respectively. But as kernel
> threads don't have memory m
On Wed, Jan 27, 2021 at 05:24:40PM +0200, Iskren Chernev wrote:
> Before the offending commit in msm_atomic_commit_tail wait_flush was
> called once per frame, after the commit was submitted. After it
> wait_flush is also called at the beginning to ensure previous
> potentially async commits are do
On Sun, Jan 31, 2021 at 2:20 PM Andy Lutomirski wrote:
>
> A smallish test that we could stick in selftests would be great if that’s
> straightforward.
Side note: it would be good to have a test-case for the interaction
with the "block step" code too.
I hate our name for it ("block step"?), but
Hi Arnd,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: ac8c6edd20bcb965b22ceb36752499b3d5cf5dd4
commit: 71b9114d2c13a648fbe6523dd859e611c316ad90 ARM: s3c: move into a common
directory
date: 5 months ago
config
On Fri, Jan 29, 2021 at 02:48:59PM +0900, Namhyung Kim wrote:
> To save memory usage, it needs to reduce number of entries in the proc
> filesystem. It's using /proc//task directory to traverse threads
> in the process and then kernel creates /proc//task/ entries.
>
> After that it checks the thr
Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP
kthread (rcuog) to be serviced.
Unfortunately the call to rcu_user_enter() is already past the last
rescheduling opportunity before we resume to userspace or to guest mode.
We may escape there with the woken task ignored.
The u
Deferred wakeup of rcuog kthreads upon RCU idle mode entry is going to
be handled differently whether initiated by idle, user or guest. Prepare
with pulling that control up to rcu_eqs_enter() callers.
Signed-off-by: Frederic Weisbecker
Cc: Paul E. McKenney
Cc: Rafael J. Wysocki
Cc: Peter Zijlst
So, here is a hopefully improved version with the following changes:
* No more late wake up debugging, objtool should debug that later with
noinstr code calling into the scheduler (Peter suggestion)
* Dropped the double rdp fetch patch, just keep the fix part for now
* Properly protect irq wor
Following the idle loop model, cleanly check for pending rcuog wakeup
before the last rescheduling point on resuming to user mode. This
way we can avoid to do it from rcu_user_enter() with the last resort
self-IPI hack that enforces rescheduling.
Signed-off-by: Frederic Weisbecker
Cc: Peter Zijls
Hi Iskren,
On Mittwoch, 27. Jänner 2021 16:24:40 CET Iskren Chernev wrote:
> Before the offending commit in msm_atomic_commit_tail wait_flush was
> called once per frame, after the commit was submitted. After it
> wait_flush is also called at the beginning to ensure previous
> potentially async co
Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP
kthread (rcuog) to be serviced.
Usually a local wake up happening while running the idle task is handled
in one of the need_resched() checks carefully placed within the idle
loop that can break to the scheduler.
Unfortunately t
Following the idle loop model, cleanly check for pending rcuog wakeup
before the last rescheduling point upon resuming to guest mode. This
way we can avoid to do it from rcu_user_enter() with the last resort
self-IPI hack that enforces rescheduling.
Suggested-by: Peter Zijlstra
Signed-off-by: Fre
On Sun, 31 Jan 2021 at 19:55, Catalin Marinas wrote:
>
> On Fri, Jan 29, 2021 at 02:09:05PM -0800, Linus Torvalds wrote:
> > On Fri, Jan 29, 2021 at 11:03 AM Catalin Marinas
> > wrote:
> > >
> > > arm64 fixes:
> > >
> > > - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses.
> >
On Sun, Jan 31, 2021 at 2:27 PM Kyle Huey wrote:
>
> On Sun, Jan 31, 2021 at 2:20 PM Andy Lutomirski wrote:
> >
> >
> >
> > > On Jan 31, 2021, at 2:08 PM, Kyle Huey wrote:
> > >
> > > On Sun, Jan 31, 2021 at 2:04 PM Andy Lutomirski
> > > wrote:
> > >> Indeed, and I have tests for this.
> > >
Hi all,
On Mon, 25 Jan 2021 16:23:36 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the pidfd tree got a conflict in:
>
> fs/ecryptfs/inode.c
>
> between commit:
>
> 176cfe865da6 ("ecryptfs: fix uid translation for setxattr on
> security.capability")
>
> from the overlayf
Right now we treat the case of the kernel trying to execute from user
memory more or less just like the kernel getting a page fault on a user
access. In the failure path, we check for erratum #93, try to otherwise
fix up the error, and then oops.
If we manage to jump to the user address space, wi
mm_fault_error() is logically just the end of do_user_addr_fault().
Combine the functions. This makes the code easier to read.
Most of the churn here is from renaming hw_error_code to error_code in
do_user_addr_fault().
This makes no difference at all to the generated code (objdump -dr) as
compa
On 1/29/21 2:35 PM, Yu, Yu-cheng wrote:
>> Andy Cooper just mentioned on IRC about this nugget in the spec:
>>
>> XRSTORS on CET state will do reserved bit and canonicality
>> checks on the state in similar manner as done by the WRMSR to
>> these state elements.
>>
>> We're using copy_k
Correct compile issue if CONFIG_TTY is not set by
only adding ttyVK devices if CONFIG_BCM_VK_TTY is set.
Reported-by: Randy Dunlap
Signed-off-by: Scott Branden
---
Changes since v2:
- add CONFIG_BCM_VK_TTY
- add function and stub for bcm_vk_tty_set_irq_enabled
Changes since v1:
- add function s
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.
Signed-off-by: Stefan Berger
Cc: David Howells
Cc: keyri...@vger.kernel.org
---
crypto/asymmetric_keys/x509_cert_parser.c |
This patch adds support for parsing of x509 certificates that contain
ECDSA keys, such as NIST P256, that have been signed by a CA using any
of the current SHA hash algorithms.
Signed-off-by: Stefan Berger
Cc: David Howells
Cc: keyri...@vger.kernel.org
---
crypto/asymmetric_keys/public_key.c
This series of patches adds support for x509 certificates signed by a CA
that uses NIST p256 or p192 keys for signing. It also adds support for
certificates where the public key is a NIST p256 or p192 key. The math
for ECDSA signature verification is also added.
Since self-signed certificates are
Add support for IMA signature verification for EC keys. Since SHA type
of hashes can be used by RSA and ECDSA signature schemes we need to
look at the key and derive from the key which signature scheme to use.
Since this can be applied to all types of keys, we change the selection
of the encoding t
201 - 300 of 540 matches
Mail list logo
