Currently, after a VM boots with APICv enabled, it could go into
the following states:
* activated = VM is running w/ APICv
* suspended = VM deactivate APICv temporarily
* disabled = VM deactivate APICv permanently
Introduce KVM APICv state enum to help keep track of the APICv states
Re-factor code into a helper function for setting lapic parameters when
activate/deactivate APICv, and export the function for subsequent usage.
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kvm/lapic.c | 22 +-
arch/x86/kvm/lapic.h | 1 +
2 files changed, 18
On Thu, 29 Aug 2019 at 07:34, Bradford, Robert
wrote:
>
> On Thu, 2019-08-29 at 14:18 +0200, Thomas Gleixner wrote:
> > On Thu, 29 Aug 2019, Rob Bradford wrote:
> >
> > CC+ Ard
> >
> > > Replace the check using efi_runtime_disabled() which only checks if
> > > EFI
> > > runtime was disabled on
Commit 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to
tpm_pcr_extend()") modifies tpm_pcr_extend() to accept a digest for each
PCR bank. After modification, tpm_pcr_extend() expects that digests are
passed in the same order as the algorithms set in chip->allocated_banks.
On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano
wrote:
>
> On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
>
> [ ... ]
>
> >> Good news (I think)
> >>
> >> With cooling-device = < 1 2> setup, I was able to ask the max
> >> frequency and it returned 600MHz.
> >>
> >> # cat
On Fri, 2019-09-13 at 15:26 +0100, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 3:12 PM Joe Perches wrote:
> > On Thu, 2019-09-12 at 13:01 -0700, Bart Van Assche wrote:
> >
> > > Another argument in favor of W=1 is that the formatting of kernel-doc
> > > headers is checked only if W=1 is passed
On Fri, Sep 13, 2019 at 07:19:41PM +0100, Cristian Marussi wrote:
> Tested as follows:
>
> - arm:
> 1. boot
So this basically means the code paths you're touching are untested on
ARM... given that, and the variety of systems we have out there, why
should the patches touching ARM be taken?
Given
On 9/12/19 5:43 PM, Mike Kravetz wrote:
> On 9/12/19 2:06 AM, Waiman Long wrote:
>> If we can take the rwsem in read mode, that should solve the problem
>> AFAICS. As I don't have a full understanding of the history of that
>> code, I didn't try to do that in my patch.
> Do you still have access
Make sparc64 use the generic SMP-stop logic provided by common code
unified smp_send_stop() function.
Signed-off-by: Cristian Marussi
---
arch/sparc/Kconfig | 1 +
arch/sparc/kernel/smp_64.c | 15 ---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git
Make arm use the SMP common implementation of crash_smp_send_stop() and
its generic logic, by removing the arm crash_smp_send_stop() definition
and providing the needed arch specific helpers.
Signed-off-by: Cristian Marussi
---
arch/arm/kernel/machine_kexec.c | 27 ++-
1
Add an arm64 specific helper which parks the cpu in a more architecture
efficient way.
Signed-off-by: Cristian Marussi
---
arch/arm64/kernel/smp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f0cc2bf84aaa..539e8db5c1ba 100644
Make x86 use the generic SMP-stop logic provided by common code unified
smp_send_stop() function.
Introduce needed arch_smp_stop_call()/arch_smp_cpus_stop_complete()
helpers that implement the backend architectures specific functionalities
previously provided by native_stop_other_cpus(): common
Make arm use the generic SMP-stop logic provided by common code
unified smp_send_stop() function.
Signed-off-by: Cristian Marussi
---
arch/arm/Kconfig | 1 +
arch/arm/kernel/smp.c | 18 ++
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch/arm/Kconfig
Make arm64 use the generic SMP-stop logic provided by common code
unified smp_send_stop() function.
arm64 smp_send_stop() logic had a bug in it: it failed to consider the
online status of the calling CPU when evaluating if any stop message
needed to be sent to other CPus at all: this resulted, on
Add to SMP stop common code a best-effort retry logic, re-issuing a stop
request when any CPU is detected to be still online after the first
stop request cycle has completed.
While retrying provide to architectures' helpers an 'attempt' argument
so that, after a possible first failed attempt,
There was a lot of code duplication across architectures regarding the
SMP stop procedures' logic; moreover some of this duplicated code logic
happened to be similarly faulty across a few architectures: while fixing
such logic, move such generic logic as much as possible inside common
code.
Once a stop request is in progress on one CPU, it must be carefully
evaluated what to do if another stop request is issued concurrently
on another CPU.
Given that panic and crash dump code flows are mutually exclusive,
the only alternative possible scenario which instead could lead to
concurrent
Make arm64 use the SMP common implementation of crash_smp_send_stop() and
its generic logic, by removing the arm64 crash_smp_send_stop() definition
and providing the needed arch specific helpers.
Additionally, simplify the arch-specific stop and crash dump ISRs backends
(which are in charge of
Hi all,
the logic underlying SMP stop and kexec crash procedures, beside containing
some arch-specific bits, is mostly generic and common across all archs:
despite this fact, such logic is now scattered across all architectures and
on some of them is flawed, in such a way that, under some
Make x86 use the SMP common implementation of crash_smp_send_stop() and
its generic logic, by removing the x86 crash_smp_send_stop() definition
and providing the needed arch specific helpers.
Remove also redundant smp_ops.crash_stop_other_cpus(); add shared util
function
crash_smp_send_stop() logic was fairly similar to smp_send_stop():
a lot of logic and code was duplicated between the two code paths and
across a few different architectures.
Unify this underlying common logic into the existing SMP common stop
code: use a common workhorse function for both paths
On 9/13/19 2:54 AM, Kirill A. Shutemov wrote:
> The next major release of distributions expected to have
> CONFIG_X86_5LEVEL=y.
It's probably worth noting that this exposes to two kinds of possible
performance issues:
First is the overhead of having the 5-level code on 4-level hardware.
We
> > > The binding we use with out-of-tree Mali drivers includes more
> > > clocks, I assume this would be required eventually if we have an
> > > in-tree driver:
> >
> > We have an in-tree driver...
>
> Right but AFAICT it does not support Bifrost GPU (yet?).
By the time MT8183 shows up in more
On Thu, Sep 12, 2019 at 10:48:13AM +0100, Linus Walleij wrote:
> On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
> wrote:
>
> > devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode
> > in question does not have to be a child of device node. Let's rename it
> > to
On Fri, Sep 13, 2019 at 12:40:07PM +0300, Mika Westerberg wrote:
> On Thu, Sep 12, 2019 at 08:22:38PM -0700, Dmitry Torokhov wrote:
> > devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode
> > in question does not have to be a child of device node. Let's rename it
> > to
On Wed, Sep 11, 2019 at 12:01:42PM +, Tony W Wang-oc wrote:
> + /* Checks after this one are Intel/Zhaoxin-specific: */
> + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
> + boot_cpu_data.x86_vendor != X86_VENDOR_ZHAOXIN)
Is it time to have a big cleanup on how we
On Mon, 2 Sep 2019 15:32:42 +0800
Ben Luo wrote:
> 在 2019/8/30 上午1:06, Alex Williamson 写道:
> > On Fri, 30 Aug 2019 00:58:22 +0800
> > Ben Luo wrote:
> >
> >> 在 2019/8/28 下午11:55, Alex Williamson 写道:
> >>> On Wed, 28 Aug 2019 12:28:04 +0800
> >>> Ben Luo wrote:
> >>>
> currently,
Em Fri, 13 Sep 2019 19:53:20 +0200
Borislav Petkov escreveu:
> On Fri, Sep 13, 2019 at 11:50:25AM -0300, Mauro Carvalho Chehab wrote:
> > There is a recent discussion at KS ML with regards to use W=1 as default.
> >
> > No idea if this will happen or not, but it doesn't hurt cleaning up W=1
> >
On Fri, Sep 13, 2019 at 7:00 PM Olof Johansson wrote:
>
> On Mon, Jul 29, 2019 at 5:36 PM Kees Cook wrote:
> >
> > On Sun, Jul 28, 2019 at 07:06:31PM -0500, Gustavo A. R. Silva wrote:
> > > Mark switch cases where we are expecting to fall through.
> > >
> > > This patch fixes the following
On Mon, Jul 29, 2019 at 5:36 PM Kees Cook wrote:
>
> On Sun, Jul 28, 2019 at 07:06:31PM -0500, Gustavo A. R. Silva wrote:
> > Mark switch cases where we are expecting to fall through.
> >
> > This patch fixes the following warnings:
> >
> > drivers/usb/phy/phy-ab8500-usb.c: In function
> >
Hi Randy,
On Fri, Sep 13, 2019 at 5:00 PM Randy Dunlap wrote:
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
> >> So I'm expecting to take this kind of stuff into Documentation/. My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence. The
> Looks ok to me at a quick glance, ACK.
Me too. Also ACK.
-Tony
On Fri, Sep 13, 2019 at 11:50:25AM -0300, Mauro Carvalho Chehab wrote:
> There is a recent discussion at KS ML with regards to use W=1 as default.
>
> No idea if this will happen or not, but it doesn't hurt cleaning up W=1
> warnings from the EDAC subsystem, specially since it helps to cleanup
>
On Tue, 10 Sep 2019 14:30:16 +0800
Ben Luo wrote:
> A friendly reminder.
The vfio patch looks ok to me. Thomas, do you have further comments or
a preference on how to merge these? I'd tend to prefer the vfio
changes through my branch for testing and can pull the irq changes with
your
-Original Message-
From: Ferry Toth [mailto:fnt...@gmail.com]
Sent: Friday, September 13, 2019 9:48 AM
To: Shevchenko, Andriy ; Moore, Robert
Cc: Nikolaus Voss ; Schmauss, Erik ;
Rafael J. Wysocki ; Len Brown ; Jacek
Anaszewski ; Pavel Machek ; Dan
Murphy ;
On Fri, Sep 13, 2019 at 5:11 AM Kishon Vijay Abraham I wrote:
>
> + Haotian Wang
>
> On 03/06/19 11:12 PM, Alan Mikhak wrote:
> > On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I wrote:
> >> Hi Alan,
> >> On 31/05/19 11:46 PM, Alan Mikhak wrote:
> >>> On Thu, May 30, 2019 at 10:08 PM Kishon
On Fri, 2019-09-13 at 16:03 +0100, David Howells wrote:
> Jarkko Sakkinen wrote:
>
> > Subject: [PATCH] MAINTAINERS: Add a git and a maintainer entry to keyring
> > subsystems
>
> I would recommend splitting the patch in two and putting something like:
>
> keys: Add Jarkko Sakkinen as
please don't top-post on public mailing lists, thanks.
On 9/13/19 9:45 AM, Yu-Hsuan Hsu wrote:
Thanks for the review! If I'm not mistaken, the microphone is attached
to external codec(rt5514) instead of PCH on Kabylake platform. So there
should be a TDM between DMICs and PCH. We can see in the
On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
[ ... ]
>> Good news (I think)
>>
>> With cooling-device = < 1 2> setup, I was able to ask the max
>> frequency and it returned 600MHz.
>>
>> # cat /sys/devices/virtual/thermal/thermal_zone0/temp
>> 58500
>> # cat
On 9/13/19 7:15 AM, Aaron Lu wrote:
> On Thu, Sep 12, 2019 at 10:29:13AM -0700, Tim Chen wrote:
>
>> The better thing to do is to move one task from cgroupA to another core,
>> that has only one cgroupA task so it can be paired up
>> with that lonely cgroupA task. This will eliminate the forced
Replace call to kmalloc followed by memcpy with a direct call
to kmemdup to achieve same functionality.
Signed-off-by: Saiyam Doshi
---
fs/omfs/inode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
index b76ec6b88ded..788b41096962
Hi Linus,
Set of changes of PDx86 for v5.4. No conflicts with recent origin/master.
Pity, but I have to move the status from Maintained to Odd Fixes.
Thanks,
With Best Regards,
Andy Shevchenko
The following changes since commit f14312a93b34b9350dc33ff0b4215c24f4c82617:
platform/x86:
- On Sep 13, 2019, at 12:04 PM, Oleg Nesterov o...@redhat.com wrote:
> On 09/13, Mathieu Desnoyers wrote:
>>
>> membarrier_exec_mmap(), which seems to be affected by the same problem.
>
> IIRC, in the last version it is called by exec_mmap() undef task_lock(),
> so it should fine.
Fair
stable-rc/linux-4.4.y boot: 102 boots: 1 failed, 92 passed with 9 offline
(v4.4.192-9-g160225f8cfe2)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.192-9-g160225f8cfe2/
Full Build Summary:
Hello all,
Sorry to have sent our message with cancelled e-mail address. I have
correct this now.
Op 13-09-19 om 17:12 schreef Shevchenko, Andriy:
On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote:
-Original Message-
From: Nikolaus Voss [mailto:n...@vosn.de]
Sent:
> Am 13.09.2019 um 18:42 schrieb Adam Ford :
>
> On Fri, Sep 13, 2019 at 11:35 AM Adam Ford wrote:
>>
>> On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller
>> wrote:
>>>
>>>
Am 13.09.2019 um 17:01 schrieb Adam Ford :
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
The thermal sensor in the omap3 family isn't accurate, but it's
better than nothing. The various OPP's enabled for the omap3630
support up to OPP1G, however the datasheet for the DM3730 states
that OPP130 and OPP1G are not available above TJ of 90C.
This patch configures the thermal throttling
On Fri, Sep 13, 2019 at 11:35:10AM -0500, Eddie James wrote:
> Document the AST2600 I2C bus compatible string.
>
> Signed-off-by: Eddie James
Reviewed-by: Brendan Higgins
Thanks!
On Fri, Sep 13, 2019 at 11:35:09AM -0500, Eddie James wrote:
> The driver default behavior works with the AST2600. We need a new
> compatible though to make sure the driver doesn't enable AST2400 or
> AST2500 behavior.
>
> Signed-off-by: Eddie James
Reviewed-by: Brendan Higgins
Thanks!
> From: Vitaly Kuznetsov
> Sent: Thursday, September 12, 2019 9:27 AM
>
> Dexuan Cui writes:
>
> > +static void perform_hibernation(struct work_struct *dummy)
> > +{
> > + /*
> > +* The user is expected to create the program, which can be a simple
> > +* script containing two lines:
On Fri, Sep 13, 2019 at 11:35 AM Adam Ford wrote:
>
> On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 13.09.2019 um 17:01 schrieb Adam Ford :
> > >
> > > On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
> > > wrote:
> > >>
> > >>
> > >>> Am 13.09.2019 um
On Fri, 2019-09-13 at 16:46 +0100, Rob Herring wrote:
> On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap wrote:
> > On 9/13/19 4:48 AM, Dan Carpenter wrote:
> >
> > > > So I'm expecting to take this kind of stuff into Documentation/. My own
> > > > personal hope is that it can maybe serve to shame
On Fri, Sep 13, 2019 at 12:42:32PM +0200, Borislav Petkov wrote:
> Or should we talk to Intel hw folks about it...
Or, I can do something like this, while waiting. Benchmark at the end.
The numbers are from a KBL box:
model : 158
model name : Intel(R) Core(TM) i5-9600K CPU @
On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller
wrote:
>
>
> > Am 13.09.2019 um 17:01 schrieb Adam Ford :
> >
> > On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
> > wrote:
> >>
> >>
> >>> Am 13.09.2019 um 16:05 schrieb Adam Ford :
> >>>
> >>> On Fri, Sep 13, 2019 at 8:32 AM H.
Document the AST2600 I2C bus compatible string.
Signed-off-by: Eddie James
---
Documentation/devicetree/bindings/i2c/i2c-aspeed.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
The driver default behavior works with the AST2600. We need a new
compatible though to make sure the driver doesn't enable AST2400 or
AST2500 behavior.
Signed-off-by: Eddie James
---
drivers/i2c/busses/i2c-aspeed.c | 4
1 file changed, 4 insertions(+)
diff --git
Update the Aspeed I2C driver with the AST2600 compatible string. The default
driver behavior works fine with the AST2600. A new compatible string is needed
to avoid the AST2400 and AST2500 behavior.
Eddie James (2):
i2c: Aspeed: Add AST2600 compatible
dt-bindings: i2c: Aspeed: Add AST2600
Replace call to kmalloc followed by memcpy with a direct call
to kmemdup to achieve same functionality.
Signed-off-by: Saiyam Doshi
---
security/integrity/ima/ima_policy.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/security/integrity/ima/ima_policy.c
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
The commit b7d5dc21072c ("random: add a spinlock_t to struct
batched_entropy") insists on acquiring "batched_entropy_u32.lock" in
get_random_u32() which introduced the lock chain,
">lock --> batched_entropy_u32.lock"
even after crng init. As the result, it could result in deadlock below.
Fix it
On 13/09/19 17:36, Alan Stern wrote:
> On Fri, 13 Sep 2019, Paolo Bonzini wrote:
>
>> On 13/09/19 15:02, Greg Kroah-Hartman wrote:
>>> Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
>>> not need this type of thing. If we got it wrong, please let us know and
>>> then yes,
On 09/13, Mathieu Desnoyers wrote:
>
> membarrier_exec_mmap(), which seems to be affected by the same problem.
IIRC, in the last version it is called by exec_mmap() undef task_lock(),
so it should fine.
Oleg.
Pierre-Louis Bossart 於
2019年9月12日 週四 下午9:02寫道：
>
> On 9/11/19 9:27 PM, Yu-Hsuan Hsu wrote:
> > 24 bits recording from DMIC is not supported for KBL platform because
> > the TDM slot between PCH and codec is 16 bits only. We should add a
> > constraint to remove that unsupported format.
>
> Humm,
Hi Ezequiel,
On 2019年09月13日 23:32, Ezequiel Garcia wrote:
Hi Zhou,
Thanks for your interest in this driver, I'm glad
so see it's more used.
On Thu, 2019-09-05 at 15:38 +0800, Zhou Yanjie wrote:
Adjust the macro definition name to match the corresponding
register name in the datasheet.
It's
- On Sep 11, 2019, at 3:00 PM, carlos car...@redhat.com wrote:
> On 9/11/19 2:26 PM, Florian Weimer wrote:
>> * Mathieu Desnoyers:
>>
>>> +#ifdef SHARED
>>> + if (rtld_active ())
>>> +{
>>> + /* Register rseq ABI to the kernel. */
>>> + (void) rseq_register_current_thread
On Fri, Sep 13, 2019 at 4:00 PM Randy Dunlap wrote:
>
> On 9/13/19 4:48 AM, Dan Carpenter wrote:
>
> >> So I'm expecting to take this kind of stuff into Documentation/. My own
> >> personal hope is that it can maybe serve to shame some of these "local
> >> quirks" out of existence. The evidence
Em Wed, 11 Sep 2019 08:48:48 -0700
Dan Williams escreveu:
> Fixup some P: entries to be M: and delete the others that do not include an
> email address. The P: tag will be used to indicate the location of a
> Profile for a given MAINTAINERS entry.
>
> Cc: Joe Perches
> Signed-off-by: Dan
Because the omap34xx, omap36xx and am3517 SoC's have the same
thermal junction limits, there is no need to duplicate the entry
multiple times.
This patch removes the thermal references from omap36xx and
omap34xx and pushes it into the common omap3.dtsi file with
the added benefit of enabling the
The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
depending on commercial or industrial temperature ratings. This
patch expands the thermal information to the limits of 90 and 105
for alert and critical.
For boards who never use industrial temperatures, these can be
changed on
On Fri, 13 Sep 2019, Paolo Bonzini wrote:
> On 13/09/19 15:02, Greg Kroah-Hartman wrote:
> > Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
> > not need this type of thing. If we got it wrong, please let us know and
> > then yes, a fix like this would be most appreciated
On Fri, 2019-09-13 at 10:22 -0400, Alan Stern wrote:
> On Thu, 12 Sep 2019, Joe Perches wrote:
>
> > On Thu, 2019-09-12 at 16:55 -0400, Alan Stern wrote:
> > > checkpatch.pl shouldn't warn about a "Missing Signed-off-by: line by
> > > nominal patch author" if there is no nominal patch author.
On 13/09/2019 16:01, Paolo Bonzini wrote:
On 13/09/19 15:02, Greg Kroah-Hartman wrote:
Look at linux-next, we "should" have fixed up hcd_buffer_alloc() now to
not need this type of thing. If we got it wrong, please let us know and
then yes, a fix like this would be most appreciated :)
I
Hi Zhou,
Thanks for your interest in this driver, I'm glad
so see it's more used.
On Thu, 2019-09-05 at 15:38 +0800, Zhou Yanjie wrote:
> Adjust the macro definition name to match the corresponding
> register name in the datasheet.
>
It's not really an issue to have slighlt different
names on
With the integration of the mmap/unmap functionality, it is no longer
necessary to allow large memory allocations upfront since they can be
handled during runtime.
Tested on QCS404 with CDSP Neural Processing test suite.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas Kandagatla
---
Hi Greg
These patches implement a few fixes identified while working on the
QCS404 ML integration plus we now have support for mmap/unmap of
buffers (so the process can be created with less initial memory
requirements).
Jorge Ramirez-Ortiz (4):
misc: fastrpc: add mmap/unmap support
misc:
the DSP firmware requires some calls to be held until processing has
completed: this is to guarantee that memory continues to be
accessible.
Nevertheless, the fastrpc driver chooses not support the case were
requests need to be held for unbounded amounts of time. If such a
use-case becomes
Buffers owned by a context that has been interrupted either by a
signal or a timeout might still be being accessed by the DSP.
delegate returning the associated memory to a later time when the
device is released.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas Kandagatla
---
Support the allocation/deallocation of buffers mapped to the DSP.
When the memory mapped to the DSP at process creation is not enough,
the fastrpc library can extend it at runtime. This avoids having to do
large preallocations by default.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas
From: Srinivas Kandagatla
Fix a memory leak in miscdev->name by using devm_variant
Orignally reported by kmemleak:
[] kmemleak_alloc+0x50/0x84
[] __kmalloc_track_caller+0xe8/0x168
[] kvasprintf+0x78/0x100
[] kasprintf+0x50/0x74
[] fastrpc_rpmsg_probe+0xd8/0x20c
[]
On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
>On Thu, Dec 13, 2018 at 07:54, Chao Gao wrote:
>>On Thu, Dec 13, 2018 at 12:54:52AM -0700, Jan Beulich wrote:
>> On 13.12.18 at 04:46, wrote:
On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
On
- On Sep 9, 2019, at 7:00 AM, Oleg Nesterov o...@redhat.com wrote:
> On 09/08, Mathieu Desnoyers wrote:
>>
>> +static void sync_runqueues_membarrier_state(struct mm_struct *mm)
>> +{
>> +int membarrier_state = atomic_read(>membarrier_state);
>> +bool fallback = false;
>> +
On Thu, 12 Sep 2019, Paul E. McKenney wrote:
> On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
> > Folks:
> >
> > I have spent some time writing up a section for
> > tools/memory-model/Documentation/explanation.txt on plain accesses and
> > data races. The initial version is
On Fri, Sep 13, 2019 at 08:11:24AM +0200, Rasmus Villemoes wrote:
> On 13/09/2019 00.30, Miguel Ojeda wrote:
> > On Fri, Sep 13, 2019 at 12:19 AM Rasmus Villemoes
> > wrote:
> >>
> >> Patch 1 has already been picked up by Greg in staging-next, it's
> >> included here for completeness. I don't
unlock_page() was lost in fuse_writepage()
Fixes commit ff17be086477 ("fuse: writepage: skip already in flight") # 3.13+
Signed-off-by: Vasily Averin
---
fs/fuse/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 5ae2828beb00..91c99724dee0 100644
On Thu, Sep 12, 2019 at 01:19:17PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 11, 2019 at 03:08:35PM -0500, Steve Wahl wrote:
> > Thank you for your time looking into this with me!
>
> With all this explanation the original patch looks sane to me.
>
> But I would like to see more information
It is preferrable to reject unknown flags within rseq unregistration
rather than to ignore them. It is an oversight caused by the fact that
the check for unknown flags is after the rseq unregister flag check.
Signed-off-by: Mathieu Desnoyers
Cc: Thomas Gleixner
Cc: Peter Zijlstra (Intel)
Cc:
On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote:
> -Original Message-
> From: Nikolaus Voss [mailto:n...@vosn.de]
> Sent: Friday, September 13, 2019 12:44 AM
> To: Moore, Robert
> Cc: Shevchenko, Andriy ; Schmauss, Erik
> ; Rafael J. Wysocki ; Len Brown
> ; Jacek
It has been reported by Google that rseq is not behaving properly
with respect to clone when CLONE_VM is used without CLONE_THREAD.
It keeps the prior thread's rseq TLS registered when the TLS of the
thread has moved, so the kernel deals with the wrong TLS.
The approach of clearing the per
glibc 2.30 introduces gettid() in public headers, which clashes with
the internal static definition within rseq selftests.
Rename gettid() to rseq_gettid() to eliminate this symbol name clash.
Reported-by: Tommi T. Rantala
Signed-off-by: Mathieu Desnoyers
Cc: Shuah Khan
Cc: Tommi T. Rantala
On Fri, Sep 13, 2019 at 08:04:07AM -0700, Randy Dunlap wrote:
> On 9/13/19 12:38 AM, Theodore Y. Ts'o wrote:
>
> > Let's continue the discussion on workfl...@vger.kernel.org.
>
> Hi,
> Will this be archived on lore.kernel.org?
It is already there:
https://lore.kernel.org/workflows/
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote:
>
> On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote:
> >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote:
> >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote:
> >> > Hi Greg,
> >> >
> >> > This feels
> Am 13.09.2019 um 17:01 schrieb Adam Ford :
>
> On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
> wrote:
>>
>>
>>> Am 13.09.2019 um 16:05 schrieb Adam Ford :
>>>
>>> On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller
>>> wrote:
Hi Adam,
> Am 13.09.2019 um
Michael Straube wrote:
> Function _rtl92c_evm_db_to_percentage is functionally identical
> to the generic version rtl_evm_db_to_percentage, so remove
> _rtl92c_evm_db_to_percentage and use the generic version instead.
>
> Signed-off-by: Michael Straube
3 patches applied to
On Fri, Sep 13, 2019 at 04:51:30PM +0200, Heiko Schocher wrote:
> Am 13.09.2019 um 12:24 schrieb Andy Shevchenko:
> > On Fri, Sep 13, 2019 at 07:01:05AM +0200, Heiko Schocher wrote:
> > > Patch is based on:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > >
Because the omap34xx, omap36xx and am3517 SoC's have the same
thermal junction limits, there is no need to duplicate the entry
multiple times.
This patch removes the thermal references from omap36xx and
omap34xx and pushes it into the common omap3.dtsi file with
the added benefit of enabling the
The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
depending on commercial or industrial temperature ratings. This
patch expands the thermal information to the limits of 90 and 105
for alert and critical.
For boards who never use industrial temperatures, these can be
changed on
Reading /sys/class/leds//trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.
Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all
On 9/13/19 12:38 AM, Theodore Y. Ts'o wrote:
> Let's continue the discussion on workfl...@vger.kernel.org.
Hi,
Will this be archived on lore.kernel.org?
thnx.
--
~Randy
201 - 300 of 973 matches
Mail list logo
