On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> A warning is generated when a PCIe device is probed with a degraded
> link, but there was no similar mechanism to warn when the link becomes
> degraded after probing. The Link Bandwidth Notification provides this
> mechanism.
>
>
Hi Han,
On 29.11.18 17:30, Han Xu wrote:
>
>
>> -Original Message-
>> From: Schrempf Frieder
>> Sent: Thursday, November 29, 2018 5:54 AM
>> To: Yogesh Narayan Gaur ; linux-
>> m...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
>> s...@vger.kernel.org; Marek Vasut ; Mark Brow
From: Adam Wong
Added the ability to detect the ELAN0621 touchpad found in some Lenovo
laptops.
Signed-off-by: Adam Wong
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index
> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>
> On Thu, 29 Nov 2018 12:20:00 -0500
> Steven Rostedt wrote:
>
>
>> r8 = return address
>> r9 = function to call
>>
>
> Bad example, r8 and r9 are args, but r10 and r11 are available.
>
> -- Steve
>
>>push r8
>>jmp *r9
>>
>>
Dear Friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Thank
On Thu, 29 Nov 2018 09:35:11 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
> >
> > No, we really do need to sync after we change the second part of the
> > command with the int3 on it. Unless there's another way to guarantee
> > that the full instruction get
On Thu, Nov 29, 2018 at 04:16:27PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, memory
> information in SRAT table is necessary.
>
> ACPI SRAT (System/Static Resource Affinity Table) can show the details
> about memory ranges, including ranges of memory provided
On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
> Signed-
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote:
>
> We can. At least in theory. The problem is that depending on the
> crazy mapping from physical and kernel virtual address to dma addresses
> these might be pages at pretty random places. Look at fun like
> arch/x86/pci/sta2x11-fixup.c
On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are
To enable the OS initiated mode, the CPU topology needs to be described
using the hierarchical model in DT. When used, the idle state bits for the
CPU are created by ORing the bits for PM domain's idle state.
Let's prepare the PSCI driver to deal with this, via introducing a per CPU
variable calle
Let's split the psci_dt_cpu_init_idle() function into two functions, as to
allow following changes to re-use some of the code.
Cc: Lina Iyer
Co-developed-by: Lina Iyer
Signed-off-by: Ulf Hansson
---
Changes in v10:
- None.
---
drivers/firmware/psci/psci.c | 42 ---
From: Lina Iyer
Knowing the sleep duration of CPUs, is known to be needed while selecting
the most energy efficient idle state for a CPU or a group of CPUs.
However, to be able to compute the sleep duration, we need to know at what
time the next expected wakeup is for the CPU. Therefore, let's e
As it's now perfectly possible that a PM domain managed by genpd contains
devices belonging to CPUs, we should start to take into account the
residency values for the idle states during the state selection process.
The residency value specifies the minimum duration of time, the CPU or a
group of CP
Instead of iterating through all the state nodes in DT, to find out how
many states that needs to be allocated, let's use the number already known
by the cpuidle driver. In this way we can drop the iteration altogether.
Signed-off-by: Ulf Hansson
---
Changes in v10:
- New patch.
---
dr
To enable a device belonging to a CPU to be attached to a PM domain managed
by genpd, let's do a few changes to it, as to make it convenient to manage
the specifics around CPUs.
To be able to quickly find out what CPUs that are attached to a genpd,
which typically becomes useful from a genpd gover
From: Lina Iyer
Update DT bindings to represent hierarchical CPU and CPU PM domain idle
states for PSCI. Also update the PSCI examples to clearly show how
flattened and hierarchical idle states can be represented in DT.
Cc: Lina Iyer
Signed-off-by: Lina Iyer
Co-developed-by: Ulf Hansson
Signe
From: Lina Iyer
Currently CPU's idle states are represented in a flattened model, via the
"cpu-idle-states" binding from within the CPU's device nodes.
Support the hierarchical layout during parsing and validating of the CPU's
idle states. This is simply done by calling the new OF helper,
of_get
When the hierarchical CPU topology is used and when a CPU has been put
offline (hotplug), that same CPU prevents its PM domain and thus also
potential master PM domains, from being powered off. This is because genpd
observes the CPU's struct device to remain being active from a runtime PM
point of
Following changes are about to implement support for PM domains to PSCI.
Those changes are mainly going to be implemented in a new separate file,
hence a couple of the internal PSCI functions needs to be shared to be
accessible. So, let's do that via adding new PSCI header file.
Moreover, the chan
In order to allow the CPU to be power managed through a potential PM domain
and the corresponding topology, it needs to be attached to it. For that
reason, check if the PM domain data structures have been initiated for PSCI
and if so, let's try to attach the CPU device to its PM domain.
However, b
To enable the OS to manage last-man standing activities for a CPU, while an
idle state for a group of CPUs is selected, let's convert the Hikey
platform into using the hierarchical CPU topology layout.
Signed-off-by: Ulf Hansson
---
Changes in v10:
- New patch.
---
arch/arm64/boot/dts/
Introduce a new PSCI DT helper function, psci_dt_attach_cpu(), which takes
a CPU number as an in-parameter and attaches the CPU's struct device to its
corresponding PM domain. Additionally, the helper prepares the CPU to be
power managed via runtime PM, which is the last step needed to enable the
i
If the hierarchical CPU topology is used, but the OS initiated mode isn't
supported, we rely solely on the regular cpuidle framework to manage the
idle state selection.
For this reason, introduce a new PSCI DT helper function,
psci_dt_pm_domains_parse_states(), which converts the hierarchically
de
When the hierarchical CPU topology layout is used in DT, let's allow the
CPU to be power managed through its PM domain and via runtime PM. In other
words, let's deploy runtime PM support to the PSCI driver during idle
management of the CPU.
Signed-off-by: Ulf Hansson
---
Changes in v10:
From: Lina Iyer
In the hierarchical layout, we are creating power domains around each CPU
and describes the idle states for them inside the power domain provider
node. Note that, the CPU's idle states still needs to be compatible with
"arm,idle-state".
Furthermore, represent the CPU cluster as a
To let the PSCI driver parse for the hierarchical CPU topology in DT and
thus potentially initiate the corresponding PM domain data structures,
let's call psci_dt_topology_init() from the existing topology_init()
subsys_initcall.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Lina Iyer
Co-developed-by
From: Lina Iyer
Currently CPU's idle states are represented in a flattened model, via the
"cpu-idle-states" binding from within the CPU's device nodes.
Support the hierarchical layout, simply by converting to calling the new OF
helper, of_get_cpu_state_node().
Cc: Lina Iyer
Suggested-by: Sudee
Instead of having each psci init function taking care of the of_node_put(),
let's deal with that from psci_dt_init(), as this enables a bit simpler
error path for each psci init function.
Cc: Lina Iyer
Co-developed-by: Lina Iyer
Signed-off-by: Ulf Hansson
Acked-by: Mark Rutland
---
Changes in
The files for the PSCI firmware driver were moved to a sub-directory, let's
update MAINTAINERS to reflect that.
Suggested-by: Mark Rutland
Signed-off-by: Ulf Hansson
---
Changes in v10:
- None.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAIN
To be able to initiate the PM domain data structures, let's export a new
init function, psci_dt_topology_init() and make it call
psci_dt_init_pm_domains(). Following changes to the ARM64 code, invokes
this new init function.
At first glance, it may seem like feasible idea to hook into the existing
To allow arch back-end init ops to operate on the cpuidle driver for the
corresponding CPU, let's pass along a pointer to the struct cpuidle_driver*
and forward it the relevant layers of callbacks for ARM/ARM64.
Following changes for the PSCI firmware driver starts making use of this.
Cc: Lina Iy
Some following changes extends the PSCI driver with some additional new
files. Let's avoid to continue cluttering the toplevel firmware directory
and first move the PSCI files into a PSCI sub-directory.
Suggested-by: Mark Rutland
Signed-off-by: Ulf Hansson
---
Changes in v10:
- None.
When the hierarchical CPU topology layout is used in DT, we need to setup
the corresponding PM domain data structures, as to allow a CPU and a group
of CPUs to be power managed accordingly. Let's enable this by deploying
support through the genpd interface.
Additionally, when the OS initiated mode
PSCI firmware v1.0+, supports two different modes for CPU_SUSPEND. The
Platform Coordinated mode, which is the default and mandatory mode, while
support for the OS initiated mode is optional.
This change introduces initial support for the OS initiated mode, in way
that it adds the related PSCI bit
The CPU's idle state nodes are currently parsed at the common cpuidle DT
library, but also when initializing back-end data for the arch specific CPU
operations, as in the PSCI driver case.
To avoid open-coding, let's introduce of_get_cpu_state_node(), which takes
the device node for the CPU and th
Let's add a data pointer to the genpd_power_state struct, to allow a genpd
backend driver to store per state specific data. In order to introduce the
pointer, we also need to adopt how genpd frees the allocated data for the
default genpd_power_state struct, that it may allocate at pm_genpd_init().
Over the years this series have been iterated and discussed at various Linux
conferences and LKML. In this new v10, a quite significant amount of changes
have been made to address comments from v8 and v9. A summary is available
below, although let's start with a brand new clarification of the motiv
On Thu, 29 Nov 2018 09:41:33 -0800
Andy Lutomirski wrote:
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are args
On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
>
> Well, the current method (as Jiri mentioned) did get the OK from at
> least Intel (and that was with a lot of arm twisting to do so).
Guys, when the comparison is to:
- create a huge honking security hole by screwing up the stack frame
> On Nov 29, 2018, at 9:45 AM, Josh Poimboeuf wrote:
>
>> On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>>
>>> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>>>
>>> On Thu, 29 Nov 2018 12:20:00 -0500
>>> Steven Rostedt wrote:
>>>
>>>
r8 = return address
r
On Thu, Nov 29, 2018 at 9:50 AM Linus Torvalds
wrote:
>
> - corrupt random registers because we "know" they aren't in use
Just to clarify: I think that's a completely unacceptable model.
We already have lots of special calling conventions, including ones
that do not have any call-clobbered regi
On Thu, Nov 29, 2018 at 04:16:30PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, SRAT table
> should be parsed by RSDP pointer, then find the immovable
> memory regions and store them in an array called immovable_mem[].
> The array called immovable_mem[] will exte
On 11/29/2018 12:27 PM, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 12:02:19PM -0500, Waiman Long wrote:
>> On 11/29/2018 11:06 AM, Peter Zijlstra wrote:
>>> Why; at that point we know the wakeup will happen after, which is all we
>>> require.
>>>
>> Thread 1 Th
On Thu, 29 Nov 2018 09:50:28 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
> >
> > Well, the current method (as Jiri mentioned) did get the OK from at
> > least Intel (and that was with a lot of arm twisting to do so).
>
> Guys, when the comparison is to:
> On Nov 29, 2018, at 9:50 AM, Linus Torvalds
> wrote:
>
>> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote:
>>
>> Well, the current method (as Jiri mentioned) did get the OK from at
>> least Intel (and that was with a lot of arm twisting to do so).
>
> Guys, when the comparison is to:
+++ Miroslav Benes [29/11/18 09:18 +0100]:
On Fri, 23 Nov 2018, Jessica Yu wrote:
The module loader internally works with both exported symbols
represented as struct kernel_symbol, as well as Elf symbols from a
module's symbol table. It's hard to distinguish sometimes which type of
symbol we're
On Tue, Nov 27, 2018 at 05:55:38PM +0100, Andrey Konovalov wrote:
> Tag-based KASAN inline instrumentation mode (which embeds checks of shadow
> memory into the generated code, instead of inserting a callback) generates
> a brk instruction when a tag mismatch is detected.
>
> This commit adds a ta
On Tue, Nov 27, 2018 at 05:55:41PM +0100, Andrey Konovalov wrote:
> Now, that all the necessary infrastructure code has been introduced,
> select HAVE_ARCH_KASAN_SW_TAGS for arm64 to enable software tag-based
> KASAN mode.
>
> Signed-off-by: Andrey Konovalov
> ---
> arch/arm64/Kconfig | 1 +
> 1
On Wed, Nov 28, 2018 at 8:05 PM tom burkart wrote:
>
> Quoting Rob Herring :
>
> > On Mon, Nov 26, 2018 at 9:57 PM tom burkart wrote:
> >>
> >> Quoting Rob Herring :
> >>
> >> > On Sat, Nov 17, 2018 at 6:35 PM tom burkart wrote:
> >> >>
> >> >> Quoting Rob Herring :
> >> >>
> >> >> > On Sat, Nov
This file uses "task" 85 times and "tsk" 25 times. It should be better to
choose one of these variants.
Signed-off-by: Andrei Vagin
---
include/linux/sched/signal.h | 51 ++--
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/include/linux/sched/sign
On Thu, Nov 29, 2018 at 12:38:24PM -0500, a...@adamwong.me wrote:
> From: Adam Wong
>
> Added the ability to detect the ELAN0621 touchpad found in some Lenovo
> laptops.
>
> Signed-off-by: Adam Wong
Applied, thank you.
> ---
> drivers/input/mouse/elan_i2c_core.c | 1 +
> 1 file changed, 1 in
On Thu, Nov 29, 2018 at 06:27:00PM +0100, Peter Zijlstra wrote:
>
> wake_up_q() should, per the barriers in wake_up_process, ensure that if
> wake_a_add() fails, there will be a wakeup of that task after that
> point.
>
> So if we put wake_up_q() at the location where wake_up_process() should
> b
From: Colin Ian King
Currently the node name is being formatting into a temporary string
node_name, however, kobject_init_and_add allows one to format up
a node name, so use that instead. This removes the need for the
node_name string and also cleans up the following warning:
Fixes clang warning
On Tue, Nov 27, 2018 at 06:47:10PM -0800, Cameron Gutman wrote:
> Since we continue to find tons of new variants [0,1,2,3,4,5,6] that
> need the PDP quirk, let's just quirk all devices from PDP.
>
> [0]: https://github.com/paroj/xpad/pull/104
> [1]: https://github.com/paroj/xpad/pull/105
> [2]: ht
On 28.11.18 16:28, Boris Brezillon wrote:
> On Wed, 28 Nov 2018 15:19:37 +
> Schrempf Frieder wrote:
>
>> On 28.11.18 16:02, Boris Brezillon wrote:
>>> On Wed, 28 Nov 2018 14:55:45 +
>>> Schrempf Frieder wrote:
>>>
Hi Boris,
On 28.11.18 15:41, Boris Brezillon wrote:
>>
On Wed, Nov 28, 2018 at 05:08:45PM -0500, Qian Cai wrote:
> Kmemleak does not play well with KASAN (tested on both HPE Apollo 70 and
> Huawei TaiShan 2280 aarch64 servers).
>
> After calling start_kernel()->setup_arch()->kasan_init(), kmemleak early
> log buffer went from something like 280 to 260
stable-rc/linux-4.19.y boot: 119 boots: 0 failed, 116 passed with 3 offline
(v4.19.5-111-gac4af649901b)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.5-111-gac4af649901b/
Full Build Summary:
https://kernelci.org/build/stable-rc/branch/linux-4.19
On Mon, Nov 12, 2018 at 11:56:56AM +, Julien Thierry wrote:
> Mask the IRQ priority through PMR and re-enable IRQs at CPU level,
> allowing only higher priority interrupts to be received during interrupt
> handling.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
>
On Thu, Nov 29, 2018 at 12:58:26PM -0500, Waiman Long wrote:
> OK, you convinced me. However, that can still lead to anonymous wakeups
> that can be problematic if it happens in certain places. Should we try
> to reduce anonymous wakeup as much as possible?
No, we should at all times accept and ex
niedz., 25 lis 2018 o 22:18 Uwe Kleine-König
napisał(a):
>
> On Fri, Nov 23, 2018 at 04:59:46PM +0100, Bartosz Golaszewski wrote:
> > śr., 21 lis 2018 o 20:15 Uwe Kleine-König
> > napisał(a):
> > >
> > > Hello Bartosz,
> > >
> > > On Wed, Nov 21, 2018 at 05:34:32PM +0100, Bartosz Golaszewski wrot
On Thu, 29 Nov 2018, Peter Zijlstra wrote:
On Thu, Nov 29, 2018 at 12:58:26PM -0500, Waiman Long wrote:
OK, you convinced me. However, that can still lead to anonymous wakeups
that can be problematic if it happens in certain places. Should we try
to reduce anonymous wakeup as much as possible?
On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
>
> Do you realize that the cmpxchg used by the first attempts of the
> dynamic modification of code by ftrace was the source of the e1000e
> NVRAM corruption bug.
If you have a static call in IO memory, you have bigger problems than that.
Wh
On 11/29/2018 01:08 PM, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 06:27:00PM +0100, Peter Zijlstra wrote:
>> wake_up_q() should, per the barriers in wake_up_process, ensure that if
>> wake_a_add() fails, there will be a wakeup of that task after that
>> point.
>>
>> So if we put wake_up_q() a
Without this patch, the thermal driver on hi6220 and hi3660 is broken.
That is due because part of the posted patchset was merged but a small
change in the DT was dropped.
The hi6220 and hi3660 do not have an interrupt name in the DT, so
finding interrupt by name fails.
In addition, the hi3660 o
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.20-rc4]
[cannot apply to next-20181129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Sorry typo in Vincent's email address, fixed now.
On 29/11/2018 19:26, Daniel Lezcano wrote:
> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>
> That is due because part of the posted patchset was merged but a small
> change in the DT was dropped.
>
> The hi6220 and hi
On Thu, Nov 29, 2018 at 01:26:34PM -0500, Waiman Long wrote:
> On 11/29/2018 01:08 PM, Peter Zijlstra wrote:
> > Hmm, I think we're missing a barrier in wake_q_add(); when cmpxchg()
> > fails we still need an smp_mb().
> >
> > Something like so.
> >
> > diff --git a/kernel/sched/core.c b/kernel/sch
ср, 28 нояб. 2018 г. в 18:20, Long Li :
>
> > Subject: Re: [Patch v4 2/3] CIFS: Add support for direct I/O write
> >
> > ср, 31 окт. 2018 г. в 15:26, Long Li :
> > >
> > > From: Long Li
> > >
> > > With direct I/O write, user supplied buffers are pinned to the memory
> > > and data are transferred
On 11/29/2018 01:31 PM, Will Deacon wrote:
> On Thu, Nov 29, 2018 at 01:26:34PM -0500, Waiman Long wrote:
>> On 11/29/2018 01:08 PM, Peter Zijlstra wrote:
>>> Hmm, I think we're missing a barrier in wake_q_add(); when cmpxchg()
>>> fails we still need an smp_mb().
>>>
>>> Something like so.
>>>
>>>
On Thu, Nov 29, 2018 at 09:24:17AM -0800, Tomasz Figa wrote:
> Whether the cache maintenance operation needs to actually do anything
> or not is a function of `dev`. We can have some devices that are
> coherent with CPU caches, and some that are not, on the same system.
Yes, but that part is not d
Hi Yangtao,
On Wed, Nov 21, 2018 at 09:35:13AM -0500, Yangtao Li wrote:
> use of_node_put() to release the refcount.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/input/serio/i8042-sparcio.h | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/driv
On Thu, Nov 29, 2018 at 06:15:39PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,
>
> > and convince yourself that there isn’t a better solution
> > (like pointin
śr., 28 lis 2018 o 11:43 Linus Walleij napisał(a):
>
> We noticed a refcounting fight between the kernel device
> core devm_* and the regulator core refcounting, pertaining
> to enable GPIOd:s that may be shared between multiple
> regulators.
>
> Fix this with a series that hand it all over to the
* Update AMD cpu microcode for processor family 17h
Key Name= AMD Microcode Signing Key (for signing microcode container
files only)
Key ID = F328AE73
Key Fingerprint = FC7C 6C50 5DAF CC14 7183 57CA E4BE 5339 F328 AE73
Signed-off-by: John Allen
---
WHENCE
On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski wrote:
> > then it really sounds pretty safe to just say "ok, just make it
> > aligned and update the instruction with an atomic cmpxchg or
> > something".
>
> And how do we do that? With a gcc plugin and some asm magic?
Asm magic.
You already ha
On Thu, 29 Nov 2018, Peter Zijlstra wrote:
On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
Yes, I think this is real, and worse, I think we need to go audit all
wake_q_add() users and document this behaviour.
In the ideal case we'd delay the actual wakeup to the last wake_up_q(
On Thu, 29 Nov 2018 10:23:44 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt wrote:
> >
> > Do you realize that the cmpxchg used by the first attempts of the
> > dynamic modification of code by ftrace was the source of the e1000e
> > NVRAM corruption bug.
>
> If y
On 11/29/2018 01:43 PM, Davidlohr Bueso wrote:
> On Thu, 29 Nov 2018, Peter Zijlstra wrote:
>
>> On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote:
>>> Yes, I think this is real, and worse, I think we need to go audit all
>>> wake_q_add() users and document this behaviour.
>>>
>>> In t
ср, 28 нояб. 2018 г. в 15:43, Long Li :
>
> > Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
> >
> > Hi Long,
> >
> > Please find my comments below.
> >
> >
> > ср, 31 окт. 2018 г. в 15:14, Long Li :
> > >
> > > From: Long Li
> > >
> > > With direct I/O read, we transfer the dat
On Thu, 29 Nov 2018 10:00:48 -0800
Andy Lutomirski wrote:
> >
> > Of course, another option is to just say "we don't do the inline case,
> > then", and only ever do a call to a stub that does a "jmp"
> > instruction.
>
> That’s not a terrible idea.
It was the implementation of my first proof
> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, November 29, 2018 7:01 AM
> To: Jean Delvare
> Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jean-Marc Lenoir
> ; Schmauss, Erik ;
> Wysocki, Rafael J
> Subject: Re: [PATCH
On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
>> A warning is generated when a PCIe device is probed with a degraded
>> link, but there was no similar mechanism to warn when the link becomes
>> degraded after probing. The Link Band
On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
>
> Note, we do have a bit of control at what is getting called. The patch
> set requires that the callers are wrapped in macros. We should not
> allow just any random callers (like from asm).
Actually, I'd argue that asm is often more contro
On 11/29/2018 10:06 AM, Mika Westerberg wrote:
>> @@ -515,7 +515,8 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
>> struct controller *ctrl = (struct controller *)dev_id;
>> struct pci_dev *pdev = ctrl_dev(ctrl);
>> struct device *parent = pdev->dev.parent;
>> -u16 stat
On Thu, Nov 29, 2018 at 07:38:20PM +0100, Bartosz Golaszewski wrote:
> I'm wondering if instead of using the non-devm variants of
> gpiod_get_*() routines, we shouldn't provide helpers in the regulator
> framework that would be named accordingly, for example:
> regulator_gpiod_get_optional() etc.
On 11/28/2018 06:24 AM, Thomas Gleixner wrote:
>
> I've integrated the latest review feedback and the change which plugs the
> TIF async update issue and pushed all of it out to:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/pti
>
> For the stable 4.14.y and 4.19.y trees,
Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
(SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
unexpected tuning pattern errors. A small failure band may be present
in the tuning range which may be missed by the current algorithm.
Furthermore, the failure bands vary wi
On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
wrote:
>
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.
Actually, I think I have a better model - if the caller is done with inline asm.
What you can do t
On Thu, 29 Nov 2018 11:08:26 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
wrote:
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
Hmm. the segment prefixes are documented as being "reserved"
On Thu, Nov 29, 2018 at 06:57:37PM +, alex_gagn...@dellteam.com wrote:
> On 11/29/2018 11:36 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> >> A warning is generated when a PCIe device is probed with a degraded
> >> link, but there was no simil
On Thu, 29 Nov 2018 10:58:40 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random caller
On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
wrote:
>
>
>> On Nov 29, 2018, at 4:28 AM, Florian Weimer
>wrote:
>>
>> Disclaimer: I'm looking at this patch because Christian requested it.
>> I'm not a kernel developer.
>>
>> * Christian Brauner:
>>
>>> diff --git a/arch/x86/entry
On Thu, Nov 29, 2018 at 06:56:40PM +, Schmauss, Erik wrote:
>
>
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, November 29, 2018 7:01 AM
> > To: Jean Delvare
> > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Jea
On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > and honestly, the way "static_call()" works now, can you guarantee
> > that the call-site doesn't end up doing that, and calling the
> > trampoline function for two different static calls from one indirect
> > call?
> >
> > See wh
On Thu, 29 Nov 2018, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> >> On Nov 28, 2018, at 5:07 AM, Thomas Gleixner wrote:
> >>
> >> On Wed, 28 Nov 2018, Vitaly Kuznetsov wrote:
> >>
> >>> Nadav Amit writes:
> >>>
> On a different note: how come all of the hyper-v structs are not mark
On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner wrote:
>
> On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski
> wrote:
> >
> >
> >> On Nov 29, 2018, at 4:28 AM, Florian Weimer
> >wrote:
> >>
> >> Disclaimer: I'm looking at this patch because Christian requested it.
> >> I'm not a ker
On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote:
>
> But then we need to implement all numbers of parameters.
Oh, I agree, it's nasty.
But it's actually a nastiness that we've solved before. In particular,
with the system call mappings, which have pretty much the exact same
issue of "map u
On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
> I spent some more time looking at this today...
>
> On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> > Doing some more debugging, it looks like the usual failure case is where
> > one CPU clears the inode field in the den
901 - 1000 of 1374 matches
Mail list logo
