Currently cpu_use_smt_and_hotplug is only set during boot time
to indicate if SMT is in use.
However, CPU topology may change and when the last SMT thread is offlined,
the SMT code path can be skipped. The sched_smt_present key detects
this condition.
Export sched_smt_present and incorporate it
Create PRCTL interface to restrict an application's indirect branch
speculation. This will protect the application against spectre v2 attack
from another application.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIR_BRANCH, 0, 0, 0);
On 11/20/18 10:11 PM, Rafael David Tinoco wrote:
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at
On 11/20/18 10:11 PM, Rafael David Tinoco wrote:
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at addr by task mkfs.ext4/623
CPU: 2 PID: 623
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break, causing:
BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
Read of size 4 at addr by task mkfs.ext4/623
CPU: 2 PID: 623
SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO
routed to the PDC as interrupts that can be used to wake the system up
from deep low power modes and suspend.
Signed-off-by: Lina Iyer
---
.../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++-
1 file
SDM845 SoC has an always-on interrupt controller (PDC) with select GPIO
routed to the PDC as interrupts that can be used to wake the system up
from deep low power modes and suspend.
Signed-off-by: Lina Iyer
---
.../bindings/pinctrl/qcom,sdm845-pinctrl.txt | 31 ++-
1 file
Signed-off-by: Lina Iyer
---
drivers/pinctrl/qcom/pinctrl-msm.c | 125 -
1 file changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 7c7d083e2c0d..3857aa5539e0 100644
---
Signed-off-by: Lina Iyer
---
drivers/pinctrl/qcom/pinctrl-msm.c | 125 -
1 file changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 7c7d083e2c0d..3857aa5539e0 100644
---
Add PDC wakeup irq for GPIOs and the wakeup parent for TLMM.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index
Hi,
This is an attempt at using GPIO as wake up sources. Based on discussions with
Stephen and Marc [1], the idea that is used here is to make PDC interrupt
controller the parent of TLMM irqchip. Wakeup capable GPIO IRQs have
corresponding parent interrupt in PDC and therefore the GIC. The TLMM
Add PDC wakeup irq for GPIOs and the wakeup parent for TLMM.
Signed-off-by: Lina Iyer
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index
Hi,
This is an attempt at using GPIO as wake up sources. Based on discussions with
Stephen and Marc [1], the idea that is used here is to make PDC interrupt
controller the parent of TLMM irqchip. Wakeup capable GPIO IRQs have
corresponding parent interrupt in PDC and therefore the GIC. The TLMM
Some documents are refering to others without links. With this
patch I add those missing links.
This patch affects only documents under process/ and labels where
necessary.
Signed-off-by: Federico Vaga
---
Documentation/admin-guide/devices.rst| 1 +
Some documents are refering to others without links. With this
patch I add those missing links.
This patch affects only documents under process/ and labels where
necessary.
Signed-off-by: Federico Vaga
---
Documentation/admin-guide/devices.rst| 1 +
Hi Leon,
Today's linux-next merge of the mlx5-next tree got a conflict in:
drivers/infiniband/hw/mlx5/main.c
between commit:
9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity")
from the rdma tree and commit:
f2f3df550139 ("net/mlx5: EQ, Privatize eq_table and friends")
Hi Leon,
Today's linux-next merge of the mlx5-next tree got a conflict in:
drivers/infiniband/hw/mlx5/main.c
between commit:
9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity")
from the rdma tree and commit:
f2f3df550139 ("net/mlx5: EQ, Privatize eq_table and friends")
On Tue, 20 Nov 2018, Jan Kara wrote:
> > Even though vma flags exported via /proc//smaps are explicitly
> > documented to be not guaranteed for future compatibility the warning
> > doesn't go far enough because it doesn't mention semantic changes to
> > those flags. And they are important as well
On Tue, 20 Nov 2018, Jan Kara wrote:
> > Even though vma flags exported via /proc//smaps are explicitly
> > documented to be not guaranteed for future compatibility the warning
> > doesn't go far enough because it doesn't mention semantic changes to
> > those flags. And they are important as well
On Mon, Nov 19, 2018 at 6:09 AM Ardelean, Alexandru
wrote:
>
> On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote:
> > This patch adds device tree support to ad2s90 with standard
> > device tree id table.
> >
>
> Hey,
>
> Comment inline
>
> > Signed-off-by: Matheus Tavares
> > ---
> >
On Mon, Nov 19, 2018 at 6:09 AM Ardelean, Alexandru
wrote:
>
> On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote:
> > This patch adds device tree support to ad2s90 with standard
> > device tree id table.
> >
>
> Hey,
>
> Comment inline
>
> > Signed-off-by: Matheus Tavares
> > ---
> >
On Wed, 2018-11-21 at 00:54 +0100, Qian Cai wrote:
> On 11/20/18 at 6:38 PM, Waiman Long wrote:
> > On 11/20/2018 06:28 PM, Qian Cai wrote:
> > > The current value of the early boot static pool size is not big enough
> > > for systems with large number of CPUs with timer or/and workqueue
> > >
On Wed, 2018-11-21 at 00:54 +0100, Qian Cai wrote:
> On 11/20/18 at 6:38 PM, Waiman Long wrote:
> > On 11/20/2018 06:28 PM, Qian Cai wrote:
> > > The current value of the early boot static pool size is not big enough
> > > for systems with large number of CPUs with timer or/and workqueue
> > >
On 11/20/18 at 6:38 PM, Waiman Long wrote:
> On 11/20/2018 06:28 PM, Qian Cai wrote:
> > The current value of the early boot static pool size is not big enough
> > for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with
On 11/20/18 at 6:38 PM, Waiman Long wrote:
> On 11/20/2018 06:28 PM, Qian Cai wrote:
> > The current value of the early boot static pool size is not big enough
> > for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with
On Tue, 20 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 14:16:24, David Rientjes wrote:
> > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
> >
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> >
> > As I noted when this patch was originally
On Tue, 20 Nov 2018, Michal Hocko wrote:
> On Mon 19-11-18 14:16:24, David Rientjes wrote:
> > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
> >
> > > 4.4-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> >
> > As I noted when this patch was originally
On 11/20/2018 11:27 PM, Jiri Kosina wrote:
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
In the documentation, AMD officially recommends against this by default,
and I can speak for Intel that our position is that as well: this really
must not be on by default.
Thanks for pointing to the AMD
On 11/20/2018 11:27 PM, Jiri Kosina wrote:
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
In the documentation, AMD officially recommends against this by default,
and I can speak for Intel that our position is that as well: this really
must not be on by default.
Thanks for pointing to the AMD
On 11/20/2018 06:28 PM, Qian Cai wrote:
> The current value of the early boot static pool size is not big enough
> for systems with large number of CPUs with timer or/and workqueue
> objects selected. As the results, systems have 60+ CPUs with both timer
> and workqueue objects enabled could
On 11/20/2018 06:28 PM, Qian Cai wrote:
> The current value of the early boot static pool size is not big enough
> for systems with large number of CPUs with timer or/and workqueue
> objects selected. As the results, systems have 60+ CPUs with both timer
> and workqueue objects enabled could
On Mon, Nov 19, 2018 at 6:22 AM Ardelean, Alexandru
wrote:
>
> On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote:
> > This patch adds the device tree binding documentation for the ad2s90
> > resolver-to-digital converter.
> >
>
> One minor comment inline.
>
> > Signed-off-by: Matheus
On Mon, Nov 19, 2018 at 6:22 AM Ardelean, Alexandru
wrote:
>
> On Sun, 2018-11-18 at 02:25 -0200, Matheus Tavares wrote:
> > This patch adds the device tree binding documentation for the ad2s90
> > resolver-to-digital converter.
> >
>
> One minor comment inline.
>
> > Signed-off-by: Matheus
The current value of the early boot static pool size is not big enough
for systems with large number of CPUs with timer or/and workqueue
objects selected. As the results, systems have 60+ CPUs with both timer
and workqueue objects enabled could trigger "ODEBUG: Out of memory.
ODEBUG disabled".
The current value of the early boot static pool size is not big enough
for systems with large number of CPUs with timer or/and workqueue
objects selected. As the results, systems have 60+ CPUs with both timer
and workqueue objects enabled could trigger "ODEBUG: Out of memory.
ODEBUG disabled".
This adds a test module in lib/, and a script in kselftest that does
benchmarking on the allocation of memory in the module space. Performance here
would have some small impact on kernel module insertions, BPF JIT insertions
and kprobes. In the case of KASLR features for the module space, this
This adds a test module in lib/, and a script in kselftest that does
benchmarking on the allocation of memory in the module space. Performance here
would have some small impact on kernel module insertions, BPF JIT insertions
and kprobes. In the case of KASLR features for the module space, this
Add debugfs file "modfraginfo" for providing info on module space fragmentation.
This can be used for determining if loadable module randomization is causing any
problems for extreme module loading situations, like huge numbers of modules or
extremely large modules.
Sample output when KASLR is
Resending this because I missed Jessica in the "to" list. Also removing the part
of this coverletter that talked about KPTI helping with some local kernel text
de-randomizing methods, because I'm not sure I fully understand this.
This
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address without triggering any lazy purging and retry. For the randomized
allocator that uses this function, failing to allocate at a specific address is
a lot more common. This function will not try to do any lazy purge
Add debugfs file "modfraginfo" for providing info on module space fragmentation.
This can be used for determining if loadable module randomization is causing any
problems for extreme module loading situations, like huge numbers of modules or
extremely large modules.
Sample output when KASLR is
Resending this because I missed Jessica in the "to" list. Also removing the part
of this coverletter that talked about KPTI helping with some local kernel text
de-randomizing methods, because I'm not sure I fully understand this.
This
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address without triggering any lazy purging and retry. For the randomized
allocator that uses this function, failing to allocate at a specific address is
a lot more common. This function will not try to do any lazy purge
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged.
It refactors
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged.
It refactors
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
+ /* Holds the resul of the last successful call to tpm_transmit() */
>>> This comment is cruft.
>> Do you want me to remove it? This is the comment you proposed.
> As I explained before it made sense before you made the remark that
> it can only
On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
+ /* Holds the resul of the last successful call to tpm_transmit() */
>>> This comment is cruft.
>> Do you want me to remove it? This is the comment you proposed.
> As I explained before it made sense before you made the remark that
> it can only
On Tue, 20 Nov 2018, Kars de Jong wrote:
> Op ma 19 nov. 2018 om 02:10 schreef Finn Thain :
> >
> > hp300_gettimeoffset() never checks the timer interrupt flag and will
> > fail to notice when the timer counter gets reloaded. That means the
> > clock could jump backwards.
> >
> > Remove this code
On Tue, 20 Nov 2018, Kars de Jong wrote:
> Op ma 19 nov. 2018 om 02:10 schreef Finn Thain :
> >
> > hp300_gettimeoffset() never checks the timer interrupt flag and will
> > fail to notice when the timer counter gets reloaded. That means the
> > clock could jump backwards.
> >
> > Remove this code
Andy,
On Mon, Nov 5, 2018 at 1:09 PM Douglas Anderson wrote:
>
> As per upstream discussion [1], we should have an SoC-specific
> compatible string for Qualcomm's SDHCI nodes. Let's add it.
>
> [1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
>
> Signed-off-by: Douglas Anderson
> ---
Andy,
On Mon, Nov 5, 2018 at 1:09 PM Douglas Anderson wrote:
>
> As per upstream discussion [1], we should have an SoC-specific
> compatible string for Qualcomm's SDHCI nodes. Let's add it.
>
> [1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
>
> Signed-off-by: Douglas Anderson
> ---
On Tue, Nov 20, 2018 at 10:30:32AM -0800, Tadeusz Struk wrote:
> On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
> >> The usecase is implemented in this TSS commit:
> >> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> > Can you implement test for this to
> >
On Tue, Nov 20, 2018 at 10:30:32AM -0800, Tadeusz Struk wrote:
> On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
> >> The usecase is implemented in this TSS commit:
> >> https://github.com/tpm2-software/tpm2-tss/commit/ce982f67a67dc08e24683d30b05800648d8a264c
> > Can you implement test for this to
> >
On Tue, Nov 20, 2018 at 10:36:14AM -0800, Tadeusz Struk wrote:
> On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
> >> + /* Holds the resul of the last successful call to tpm_transmit() */
> > This comment is cruft.
>
> Do you want me to remove it? This is the comment you proposed.
As I explained
On Tue, Nov 20, 2018 at 10:36:14AM -0800, Tadeusz Struk wrote:
> On 11/20/18 4:48 AM, Jarkko Sakkinen wrote:
> >> + /* Holds the resul of the last successful call to tpm_transmit() */
> > This comment is cruft.
>
> Do you want me to remove it? This is the comment you proposed.
As I explained
Fix of_node* refcount at various places by using of_node_put.
Signed-off-by: Atish Patra
---
arch/riscv/kernel/cacheinfo.c | 11 +++
arch/riscv/kernel/cpu.c| 1 +
arch/riscv/kernel/cpufeature.c | 2 ++
arch/riscv/kernel/perf_event.c | 1 +
arch/riscv/kernel/smpboot.c| 6
Fix of_node* refcount at various places by using of_node_put.
Signed-off-by: Atish Patra
---
arch/riscv/kernel/cacheinfo.c | 11 +++
arch/riscv/kernel/cpu.c| 1 +
arch/riscv/kernel/cpufeature.c | 2 ++
arch/riscv/kernel/perf_event.c | 1 +
arch/riscv/kernel/smpboot.c| 6
On 20/11/18 12:08 PM, J, KEERTHY wrote:
>
>
> On 11/20/2018 2:22 AM, Sekhar Nori wrote:
>> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski
>>>
>>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
>>> IRQ numbering") the davinci GPIO driver fails
On 20/11/18 12:08 PM, J, KEERTHY wrote:
>
>
> On 11/20/2018 2:22 AM, Sekhar Nori wrote:
>> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski
>>>
>>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
>>> IRQ numbering") the davinci GPIO driver fails
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a
On 20/11/2018 08:33, Ingo Molnar wrote:
[...]
> 6. Is x32 even used in practice? I still think it was a mistake to add it
>and some significant distributions like Fedora are not enabling it.
x32 works as far as gcc/gas/ld is concerned (at least for compiling
non-trivial programs).
Finding a
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote:
> What is "#GP with EPCM"? We certainly don't want to react to #UD in
A typo. Meant #PF with PF_SGX set i.e. EPCM conflict.
> general by mucking with some regs and retrying -- that will infinite
> loop and confuse everyone. I'm
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote:
> What is "#GP with EPCM"? We certainly don't want to react to #UD in
A typo. Meant #PF with PF_SGX set i.e. EPCM conflict.
> general by mucking with some regs and retrying -- that will infinite
> loop and confuse everyone. I'm
On Tue, Nov 20, 2018 at 09:01:11AM -0700, Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 03:08:05PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Nov 19, 2018 at 09:33:31PM +, Winkler, Tomas wrote:
> > >
> > > >
> > > > Decleare struct tpm_header that replaces struct tpm_input_header and
> > >
On Tue, Nov 20, 2018 at 09:01:11AM -0700, Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 03:08:05PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Nov 19, 2018 at 09:33:31PM +, Winkler, Tomas wrote:
> > >
> > > >
> > > > Decleare struct tpm_header that replaces struct tpm_input_header and
> > >
On Tue, Nov 20, 2018 at 12:11:33PM +0200, Jarkko Sakkinen wrote:
> On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen
> > wrote:
> > >
> > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote:
> > > > 1. The kernel
On Tue, Nov 20, 2018 at 12:11:33PM +0200, Jarkko Sakkinen wrote:
> On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote:
> > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen
> > wrote:
> > >
> > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wrote:
> > > > 1. The kernel
On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
>
> > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu,
> > + u64 *user, u64 *nice, u64 *system,
> > + u64 *guest,
On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
>
> > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu,
> > + u64 *user, u64 *nice, u64 *system,
> > + u64 *guest,
> In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> independent counters, because while one counter overflows, we'll stall
> counting on all others until we've handled the PMI.
>
> Even though the PMI might not be for them and they very much want/need
> to continue counting.
We
> In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> independent counters, because while one counter overflows, we'll stall
> counting on all others until we've handled the PMI.
>
> Even though the PMI might not be for them and they very much want/need
> to continue counting.
We
On Tue, Nov 20, 2018 at 02:28:13PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote:
> > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote:
> > > > On Sat, Nov 10,
On Tue, Nov 20, 2018 at 02:28:13PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote:
> > On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote:
> > > > On Sat, Nov 10,
On Tue, Nov 20, 2018 at 03:24:22PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 14, 2018 at 03:46:05AM +0100, Frederic Weisbecker wrote:
> > /* Copy values here to work around gcc-2.95.3, gcc-2.96 */
>
> Just a note to let you know the current minimum GCC version is 4.6 :-)
Yeah,
On Tue, Nov 20, 2018 at 03:24:22PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 14, 2018 at 03:46:05AM +0100, Frederic Weisbecker wrote:
> > /* Copy values here to work around gcc-2.95.3, gcc-2.96 */
>
> Just a note to let you know the current minimum GCC version is 4.6 :-)
Yeah,
On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote:
> On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote:
> > > On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote:
> > > > On Sat, Nov 10,
On 11/20/2018 4:42 PM, Keith Busch wrote:
How does that work? If the OS takes control, it sets up MSIs that FW don't
react to, and disables system errors through PCIe Root Control. Aren't
those sys errs the mechanism FW knows it has something to do, which
means the OS can effectively fence it
On Tue, Nov 20, 2018 at 12:42:43PM -0800, Joel Fernandes wrote:
> On Sun, Nov 11, 2018 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > On Sun, Nov 11, 2018 at 10:09:16AM -0800, Joel Fernandes wrote:
> > > On Sat, Nov 10, 2018 at 08:22:10PM -0800, Paul E. McKenney wrote:
> > > > On Sat, Nov 10,
On 11/20/2018 4:42 PM, Keith Busch wrote:
How does that work? If the OS takes control, it sets up MSIs that FW don't
react to, and disables system errors through PCIe Root Control. Aren't
those sys errs the mechanism FW knows it has something to do, which
means the OS can effectively fence it
Hello,
(Please update my email address).
On 13/11/2018 19:17:10+0200, Andy Shevchenko wrote:
> There are users which print time and date represented by content of
> struct rtc_time in human readable format.
>
> Instead of open coding that each time introduce %ptR[dt][rv] specifier.
>
> Note,
Hello,
(Please update my email address).
On 13/11/2018 19:17:10+0200, Andy Shevchenko wrote:
> There are users which print time and date represented by content of
> struct rtc_time in human readable format.
>
> Instead of open coding that each time introduce %ptR[dt][rv] specifier.
>
> Note,
On 20 November 2018 at 15:55, Sjoerd Simons
wrote:
> On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote:
>> On 20 November 2018 at 15:00, Sjoerd Simons
>> wrote:
>> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote:
>> > > + Hal Emmerich
>> > >
>> > > On 20 November 2018 at 12:38, Sjoerd
On 20 November 2018 at 15:55, Sjoerd Simons
wrote:
> On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote:
>> On 20 November 2018 at 15:00, Sjoerd Simons
>> wrote:
>> > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote:
>> > > + Hal Emmerich
>> > >
>> > > On 20 November 2018 at 12:38, Sjoerd
On Tue, Nov 20, 2018 at 11:16:42PM +0100, Peter Zijlstra wrote:
> Ooh, so the thing does FREEZE_ON_OVERFLOW _not_ FREEZE_ON_PMI. Yes, that
> can be a big difference.
>
> See, FREEZE_ON_PMI, as advertised by the name, should have no observable
> effect on counters limited to USR. But something
On Tue, Nov 20, 2018 at 11:16:42PM +0100, Peter Zijlstra wrote:
> Ooh, so the thing does FREEZE_ON_OVERFLOW _not_ FREEZE_ON_PMI. Yes, that
> can be a big difference.
>
> See, FREEZE_ON_PMI, as advertised by the name, should have no observable
> effect on counters limited to USR. But something
On Tue, Nov 20, 2018 at 01:46:05PM -0800, Kyle Huey wrote:
> On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote:
> >
> > > I suppose that's fair that it's better for some use cases. The flip
> > > side is that it's no longer possible to get exactly accurate counts
> > > from user space if you're
On Tue, Nov 20, 2018 at 01:46:05PM -0800, Kyle Huey wrote:
> On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote:
> >
> > > I suppose that's fair that it's better for some use cases. The flip
> > > side is that it's no longer possible to get exactly accurate counts
> > > from user space if you're
On Tue, Nov 20, 2018 at 12:11:44PM -0800, Andi Kleen wrote:
> > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > we'd ask that counter freezing be disabled for the 4.20 release.
> > >
> > > The boot option should be good enough for the release?
> >
> > I'm not
On Tue, Nov 20, 2018 at 12:11:44PM -0800, Andi Kleen wrote:
> > > > Given that we're already at rc3, and that this renders rr unusable,
> > > > we'd ask that counter freezing be disabled for the 4.20 release.
> > >
> > > The boot option should be good enough for the release?
> >
> > I'm not
Hi Eddie, Vlad, and Willem,
A few people mentioned to me that you guys were experiencing issues with
the percpu memory allocator. I saw the talk slides mention the
following two bullets:
1) allocation pattern makes the per cpu allocator reach a highly
fragmented state
2) sometimes takes a
Hi Eddie, Vlad, and Willem,
A few people mentioned to me that you guys were experiencing issues with
the percpu memory allocator. I saw the talk slides mention the
following two bullets:
1) allocation pattern makes the per cpu allocator reach a highly
fragmented state
2) sometimes takes a
On Thursday, November 8, 2018 5:51:52 PM CET Heikki Krogerus wrote:
> Hi,
>
> This is the second version of my proposal for this helper. The
> first version can be checked here:
> https://lkml.org/lkml/2018/11/5/326
>
> In order to support also ACPI properly, I decided to change the API.
> The
On Thursday, November 8, 2018 5:51:52 PM CET Heikki Krogerus wrote:
> Hi,
>
> This is the second version of my proposal for this helper. The
> first version can be checked here:
> https://lkml.org/lkml/2018/11/5/326
>
> In order to support also ACPI properly, I decided to change the API.
> The
Hi Linus,
Here are a few MIPS fixes for v4.20-rc4, please pull.
Thanks,
Paul
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
Hi Linus,
Here are a few MIPS fixes for v4.20-rc4, please pull.
Thanks,
Paul
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote:
>
> > I suppose that's fair that it's better for some use cases. The flip
> > side is that it's no longer possible to get exactly accurate counts
> > from user space if you're using the PMI (because any events between
> > the overflow itself and
On Tue, Nov 20, 2018 at 1:18 PM Andi Kleen wrote:
>
> > I suppose that's fair that it's better for some use cases. The flip
> > side is that it's no longer possible to get exactly accurate counts
> > from user space if you're using the PMI (because any events between
> > the overflow itself and
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> static void decompress_record(struct pstore_record *record)
> >> {
> >> + int ret;
> >> int
On Wed, Nov 14, 2018 at 01:56:09AM -0600, Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> static void decompress_record(struct pstore_record *record)
> >> {
> >> + int ret;
> >> int
301 - 400 of 1736 matches
Mail list logo
