On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
wrote:
>
> Recently syzbot reported crashes in send_sigio_to_task and
> send_sigurg_to_task in linux-next. Despite finding a reproducer
> syzbot apparently did not bisected this or otherwise track down the
> offending commit in linux-next.
>
> I
On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
wrote:
>
> Recently syzbot reported crashes in send_sigio_to_task and
> send_sigurg_to_task in linux-next. Despite finding a reproducer
> syzbot apparently did not bisected this or otherwise track down the
> offending commit in linux-next.
>
> I
Fix s/4.17/4.16/ typo.
Fixes: 8962e40c1993 ("docs: update kernel versions and dates in tables")
Cc: Tim Bird
Cc: Jonathan Corbet
Signed-off-by: Akinobu Mita
---
Documentation/process/2.Process.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Fix s/4.17/4.16/ typo.
Fixes: 8962e40c1993 ("docs: update kernel versions and dates in tables")
Cc: Tim Bird
Cc: Jonathan Corbet
Signed-off-by: Akinobu Mita
---
Documentation/process/2.Process.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
wrote:
> Dmitry Vyukov writes:
>
>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>> wrote:
>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
syzbot has found a reproducer for the following crash on:
HEAD commit:
On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
wrote:
> Dmitry Vyukov writes:
>
>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields
>> wrote:
>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
syzbot has found a reproducer for the following crash on:
HEAD commit:
On Fri, Aug 17, 2018 at 10:18:47AM -0700, Guenter Roeck wrote:
> On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.2 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one.
On Fri, Aug 17, 2018 at 10:18:47AM -0700, Guenter Roeck wrote:
> On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.2 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one.
Linus,
The following changes since commit a449938297e55e7e8958f8b48583f7d342da1930:
KVM: s390: Add huge page enablement control (2018-07-30 23:13:38 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
Linus,
The following changes since commit a449938297e55e7e8958f8b48583f7d342da1930:
KVM: s390: Add huge page enablement control (2018-07-30 23:13:38 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
Hi Torsten,
On 17/08/18 11:27, Torsten Duwe wrote:
Check for compiler support of -fpatchable-function-entry and use it
to intercept functions immediately on entry, saving the LR in x9.
Disable ftracing in efi/libstub, because this triggers cross-section
linker errors now (-pg is disabled
Hi Torsten,
On 17/08/18 11:27, Torsten Duwe wrote:
Check for compiler support of -fpatchable-function-entry and use it
to intercept functions immediately on entry, saving the LR in x9.
Disable ftracing in efi/libstub, because this triggers cross-section
linker errors now (-pg is disabled
On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.2 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.2 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.16 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.16 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:45:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.121 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.121 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:47PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.149 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:47PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.149 release.
> There are 13 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:37PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.119 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Aug 16, 2018 at 08:41:37PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.119 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Hi,
On 17 Aug 2018, at 18:54, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
>> Hey,
>>
>> is there any mainline future for this zstd support? Currently my most
>> favourite compressor for this, and for what it’s worth zstd/initrd now even
>> tested on #t2sde
Hi,
On 17 Aug 2018, at 18:54, Andi Kleen wrote:
> On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
>> Hey,
>>
>> is there any mainline future for this zstd support? Currently my most
>> favourite compressor for this, and for what it’s worth zstd/initrd now even
>> tested on #t2sde
On Fri, Aug 17, 2018 at 07:29:25PM +0530, Harsh 'Shandilya wrote:
> On 17 August 2018 12:11:37 AM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 3.18.119 release.
> >There are 15 patches in this series, all will be posted as a response
> >to this one.
On Fri, Aug 17, 2018 at 07:29:25PM +0530, Harsh 'Shandilya wrote:
> On 17 August 2018 12:11:37 AM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 3.18.119 release.
> >There are 15 patches in this series, all will be posted as a response
> >to this one.
On Fri, Aug 17, 2018 at 10:01 AM Sean Christopherson
wrote:
>
> Checking for a non-zero val in __pte_needs_invert() also resolves the
> issue. I shied away from that change because prot_none_walk() doesn't
> pass the full PTE to __pte_needs_invert(), it only passes the pgprot_t
> bits. This
On Fri, Aug 17, 2018 at 10:01 AM Sean Christopherson
wrote:
>
> Checking for a non-zero val in __pte_needs_invert() also resolves the
> issue. I shied away from that change because prot_none_walk() doesn't
> pass the full PTE to __pte_needs_invert(), it only passes the pgprot_t
> bits. This
On Fri, Aug 17, 2018 at 09:13:51AM -0700, Linus Torvalds wrote:
> On Thu, Aug 16, 2018 at 1:47 PM Sean Christopherson
> wrote:
> >
> > Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against
> > speculation")
>
> This seems wrong.
>
> That commit doesn't invert a cleared
On Fri, Aug 17, 2018 at 09:13:51AM -0700, Linus Torvalds wrote:
> On Thu, Aug 16, 2018 at 1:47 PM Sean Christopherson
> wrote:
> >
> > Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against
> > speculation")
>
> This seems wrong.
>
> That commit doesn't invert a cleared
On Fri, Aug 17, 2018 at 02:39:00PM +0200, Jinpu Wang wrote:
> On Thu, Aug 16, 2018 at 6:48 PM Jinpu Wang
> wrote:
> >
> > On Thu, Aug 16, 2018 at 6:39 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Aug 16, 2018 at 06:28:59PM +0200, Jinpu Wang wrote:
> > > > On Thu, Aug 16, 2018 at 5:51 PM
On Fri, Aug 17, 2018 at 02:39:00PM +0200, Jinpu Wang wrote:
> On Thu, Aug 16, 2018 at 6:48 PM Jinpu Wang
> wrote:
> >
> > On Thu, Aug 16, 2018 at 6:39 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Aug 16, 2018 at 06:28:59PM +0200, Jinpu Wang wrote:
> > > > On Thu, Aug 16, 2018 at 5:51 PM
> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the
> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the
> Note - it's whitespace-damaged by cut-and-paste, but it should be
> obvious enough to apply by hand.
>
> Can you test this one instead?
Right that seems like a better fix.
-Andi
> Note - it's whitespace-damaged by cut-and-paste, but it should be
> obvious enough to apply by hand.
>
> Can you test this one instead?
Right that seems like a better fix.
-Andi
On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> Hey,
>
> is there any mainline future for this zstd support? Currently my most
> favourite compressor for this, and for what it’s worth zstd/initrd now even
> tested on #t2sde / hp/pa-risc, …
On Fri, Aug 17, 2018 at 06:15:45PM +0200, René Rebe wrote:
> Hey,
>
> is there any mainline future for this zstd support? Currently my most
> favourite compressor for this, and for what it’s worth zstd/initrd now even
> tested on #t2sde / hp/pa-risc, …
Hey,
is there any mainline future for this zstd support? Currently my most favourite
compressor for this, and for what it’s worth zstd/initrd now even tested on
#t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk
René
On 10 Jul 2018, at 00:13, René Rebe wrote:
> Hi
Hey,
is there any mainline future for this zstd support? Currently my most favourite
compressor for this, and for what it’s worth zstd/initrd now even tested on
#t2sde / hp/pa-risc, … https://www.youtube.com/watch?v=MHplOJxnIHk
René
On 10 Jul 2018, at 00:13, René Rebe wrote:
> Hi
Liebste in Christus,
Ich bin Frau Ruth Hamson, ich heiratete Herrn Paul Hamson für 19 Jahre ohne
Kind und mein Mann starb im Jahr 2007. Ich kontaktiere Sie, damit Sie meinen
Wunsch wissen, die Summe von $ 6,500,000, die ich von meiner geerbt habe, zu
spenden späte Ehemann zu Wohltätigkeit,
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.
To avoid
Liebste in Christus,
Ich bin Frau Ruth Hamson, ich heiratete Herrn Paul Hamson für 19 Jahre ohne
Kind und mein Mann starb im Jahr 2007. Ich kontaktiere Sie, damit Sie meinen
Wunsch wissen, die Summe von $ 6,500,000, die ich von meiner geerbt habe, zu
spenden späte Ehemann zu Wohltätigkeit,
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.
To avoid
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to the
its interrupt controller. Only select GPIOs that are deemed wakeup
capable are routed to specific PDC pins. During low power state, the
pinmux interrupt
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to the
its interrupt controller. Only select GPIOs that are deemed wakeup
capable are routed to specific PDC pins. During low power state, the
pinmux interrupt
GPIOs that are wakeup capable have interrupt lines that are routed to
the always-on interrupt controller (PDC) in parallel to the pinctrl. The
interrupts listed here are the wake up lines corresponding to GPIOs.
Signed-off-by: Lina Iyer
---
Changes in v1:
- Use interrupt-extended for all
GPIOs that are wakeup capable have interrupt lines that are routed to
the always-on interrupt controller (PDC) in parallel to the pinctrl. The
interrupts listed here are the wake up lines corresponding to GPIOs.
Signed-off-by: Lina Iyer
---
Changes in v1:
- Use interrupt-extended for all
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2ab7a8885757..cc333b8afb99 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++
Hi,
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume callbacks
- Dropped PDC DT bindings (see dependencies)
Dependencies:
https://lkml.org/lkml/2018/8/17/137
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
---
drivers/pinctrl/qcom/pinctrl-sdm845.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c
b/drivers/pinctrl/qcom/pinctrl-sdm845.c
index 2ab7a8885757..cc333b8afb99 100644
--- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
+++
Hi,
Changes in v1:
- Avoid GPIO-PDC map in .c file
- Trigger GPIO by writing to the hardware
- Hooked up to suspend/resume callbacks
- Dropped PDC DT bindings (see dependencies)
Dependencies:
https://lkml.org/lkml/2018/8/17/137
Update the documentation to use interrupts-extended format for
specifying the TLMM summary IRQ line that is requested from GIC and the
PDC interrupts corresponding to the wakeup capable GPIOs.
Update the example to show PDC interrupts for the wakeup capable GPIOs
for SDM845.
Cc:
Hi Linus,
I'm travelling next week and a couple of fixes came in since our main
pull request on Tuesday. Since one of them fixes a boot failure on
Hikey-960, I figured there was no point holding them off until -rc1 is
released, so please consider pulling them beforehand.
Details in the tag.
Hi Linus,
I'm travelling next week and a couple of fixes came in since our main
pull request on Tuesday. Since one of them fixes a boot failure on
Hikey-960, I figured there was no point holding them off until -rc1 is
released, so please consider pulling them beforehand.
Details in the tag.
The package power can also be read from an MSR. It's not clear exactly
what is included, and whether it's aggregated over all nodes or
reported separately.
It does look like this is reported separately per CCX (I get a single
value on the Ryzen R7 1700), but it might be reported separately per-
This is an updated version of my RAPL patchset for Zen CPUs, rebased on
top of the current state of kernel/git/lenb/linux.get turbostat branch.
(In particular, this fixes conflicts with the AMD APIC-id patch)
I've split it into two patches now. The first patch only adds Cores
power reporting,
The package power can also be read from an MSR. It's not clear exactly
what is included, and whether it's aggregated over all nodes or
reported separately.
It does look like this is reported separately per CCX (I get a single
value on the Ryzen R7 1700), but it might be reported separately per-
This is an updated version of my RAPL patchset for Zen CPUs, rebased on
top of the current state of kernel/git/lenb/linux.get turbostat branch.
(In particular, this fixes conflicts with the AMD APIC-id patch)
I've split it into two patches now. The first patch only adds Cores
power reporting,
Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf
These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's
Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf
These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's
On Fri, 2018-08-17 at 09:01 +0200, Simon Goldschmidt wrote:
> The spi-dw driver currently only supports 8 or 16 bits per word.
>
> Since the hardware supports 4-16 bits per word, adapt the driver
> to also support this.
>
>
> @@ -307,15 +307,13 @@ static int dw_spi_transfer_one(struct
On Fri, 2018-08-17 at 09:01 +0200, Simon Goldschmidt wrote:
> The spi-dw driver currently only supports 8 or 16 bits per word.
>
> Since the hardware supports 4-16 bits per word, adapt the driver
> to also support this.
>
>
> @@ -307,15 +307,13 @@ static int dw_spi_transfer_one(struct
On Fri, Aug 17, 2018 at 09:08:42AM -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 14, 2018 at 10:06:18AM -0700, Paul E. McKenney wrote:
> > > Is there a way we could make a union, or reuse one of the other fields,
> > > as we know that synchronize_srcu() can't be used yet (and if it is,
> > >
On Fri, Aug 17, 2018 at 09:08:42AM -0700, Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 14, 2018 at 10:06:18AM -0700, Paul E. McKenney wrote:
> > > Is there a way we could make a union, or reuse one of the other fields,
> > > as we know that synchronize_srcu() can't be used yet (and if it is,
> > >
Hi Wendy,
couple of minor stuff inline.
On Thu, Aug 16, 2018 at 12:06 AM, Wendy Liang wrote:
> Add device tree binding for Xilinx Cortex-r5 remoteproc.
>
> Signed-off-by: Wendy Liang
> ---
> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81
> ++
> 1 file changed,
Hi Wendy,
couple of minor stuff inline.
On Thu, Aug 16, 2018 at 12:06 AM, Wendy Liang wrote:
> Add device tree binding for Xilinx Cortex-r5 remoteproc.
>
> Signed-off-by: Wendy Liang
> ---
> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81
> ++
> 1 file changed,
Hi all,
This is a friendly reminder that the deadline for submitting talk proposals for
Tracing Summit 2018[1] is coming up soon (Sept 1st). Submit you talk today
using submiss...@tracingsummit.org and don't forget to include the following:
- Talk title,
- Talk abstract (900 characters maximum),
Hi all,
This is a friendly reminder that the deadline for submitting talk proposals for
Tracing Summit 2018[1] is coming up soon (Sept 1st). Submit you talk today
using submiss...@tracingsummit.org and don't forget to include the following:
- Talk title,
- Talk abstract (900 characters maximum),
On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> This re-fixes the bug reported by Hari Vyas
> after my revert of his commit but in a much simpler way.
>
> The main issues is that is_added was being set after the driver
> got bound and started, and thus setting it could
On Fri, Aug 17, 2018 at 02:48:58PM +1000, Benjamin Herrenschmidt wrote:
> This re-fixes the bug reported by Hari Vyas
> after my revert of his commit but in a much simpler way.
>
> The main issues is that is_added was being set after the driver
> got bound and started, and thus setting it could
On Fri, 17 Aug 2018 15:56:23 +
"Luck, Tony" wrote:
> >> - Some targets don't have any support for I/O space on their PCI bus and
> >> just
> >>want to get things to compile by setting PCI_IOBASE to zero, this still
> >> opens
> >> up some of the same problems as above, but doesn't
On Fri, 17 Aug 2018 15:56:23 +
"Luck, Tony" wrote:
> >> - Some targets don't have any support for I/O space on their PCI bus and
> >> just
> >>want to get things to compile by setting PCI_IOBASE to zero, this still
> >> opens
> >> up some of the same problems as above, but doesn't
On Fri, Aug 17, 2018 at 06:53:48PM +0530, Bhaskar Singh wrote:
> This patch fixes the checkpatch.pl ERROR:
>
> ERROR: spaces required around that '==' (ctx:VxV)
>
> Signed-off-by: Bhaskar Singh
> ---
> kernel/acct.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, Aug 17, 2018 at 06:53:48PM +0530, Bhaskar Singh wrote:
> This patch fixes the checkpatch.pl ERROR:
>
> ERROR: spaces required around that '==' (ctx:VxV)
>
> Signed-off-by: Bhaskar Singh
> ---
> kernel/acct.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Fri, Aug 17, 2018 at 08:40:06AM -0700, Rodrigo Vivi wrote:
> Hi Greg, Ben, and all
>
> Is https://www.kernel.org/category/releases.html updated in terms of EOL?
As of right now, for the kernels I maintain, yes, it is correct.
> Some news out of Linaro conference [2] generated a lot of doubts
On Fri, Aug 17, 2018 at 08:40:06AM -0700, Rodrigo Vivi wrote:
> Hi Greg, Ben, and all
>
> Is https://www.kernel.org/category/releases.html updated in terms of EOL?
As of right now, for the kernels I maintain, yes, it is correct.
> Some news out of Linaro conference [2] generated a lot of doubts
On Thu, Aug 16, 2018 at 1:47 PM Sean Christopherson
wrote:
>
> Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against
> speculation")
This seems wrong.
That commit doesn't invert a cleared page table entry, because that
commit still required _PAGE_PROTNONE being set for a
On Thu, Aug 16, 2018 at 1:47 PM Sean Christopherson
wrote:
>
> Fixes: 6b28baca9b1f ("x86/speculation/l1tf: Protect PROT_NONE PTEs against
> speculation")
This seems wrong.
That commit doesn't invert a cleared page table entry, because that
commit still required _PAGE_PROTNONE being set for a
Hello,
On Tue, Aug 14, 2018 at 10:06:18AM -0700, Paul E. McKenney wrote:
> > Is there a way we could make a union, or reuse one of the other fields,
> > as we know that synchronize_srcu() can't be used yet (and if it is,
> > either warn, or just make it a nop). And when we call srcu_init() and
>
Hello,
On Tue, Aug 14, 2018 at 10:06:18AM -0700, Paul E. McKenney wrote:
> > Is there a way we could make a union, or reuse one of the other fields,
> > as we know that synchronize_srcu() can't be used yet (and if it is,
> > either warn, or just make it a nop). And when we call srcu_init() and
>
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
Changes in v2:
- Order by address
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
Add PDC interrupt controller device bindings for SDM845.
Signed-off-by: Lina Iyer
---
Changes in v2:
- Order by address
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote:
> On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
> wrote:
> > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
[...]
> > > We also don't necessarily want to encourage ordinary users to
> > > fiddle with the system key databases
On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote:
> On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
> wrote:
> > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
[...]
> > > We also don't necessarily want to encourage ordinary users to
> > > fiddle with the system key databases
On Fri, Aug 17 2018 at 03:18 -0600, Marc Zyngier wrote:
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
On Fri, Aug 17 2018 at 03:18 -0600, Marc Zyngier wrote:
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
>> - Some targets don't have any support for I/O space on their PCI bus and just
>>want to get things to compile by setting PCI_IOBASE to zero, this still
>> opens
>> up some of the same problems as above, but doesn't really help otherwise.
That sounds horrible. Why would you want to
>> - Some targets don't have any support for I/O space on their PCI bus and just
>>want to get things to compile by setting PCI_IOBASE to zero, this still
>> opens
>> up some of the same problems as above, but doesn't really help otherwise.
That sounds horrible. Why would you want to
On Thu, Aug 16, 2018 at 10:55 PM zhong jiang wrote:
> Signed-off-by: zhong jiang
Acked-by: Robin Holt
On Thu, Aug 16, 2018 at 10:55 PM zhong jiang wrote:
> Signed-off-by: zhong jiang
Acked-by: Robin Holt
On 08/17/2018 04:45 PM, Patrick Bellasi wrote:
On 17-Aug 15:43, Dietmar Eggemann wrote:
On 08/06/2018 06:39 PM, Patrick Bellasi wrote:
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still
On 08/17/2018 04:45 PM, Patrick Bellasi wrote:
On 17-Aug 15:43, Dietmar Eggemann wrote:
On 08/06/2018 06:39 PM, Patrick Bellasi wrote:
In order to properly support hierarchical resources control, the cgroup
delegation model requires that attribute writes from a child group never
fail but still
On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
Just to be clear, if I understand correctly, this is a pure revert of
44bda4b7d26e and as such it reintroduces the problem solved by that
commit.
If your
On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
Just to be clear, if I understand correctly, this is a pure revert of
44bda4b7d26e and as such it reintroduces the problem solved by that
commit.
If your
On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
wrote:
> On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
>> James Bottomley wrote:
>>
>> > > > As a step by step process, I agree. However, I think we can
>> > > > automate it to the point where you install a package and it
>> > > > says
On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
wrote:
> On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
>> James Bottomley wrote:
>>
>> > > > As a step by step process, I agree. However, I think we can
>> > > > automate it to the point where you install a package and it
>> > > > says
201 - 300 of 714 matches
Mail list logo
