On 9/23/19 1:52 PM, Randy Dunlap wrote:
On 9/23/19 12:43 PM, Ingo Molnar wrote:
* Shuah Khan wrote:
I am exploring the possibility to move selftests to a better location
or add a git alias so it can be found easily. With the addition of
KUnit and future work that is planned to connect
On 9/23/19 1:23 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>>
>> CPU 0CPU 1
>> -- --
>>READ(pte) (re-ordered at run time)
>>
Hello Christian,
On 9/23/19 4:29 PM, Christian Brauner wrote:
> On Mon, Sep 23, 2019 at 11:12:00AM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello Christian and all,
>>
>> Below, I have the rendered version of the current draft of
>> the pidfd_send_signal(2) manual page that I have written.
>>
On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>
> CPU 0CPU 1
> -- --
>READ(pte) (re-ordered at run time)
>atomic_inc(val) (no run-time memory barrier!)
>
On Mon, Sep 23, 2019 at 03:05:14PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 11:57:57AM +0200, Paolo Bonzini wrote:
> > On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> > > +#ifdef CONFIG_RETPOLINE
> > > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > > + return
Hello Daniel,
Than you for reviewing the page!
On 9/23/19 1:26 PM, Daniel Colascione wrote:
> On Mon, Sep 23, 2019 at 3:53 AM Florian Weimer wrote:
>>
>> * Michael Kerrisk:
>>
>>> SYNOPSIS
>>>int pidfd_open(pid_t pid, unsigned int flags);
>>
>> Should this mention for pid_t?
>>
>>>
Hello Christian,
On 9/23/19 4:47 PM, Christian Brauner wrote:
> On Mon, Sep 23, 2019 at 12:53:09PM +0200, Florian Weimer wrote:
>> * Michael Kerrisk:
>>
>>> SYNOPSIS
>>>int pidfd_open(pid_t pid, unsigned int flags);
>>
>> Should this mention for pid_t?
>>
>>> ERRORS
>>>EINVAL
Hello Christian,
On 9/23/19 4:38 PM, Christian Brauner wrote:
> On Mon, Sep 23, 2019 at 11:11:53AM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello Christian and all,
>>
>> Below, I have the rendered version of the current draft of
>> the pidfd_open(2) manual page that I have written.
>> The
On Mon, 23 Sep 2019, Borislav Petkov wrote:
> From: Borislav Petkov
>
> db47d5f85646 ("x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR
> NMI")
>
> forgot to remove it. Drop it.
>
> Signed-off-by: Borislav Petkov
Reviewed-by: Thomas Gleixner
Hello Florian,
Thanks for taking a look at this page.
On 9/23/19 12:53 PM, Florian Weimer wrote:
> * Michael Kerrisk:
>
>> SYNOPSIS
>>int pidfd_open(pid_t pid, unsigned int flags);
>
> Should this mention for pid_t?
Seems reasonable. I added this.
>> ERRORS
>>EINVAL flags is
On 23/09/2019 11:20:42-0600, Nick Crews wrote:
> > This is coming from struct tm, it is part of C89 but I think I was not
> > born when this decision was made. man rtc properly reports that those
> > fields are unused and no userspace tools are actually making use of
> > them. Nobody cares about
On Mon, 2019-09-23 at 12:08 -0700, Ira Weiny wrote:
> Since the last RFC patch set[1] much of the discussion of supporting RDMA with
> FS DAX has been around the semantics of the lease mechanism.[2] Within that
> thread it was suggested I try and write some documentation and/or tests for
> the
>
On Sun, Sep 22, 2019 at 11:32 PM Hui Zhu wrote:
>
> This is the third version of this patch. The first and second version
> is in [1] and [2].
> This verion is updated according to the comments from Randy Dunlap
> in [3].
>
> Currently, I use a VM that has 2 CPUs, 4G memory and 4G swap file.
> I
Hello Linus
Thank for the instruction. I think this is correct.
I have four patches for v5.4. Nothing is major. All but one are in
response to mechanically detected potential issues. The remaining
patch cleans up kernel-doc notations.
The following changes since commit
* Greg KH wrote:
> On Sun, Sep 22, 2019 at 01:25:55PM +0200, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> > > On Fri, Sep 20, 2019 at 9:35 AM Brendan Higgins
> > > wrote:
> > > >
> > > > Sorry about that. I am surprised that none of the other reviewers
> > > > brought this up.
On 2019-09-23, He Zhe wrote:
> When users read the buffer from start, there is no need to return -EPIPE
> since the possible overflows will not affect the output.
>
[..]
> - if (user->seq < log_first_seq) {
> + if (user->seq == 0) {
> + user->seq =
On 9/23/19 12:43 PM, Ingo Molnar wrote:
>
> * Shuah Khan wrote:
>
>> I am exploring the possibility to move selftests to a better location
>> or add a git alias so it can be found easily. With the addition of
>> KUnit and future work that is planned to connect kselftest and KUnit,
>> it
On Wed, 18 Sep 2019, Balasubramani Vivekanandan wrote:
>
> When there are no more cpus subscribed to broadcast, the timer callback
> might not set the expiry time for hrtimer. Therefore the callback timer
> function is modified to set the state of broadcast clock to
>
On 9/23/19 1:45 PM, Matthew Wilcox wrote:
> On Mon, Sep 23, 2019 at 01:38:23PM -0600, Jens Axboe wrote:
>> On 9/23/19 5:19 AM, Matthew Wilcox wrote:
>>>
>>> Ping Jens?
>>>
>>> On Wed, Sep 18, 2019 at 08:49:49PM -0700, Matthew Wilcox wrote:
On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng
The local variable 'bcmd_down' is always set to true almost immediately
before the do-while's condition is checked. As a result, !bcmd_down
evaluates to false which short circuits the logical AND operator meaning
that the second operand is never reached and is therefore dead code.
Hi guys,
I noticed some warning in dmesg on this Laptop.
Fn+right, Fn+left is BrightnessDown/Up and produce the following warning:
acer_wmi: Unknown function number - 4 - 0
The brightness has some other issue on this Laptop but not sure
who to blame on this. Probably amdgpu.?
On Mon, Sep 23, 2019 at 01:38:23PM -0600, Jens Axboe wrote:
> On 9/23/19 5:19 AM, Matthew Wilcox wrote:
> >
> > Ping Jens?
> >
> > On Wed, Sep 18, 2019 at 08:49:49PM -0700, Matthew Wilcox wrote:
> >> On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng wrote:
> >>> On 9/18/19 20:33, Michal Hocko
* Shuah Khan wrote:
> I am exploring the possibility to move selftests to a better location
> or add a git alias so it can be found easily. With the addition of
> KUnit and future work that is planned to connect kselftest and KUnit,
> it would make sense have selftests to be in a location
On Mon, 2019-09-23 at 11:14 -0700, John Hubbard wrote:
> On 9/23/19 10:25 AM, Leonardo Bras wrote:
> [...]
> That part is all fine, but there are no run-time memory barriers in the
> atomic_inc() and atomic_dec() additions, which means that this is not
> safe, because memory operations on CPU 1
On 9/23/19 5:19 AM, Matthew Wilcox wrote:
>
> Ping Jens?
>
> On Wed, Sep 18, 2019 at 08:49:49PM -0700, Matthew Wilcox wrote:
>> On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng wrote:
>>> On 9/18/19 20:33, Michal Hocko wrote:
I absolutely agree here. From you changelog it is also not
From: Borislav Petkov
db47d5f85646 ("x86/nmi, EDAC: Get rid of DRAM error reporting thru PCI SERR
NMI")
forgot to remove it. Drop it.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/traps.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kernel/traps.c
On Mon, Sep 23, 2019 at 11:41:59AM -0700, Andy Lutomirski wrote:
> On Mon, Sep 23, 2019 at 2:49 AM Borislav Petkov wrote:
> >
> > On Fri, Sep 20, 2019 at 03:19:09PM +0200, Christian Brauner wrote:
> > > While touching seccomp code I realized that the struct seccomp_data
> > > argument to
Hi,
On 9/23/19 10:14 AM, Hans de Goede wrote:
Ack, this is what drivers/i2c/i2c-core-acpi.c is doing and more in general
all ACPI enumeration code always first checks _STA before doing anything
else, so I think it would be best to do this here too.
Actually I think it might be best to fully
On Mon, Sep 23, 2019 at 12:01 PM Linus Torvalds
wrote:
>
> Anyway, this bug would likely had been avoided if rcu_swap_protected()
> just returned the old pointer instead of changing the argument.
Also, I have to say that the fact that I got the fundamentally buggy
commit in a pull request
On Mon, Sep 23, 2019 at 06:07:27PM +, Lei Wang wrote:
> After merge is over, it would be something like Linux v5.4-rc1?
Yes, I'll update it once v5.4-rc1 is released.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
The pull request you sent on Sun, 22 Sep 2019 22:56:23 +0200 (CEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching.git
> for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9f7582d15f82e86b2041ab22327b7d769e061c1f
Thank you!
--
The pull request you sent on Sun, 22 Sep 2019 22:49:57 +0200 (CEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1ad0bc78948652edc3067b6b49ba31b1598faa4a
Thank you!
--
Deet-doot-dot, I am a
On 2019-09-23 17:43, Jason Baron wrote:
On 9/4/19 4:22 PM, Jason Baron wrote:
Currently, ep_poll_safewake() in the CONFIG_DEBUG_LOCK_ALLOC case uses
ep_call_nested() in order to pass the correct subclass argument to
spin_lock_irqsave_nested(). However, ep_call_nested() adds unnecessary
checks
Assorted conversions of options parsing to new API.
gfs2 is probably the most serious one here; the rest is
trivial stuff. Other things in what used to be #work.mount
are going to wait for the next cycle (and preferably go via
git trees of the filesystems involved).
The following changes
On Mon, Sep 23, 2019 at 12:19:30PM +0200, Paolo Bonzini wrote:
> On 20/09/19 23:24, Andrea Arcangeli wrote:
> > diff --git a/arch/x86/kvm/svm_ops.c b/arch/x86/kvm/svm_ops.c
> > new file mode 100644
> > index ..2aaabda92179
> > --- /dev/null
> > +++ b/arch/x86/kvm/svm_ops.c
> > @@ -0,0
Add an API for EDAC device to report multiple errors with same type.
Signed-off-by: Hanna Hawa
Acked-by: Robert Richter
---
drivers/edac/edac_device.c | 56 --
drivers/edac/edac_device.h | 47
2 files changed, 83
Add an API for EDAC device to report for multiple errors, and move the
old report function to use the new API.
Changes from v3:
- Move count check to inline function
- Fix count variable describtion
(Reported-by: kbuild test robot )
Changes from v2:
- Remove
On Mon, Sep 23, 2019 at 10:47 AM Mike Kravetz wrote:
>
> On 9/19/19 3:24 PM, Mina Almasry wrote:
> > Patch series implements hugetlb_cgroup reservation usage and limits, which
> > track hugetlb reservations rather than hugetlb memory faulted in. Details of
> > the approach is 1/7.
>
> Thanks for
Move edac_device_handle_*() functions from source file to header file as
inline funtcion that use the new API with single error.
Signed-off-by: Hanna Hawa
Acked-by: Robert Richter
---
drivers/edac/edac_device.c | 14 --
drivers/edac/edac_device.h | 35
On Mon, Sep 23, 2019 at 10:24 AM Casey Schaufler wrote:
>
> This is my first direct pull request. I think I have followed process
> correctly, but if not I will attend to my error as required.
The contents look fine.
However, it's from an open hosting site - github. Which is fine, I
take pull
On Mon, Sep 23, 2019 at 04:10:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 13, 2019 at 03:23:14PM +0200, Jiri Olsa escreveu:
> > We need page_size in libperf, so moving it in there.
> > Adding libperf_init as a global libperf init functon.
> >
> > Link:
On Mon, Sep 23, 2019 at 09:58:30AM +0200, Stefano Garzarella wrote:
> Hi Matias,
> thanks for this patch!
>
> Since this patch only concerns virtio_transport,
> I'd use the 'vsock/virtio' prefix in the commit title:
> "vsock/virtio: add support for MSG_PEEK"
>
> Some comments below:
>
> On Sun,
On Tue, Jul 23, 2019 at 3:17 AM Marc Zyngier wrote:
>
> On Mon, 22 Jul 2019 21:52:42 +0100,
> Pavel Tatashin wrote:
> >
> > On Mon, Jul 22, 2019 at 3:33 AM Marc Zyngier wrote:
> > >
> > > So far, we've let the arm64 kernel start its meaningful time stamping
> > > of the kernel log pretty late,
On Mon, 2019-09-23 at 15:35 -0300, Leonardo Bras wrote:
> Could you please provide feedback on this patch?
I have done a very simple comparison with gcc disassemble:
By applying this patch, there was a reduction in the function size from
882 to 878 instructions.
signature.asc
Description: This
On Mon, Sep 23, 2019 at 11:15:58AM -0700, Sean Christopherson wrote:
> On the flip side, using a switch for the fast-path handlers gives the
> compiler more flexibility to rearrange and combine checks. Of course that
> doesn't mean the compiler will actually generate faster code for our
>
On Mon, Sep 23, 2019 at 3:37 AM kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -7.3% regression of will-it-scale.per_process_ops due to
> commit:
Most likely this caused by changing struct file layout after adding new field.
>
>
> commit: e0e7df8d5b71bf59ad93fe75e662c929b580d805
Em Fri, Sep 13, 2019 at 03:23:14PM +0200, Jiri Olsa escreveu:
> We need page_size in libperf, so moving it in there.
> Adding libperf_init as a global libperf init functon.
>
> Link: http://lkml.kernel.org/n/tip-g6auuaej31nsusuevuhcg...@git.kernel.org
> Signed-off-by: Jiri Olsa
> ---
>
Since the last RFC patch set[1] much of the discussion of supporting RDMA with
FS DAX has been around the semantics of the lease mechanism.[2] Within that
thread it was suggested I try and write some documentation and/or tests for the
new mechanism being proposed. I have created a foundation
The pull request you sent on Tue, 17 Sep 2019 15:38:05 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
> tags/selinux-pr-20190917
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5825a95fe92566ada2292a65de030850b5cff1da
Thank you!
--
The pull request you sent on Wed, 18 Sep 2019 10:41:06 -0700:
> https://github.com/micah-morton/linux.git tags/safesetid-bugfix-5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1b5fb415442eb3ec946d48afe8c87b0f2fd42d7c
Thank you!
--
Deet-doot-dot, I am a bot.
On Mon, Sep 23, 2019 at 11:57:57AM +0200, Paolo Bonzini wrote:
> On 23/09/19 11:31, Vitaly Kuznetsov wrote:
> > +#ifdef CONFIG_RETPOLINE
> > + if (exit_reason == EXIT_REASON_MSR_WRITE)
> > + return handle_wrmsr(vcpu);
> > + else if (exit_reason ==
On 9/20/2019 9:42 AM, Robert Richter wrote:
On 19.09.19 18:17:12, Hanna Hawa wrote:
Add an API for EDAC device to report multiple errors with same type.
Signed-off-by: Hanna Hawa
With the change below it looks good to me:
Acked-by: Robert Richter
Thanks
Thanks,
-Robert
---
On Wed, Sep 18, 2019 at 10:41 AM Micah Morton wrote:
>
> Fix for SafeSetID bug that was introduced in 5.3
So this seems to be a good fix, but the bug itself came from the fact that
rcu_swap_protected(..)
is so hard to read, and I don't see *why* it's so pointlessly hard to read.
Yes, we
On 9/20/2019 9:49 AM, Robert Richter wrote:
On 19.09.19 18:17:13, Hanna Hawa wrote:
Move edac_device_handle_*() functions from source file to header file as
inline funtcion that use the new API with single error.
Signed-off-by: Hanna Hawa
With the changes below it looks good to me:
These are some changes, which help users to use the base-freq and
turbo-freq features without going through multiple steps for
basic configuration. Also add some error when user is trying
to disable core-power feature while it is getting used.
None of these patches are urgent and can wait for
Introduce --auto|-a option to base-freq enable feature, so that it
does in one step for users who are OK by setting all cores with higher
base frequency to be set in CLOS 0 and remaining in CLOS 3. This option
also sets corresponding clos.min to CLOS 0 and CLOS3. In this way, users
don't have to
The turbo-freq feature is dependent on the core-power feature. If the
core-power feature is disabled while the turbo-freq feature is enabled,
this will break the turbo-freq feature. This is a firmware limitation,
where they can't return error under this scenario.
So when trying to disable
Introduce --auto|-a option to turbo-freq enable feature, so that it
does in one step for users who are OK by setting all passed target cores
as high priority and set in CLOS 0 and remaining in CLOS 3. In this way,
users don't have to take multiple steps to enable turbo-freq feature. For
users who
On September 23, 2019 11:15:20 AM PDT, Steve Wahl wrote:
>Our hardware (UV aka Superdome Flex) has address ranges marked
>reserved by the BIOS. Access to these ranges is caught as an error,
>causing the BIOS to halt the system.
>
>Initial page tables mapped a large range of physical addresses
On Mon, Sep 23, 2019 at 11:36:11AM -0700, Doug Anderson wrote:
> On Mon, Sep 23, 2019 at 11:14 AM Mark Brown wrote:
> > Boot on means that it's powered on when the kernel starts, it's
> > for regulators that we can't read back the status of.
> 1. Would it be valid to say that it's always
On Mon, 23 Sep 2019 12:31:39 +0200
Borislav Petkov wrote:
> + Masami.
>
> On Sun, Sep 22, 2019 at 06:03:28PM +0300, Alexander Kapshuk wrote:
> > This patch fixes the regexp warnings shown below:
>
> Avoid having "This patch" or "This commit" in the commit message. It is
> tautologically
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more
By replacing, we would reduce the use of 'global' current on code,
relying more in the contents of kvm struct.
On code, I found that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have tests like that:
if (kvm->mm != current->mm)
return -EIO;
So
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more
On Mon, Sep 23, 2019 at 2:49 AM Borislav Petkov wrote:
>
> On Fri, Sep 20, 2019 at 03:19:09PM +0200, Christian Brauner wrote:
> > While touching seccomp code I realized that the struct seccomp_data
> > argument to secure_computing() seems to be unused by all current
> > callers. So let's remove
On 2019-09-23 20:34, Bartosz Golaszewski wrote:
> pon., 23 wrz 2019 o 20:30 Peter Rosin napisał(a):
>>
>> which is no longer allowed. That might be a problem? The previous binding
>> also allows less e.g.
>>
>> compatible = "atmel,24c00", "renesas,24mac402";
>>
>
> Right, but I'm not
Hi,
On Mon, Sep 23, 2019 at 11:14 AM Mark Brown wrote:
>
> On Mon, Sep 23, 2019 at 11:02:26AM -0700, Doug Anderson wrote:
>
> > I will freely admit my ignorance here, but I've always been slightly
> > confused by the "always-on" vs. "boot-on" distinction...
>
> > The bindings say:
>
> >
On Mon, 23 Sep 2019, Sebastian Andrzej Siewior wrote:
> Patch ("posix-timers: Add expiry lock") acquired a lock in
> run_posix_cpu_timers() but didn't drop the lock in the early return.
>
> Unlock the lock in the early return path.
>
> Reported-by: kbuild test robot
> Reported-by: Dan
On Thu, 2019-09-19 at 23:47 -0300, Leonardo Bras wrote:
> Hello Paul,
> I sent this patch, but I have a question:
>
> > + mm = current->mm;
>
> Here, current->mm is not always the same as kvm->mm?
> Thanks
I have contacted Paul, who said it is equivalent. But I think I will
deal with that
pon., 23 wrz 2019 o 20:30 Peter Rosin napisał(a):
>
> On 2019-09-23 19:52, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Convert the binding document for at24 EEPROMs from txt to yaml. The
> > compatible property uses a regex pattern to address all the possible
> >
On Fri, Sep 20, 2019 at 11:07 PM Florian Weimer wrote:
>
> * Linus Torvalds:
>
> > Violently agreed. And that's kind of what the GRND_EXPLICIT is really
> > aiming for.
> >
> > However, it's worth noting that nobody should ever use GRND_EXPLICIT
> > directly. That's just the name for the bit. The
On 2019-09-23 19:52, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Convert the binding document for at24 EEPROMs from txt to yaml. The
> compatible property uses a regex pattern to address all the possible
> combinations of "vendor,model" strings.
>
> Signed-off-by: Bartosz
* Adam Ford [190911 17:14]:
> On Wed, Sep 11, 2019 at 11:50 AM Sebastian Reichel wrote:
> >
> > Hi,
> >
> > On Wed, Sep 11, 2019 at 09:52:25AM -0500, Adam Ford wrote:
> > > The omap panel-dpi driver was removed in
> > > Commit 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
> > >
> > > The
On Mon, Sep 23, 2019 at 05:45:47PM +0200, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
Acked-by: Mark Brown
signature.asc
Description: PGP signature
Instead of caching the GICv4 compatibility in a discrete way, cache the
TYPER register instead, which can then be used to implement the same
functionnality. This will get used more extensively in subsequent patches.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 24
GICv4.1 defines a new VPE table that is potentially shared between
both the ITSs and the redistributors, following complicated affinity
rules.
To make things more confusing, the programming of this table at
the redistributor level is reusing the GICv4.0 GICR_VPROPBASER register
for something
Making a VPE resident on GICv4.1 is pretty simple, as it is just a
single write to the local redistributor. We just need extra information
about which groups to enable, which the KVM code will have to provide.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 17
When descheduling a VPE, special care must be taken to tell the GIC
about whether we want to receive a doorbell or not. This is a
major improvement on GICv4.0, where the doorbell had to be separately
enabled/disabled.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 53
masking/unmasking doorbells on GICv4.1 relies on a new INVDB command,
which broadcasts the invalidation to all RDs.
Implement the new command as well as the masking callbacks, and plug
the whole thing into the v4.1 VPE irqchip.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c
The infamous VPE proxy device isn't used with GICv4.1 because:
- we can invalidate any LPI from the DirectLPI MMIO interface
- the ITS and redistributors understand the life cycle of
the doorbell, so we don't need to enable/disable it all
the time
So let's escape early from the proxy related
Hello,
syzbot found the following crash on:
HEAD commit:24ccb0ab qede: qede_fp: simplify a bit 'qede_rx_build_skb()'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=11a5b22960
kernel config: https://syzkaller.appspot.com/x/.config?x=dfcf592db22b9132
On Sun, Sep 22, 2019 at 02:43:19PM -0400, Sasha Levin wrote:
> From: Katsuhiro Suzuki
>
> [ Upstream commit ebe02a5b9ef05e3b812af3d628cdf6206d9ba610 ]
>
> This patch supports some type of machine drivers that set 0 to mclk
> when sound device goes to idle state. After applied this patch,
>
* Adam Ford [190911 10:47]:
> The TFP410 driver was removed but the replacement driver was
> never enabled. This patch enableds the DRM_TI_TFP410
>
> Fixes: be3143d8b27f ("drm/omap: Remove TFP410 and DVI connector drivers")
Applying into fixes thanks.
Tony
Booting with default_ps_max_latency_us >6000 makes the device fail.
Also SUBNQN is NULL and gives a warning on each boot/resume.
$ nvme id-ctrl /dev/nvme0 | grep ^subnqn
subnqn: (null)
I use this device with an Acer Nitro 5 (AN515-43-R8BF) Laptop.
To be sure is not a Laptop issue only, I
On Sun, Sep 22, 2019 at 02:41:53PM -0400, Sasha Levin wrote:
> From: Jiaxin Yu
>
> [ Upstream commit ccb1fa21ef58a2ac15519bb878470762e967e8b3 ]
>
> Most dmics produce a high level when they receive clock. The difference
> between power-on and memory record time is about 10ms, but the dmic
>
On Thu, Sep 19, 2019 at 8:09 AM Thomas Gleixner wrote:
>
> When working on a way to move out the posix cpu timer expiry out of the
> timer interrupt context, I noticed that KVM is not handling pending task
> work before entering a guest. A quick hack was to add that to the x86 KVM
> handling
On Mon, Sep 23, 2019 at 11:07 AM Paul Burton wrote:
>
> Another issue is that there are currently 'expected' warnings dotted
> through the tree for various defconfigs
This is why I refuse to have _any_ warnings at all in my tree during
the merge window.
If you have expected warnings, you will
On Mon, 2019-09-23 at 09:16 -0400, Prarit Bhargava wrote:
> The turbo ratio limits and turbo frequencies add a large amount of
> lines to the output. The output can be truncated into human and
> machine readable tables to reduce the number of lines of output.
>
Unfortunately this breaks json
On Thu, Sep 19, 2019 at 8:09 AM Thomas Gleixner wrote:
>
> Entering a guest is similar to exiting to user space. Pending work like
> handling signals, rescheduling, task work etc. needs to be handled before
> that.
>
> Provide generic infrastructure to avoid duplication of the same handling code
On Mon, Sep 23, 2019 at 01:42:44PM -0400, Andrea Arcangeli wrote:
> On Mon, Sep 23, 2019 at 06:53:10PM +0200, Paolo Bonzini wrote:
> > On 23/09/19 18:37, Sean Christopherson wrote:
> > >> Would it be too much if we get rid of
> > >> kvm_vmx_exit_handlers completely replacing this code with one
The kernel image map is created using PMD pages, which can include
some extra space beyond what's actually needed. Round the size of the
memory hole we search for up to the next PMD boundary, to be certain
all of the space to be mapped is usable RAM and includes no reserved
areas.
Signed-off-by:
Our hardware (UV aka Superdome Flex) has address ranges marked
reserved by the BIOS. Access to these ranges is caught as an error,
causing the BIOS to halt the system.
Initial page tables mapped a large range of physical addresses that
were not checked against the list of BIOS reserved addresses,
This patch set narrows the valid space addressed by the page table
level2_kernel_pgt to only contain ranges checked against the "usable
RAM" list provided by the BIOS.
Prior to this, some larger than needed mappings were occasionally
crossing over into spaces marked reserved, allowing the
On Mon, Sep 23, 2019 at 11:02:26AM -0700, Doug Anderson wrote:
> I will freely admit my ignorance here, but I've always been slightly
> confused by the "always-on" vs. "boot-on" distinction...
> The bindings say:
> regulator-always-on:
> description: boolean, regulator should never be
On Mon, Sep 23, 2019 at 4:28 AM Peter Zijlstra wrote:
>
> I'm conflicted on this one... the only use of addr here is
> pti_user_pagetable_walk_pmd() and that already masks things, so the
> fixup is 'pointless'.
No it's not.
The *other* use of 'addr' is
addr += PMD_SIZE;
and then
On Mon, Sep 23, 2019 at 8:39 AM Petr Vorel wrote:
>
> Hi,
>
> > > FYI, we noticed the following commit (built with gcc-7):
>
> > > commit: 12abeb544d548f55f56323fc6e5e6c0fb74f58e1 ("horrible test hack")
> > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/luto/linux.git
> > >
Em Fri, Sep 13, 2019 at 03:23:01PM +0200, Jiri Olsa escreveu:
> diff --git a/tools/perf/lib/include/internal/evsel.h
> b/tools/perf/lib/include/internal/evsel.h
> index 8b854d1c9b45..220cb2e2b54e 100644
> --- a/tools/perf/lib/include/internal/evsel.h
> +++
Hi Linus,
On Sun, Sep 22, 2019 at 11:35:36AM -0700, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 4:10 PM Paul Burton wrote:
> >
> > Here are the main MIPS changes for v5.4; please pull.
>
> Hmm. I pulled and because initial tests didn't show any issues, I
> already pushed out.
>
> But some
On Sun, Sep 22, 2019 at 9:26 PM Peter Xu wrote:
>
> This patch is a preparation of removing that special path by allowing
> the page fault to return even faster if we were interrupted by a
> non-fatal signal during a user-mode page fault handling routine.
So I really wish saome other vm person
201 - 300 of 783 matches
Mail list logo
