On Thu, Sep 06, 2018 at 11:45:03AM -0700, Sean Christopherson wrote:
> Yep, though because the 4k chunk in __decrypted is @hv_clock_boot
> that's used for cpus 0-127, __decrypted_XXX would effectively be:
>
>(((num_possible_cpus() * 32) / 4k) - 1) pages
Ok, sounds like a nice compromise to
On Thu, Sep 06, 2018 at 11:45:03AM -0700, Sean Christopherson wrote:
> Yep, though because the 4k chunk in __decrypted is @hv_clock_boot
> that's used for cpus 0-127, __decrypted_XXX would effectively be:
>
>(((num_possible_cpus() * 32) / 4k) - 1) pages
Ok, sounds like a nice compromise to
On Mon, Sep 03, 2018 at 03:11:11PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> Disable interrupts while configuring the transfer and enable them back.
>
> We have below as the programming sequence
> 1. start and slave address
> 2. byte count and stop
>
> In some
On Mon, Sep 03, 2018 at 03:11:11PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> Disable interrupts while configuring the transfer and enable them back.
>
> We have below as the programming sequence
> 1. start and slave address
> 2. byte count and stop
>
> In some
On 09/06/2018 09:07 AM, Sean Christopherson wrote:
...
+
+/* This should cover upto 512 VCPUS (first 64 are covered by hv_clock_boot[]).
*/
+#define HVC_DECRYPTED_ARRAY_SIZE \
+ ((PAGE_SIZE * 7) / sizeof(struct pvclock_vsyscall_time_info))
I think we can define the size relative to
On 09/06/2018 09:07 AM, Sean Christopherson wrote:
...
+
+/* This should cover upto 512 VCPUS (first 64 are covered by hv_clock_boot[]).
*/
+#define HVC_DECRYPTED_ARRAY_SIZE \
+ ((PAGE_SIZE * 7) / sizeof(struct pvclock_vsyscall_time_info))
I think we can define the size relative to
On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 09:18 AM, Sean Christopherson wrote:
>
>
> >>>
> >>>So are we going to be defining a decrypted section for every piece of
> >>>machinery now?
> >>>
> >>>That's a bit too much in my book.
> >>>
> >>>Why can't
On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 09:18 AM, Sean Christopherson wrote:
>
>
> >>>
> >>>So are we going to be defining a decrypted section for every piece of
> >>>machinery now?
> >>>
> >>>That's a bit too much in my book.
> >>>
> >>>Why can't
On Thu, Sep 06, 2018 at 08:33:34PM +0200, Borislav Petkov wrote:
> On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
> > My thought was that we could simply define a second array for the SEV
> > case to statically allocate for NR_CPUS since __decrypted has a big
> > chunk of
On Thu, Sep 06, 2018 at 08:33:34PM +0200, Borislav Petkov wrote:
> On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
> > My thought was that we could simply define a second array for the SEV
> > case to statically allocate for NR_CPUS since __decrypted has a big
> > chunk of
On 09/06/2018 01:33 PM, Borislav Petkov wrote:
On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
My thought was that we could simply define a second array for the SEV
case to statically allocate for NR_CPUS since __decrypted has a big
chunk of memory that would be ununsed
On 09/06/2018 01:33 PM, Borislav Petkov wrote:
On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
My thought was that we could simply define a second array for the SEV
case to statically allocate for NR_CPUS since __decrypted has a big
chunk of memory that would be ununsed
On Thu, Aug 23, 2018 at 03:57:31PM -0700, Jae Hyun Yoo wrote:
> In most of cases, interrupt bits are set one by one but there are
> also a lot of other cases that Aspeed I2C IP sends multiple
> interrupt bits with combining master and slave events using a
> single interrupt call. It happens much
On Thu, Aug 23, 2018 at 03:57:31PM -0700, Jae Hyun Yoo wrote:
> In most of cases, interrupt bits are set one by one but there are
> also a lot of other cases that Aspeed I2C IP sends multiple
> interrupt bits with combining master and slave events using a
> single interrupt call. It happens much
at 11:31 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 11:09:23AM -0700, Andy Lutomirski wrote:
>>> On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
>>> It depends what security you want. Some may consider even the short
>>> time-window in which the kernel code is writable from other cores
at 11:31 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 11:09:23AM -0700, Andy Lutomirski wrote:
>>> On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
>>> It depends what security you want. Some may consider even the short
>>> time-window in which the kernel code is writable from other cores
On 09/06/2018 09:18 AM, Sean Christopherson wrote:
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my book.
Why can't you simply free everything in .data..decrypted on !SVE guests?
That would prevent adding __decrypted
On 09/06/2018 09:18 AM, Sean Christopherson wrote:
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my book.
Why can't you simply free everything in .data..decrypted on !SVE guests?
That would prevent adding __decrypted
Commit-ID: 4cb205c0c50f613e2de91f0eb19d5247ed003e89
Gitweb: https://git.kernel.org/tip/4cb205c0c50f613e2de91f0eb19d5247ed003e89
Author: Jia He
AuthorDate: Tue, 28 Aug 2018 12:53:26 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 6 Sep 2018 20:31:59 +0200
irqchip/gic-v3-its: Cap
Commit-ID: 4cb205c0c50f613e2de91f0eb19d5247ed003e89
Gitweb: https://git.kernel.org/tip/4cb205c0c50f613e2de91f0eb19d5247ed003e89
Author: Jia He
AuthorDate: Tue, 28 Aug 2018 12:53:26 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 6 Sep 2018 20:31:59 +0200
irqchip/gic-v3-its: Cap
On 09/05/2018 11:47 PM, Lei Yang wrote:
> Update .gitignore file.
>
> Signed-off-by: Lei Yang
> ---
> tools/testing/selftests/cgroup/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/cgroup/.gitignore
> b/tools/testing/selftests/cgroup/.gitignore
>
On 09/05/2018 11:47 PM, Lei Yang wrote:
> Update .gitignore file.
>
> Signed-off-by: Lei Yang
> ---
> tools/testing/selftests/cgroup/.gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/cgroup/.gitignore
> b/tools/testing/selftests/cgroup/.gitignore
>
Hi,
On Mon, Aug 27, 2018 at 10:10 AM, Matthias Kaehlcke wrote:
> On Fri, Aug 10, 2018 at 05:09:17PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Wed, Aug 8, 2018 at 12:13 PM, Matthias Kaehlcke wrote:
>> > This adds the adc node to pm8998 based on the examples in the
>> > bindings. It also fixes
Hi,
On Mon, Aug 27, 2018 at 10:10 AM, Matthias Kaehlcke wrote:
> On Fri, Aug 10, 2018 at 05:09:17PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Wed, Aug 8, 2018 at 12:13 PM, Matthias Kaehlcke wrote:
>> > This adds the adc node to pm8998 based on the examples in the
>> > bindings. It also fixes
On Fri, Aug 31, 2018 at 11:43:42AM +0200, Andrea Parri wrote:
> > > > + b. The "unless" RMW operations are not currently modeled:
> > > > + atomic_long_add_unless(), atomic_add_unless(),
> > > > + atomic_inc_unless_negative(), and
> > > > +
On Fri, Aug 31, 2018 at 11:43:42AM +0200, Andrea Parri wrote:
> > > > + b. The "unless" RMW operations are not currently modeled:
> > > > + atomic_long_add_unless(), atomic_add_unless(),
> > > > + atomic_inc_unless_negative(), and
> > > > +
Please don't quote the whole message. Everyone else has to scroll down
a lot to find the relevant information. Thanks!
Will keep that in mind. Thanks Wolfram!
Please don't quote the whole message. Everyone else has to scroll down
a lot to find the relevant information. Thanks!
Will keep that in mind. Thanks Wolfram!
On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
> My thought was that we could simply define a second array for the SEV
> case to statically allocate for NR_CPUS since __decrypted has a big
> chunk of memory that would be ununsed anyways[1]. And since the second
> array is
On Thu, Sep 06, 2018 at 09:15:29PM +0800, Jun Gao wrote:
> From: Jun Gao
>
> DMA mode will always be used in i2c transactions, try to allocate
> a DMA safe buffer if the buf of struct i2c_msg used is not DMA safe.
>
> Signed-off-by: Jun Gao
Applied to for-next, thanks!
signature.asc
On Thu, Sep 06, 2018 at 08:54:52AM -0700, Sean Christopherson wrote:
> My thought was that we could simply define a second array for the SEV
> case to statically allocate for NR_CPUS since __decrypted has a big
> chunk of memory that would be ununsed anyways[1]. And since the second
> array is
On Thu, Sep 06, 2018 at 09:15:29PM +0800, Jun Gao wrote:
> From: Jun Gao
>
> DMA mode will always be used in i2c transactions, try to allocate
> a DMA safe buffer if the buf of struct i2c_msg used is not DMA safe.
>
> Signed-off-by: Jun Gao
Applied to for-next, thanks!
signature.asc
On Thu, Sep 06, 2018 at 11:09:23AM -0700, Andy Lutomirski wrote:
> > On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
> > It depends what security you want. Some may consider even the short
> > time-window in which the kernel code is writable from other cores as
> > insufficient for security.
> >
On Thu, Sep 06, 2018 at 11:09:23AM -0700, Andy Lutomirski wrote:
> > On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
> > It depends what security you want. Some may consider even the short
> > time-window in which the kernel code is writable from other cores as
> > insufficient for security.
> >
On Thu, Sep 06, 2018 at 09:15:28PM +0800, Jun Gao wrote:
> From: Jun Gao
>
> In order not to block the initializations of some i2c devices.
> Register i2c adapter driver at appropriate time.
>
> Signed-off-by: Jun Gao
The reasons this patch was rejected in v2 still hold.
signature.asc
On Thu, Sep 06, 2018 at 09:15:28PM +0800, Jun Gao wrote:
> From: Jun Gao
>
> In order not to block the initializations of some i2c devices.
> Register i2c adapter driver at appropriate time.
>
> Signed-off-by: Jun Gao
The reasons this patch was rejected in v2 still hold.
signature.asc
On Thu, Sep 6, 2018 at 1:24 PM Moritz Fischer wrote:
>
> Hi Alan,
>
> looks like it's just the examples, right?
Yes, it's in the examples of use, not the actual freeze bridge
bindings doc that I'm correcting.
> So not sure someone
> would be affected by that, yet?
It's taken two years for
On Thu, Sep 06, 2018 at 10:22:46AM -0600, Tycho Andersen wrote:
> On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > > The idea here is that the userspace handler should be able to pass an fd
> > > back to the trapped task, for
On Thu, Sep 6, 2018 at 1:24 PM Moritz Fischer wrote:
>
> Hi Alan,
>
> looks like it's just the examples, right?
Yes, it's in the examples of use, not the actual freeze bridge
bindings doc that I'm correcting.
> So not sure someone
> would be affected by that, yet?
It's taken two years for
On Thu, Sep 06, 2018 at 10:22:46AM -0600, Tycho Andersen wrote:
> On Thu, Sep 06, 2018 at 06:15:18PM +0200, Jann Horn wrote:
> > On Thu, Sep 6, 2018 at 5:29 PM Tycho Andersen wrote:
> > > The idea here is that the userspace handler should be able to pass an fd
> > > back to the trapped task, for
On 9/6/18 3:21 AM, Mark Rutland wrote:
Hi,
On Thu, Sep 06, 2018 at 01:05:35AM -0700, Atish Patra wrote:
This patch enable support for cpu hotplug in RISC-V.
In absence of generic cpu stop functions, WFI is used
to put the cpu in low power state during offline. An IPI
is sent to bring it out
On 9/6/18 3:21 AM, Mark Rutland wrote:
Hi,
On Thu, Sep 06, 2018 at 01:05:35AM -0700, Atish Patra wrote:
This patch enable support for cpu hotplug in RISC-V.
In absence of generic cpu stop functions, WFI is used
to put the cpu in low power state during offline. An IPI
is sent to bring it out
Hi Alan,
looks like it's just the examples, right? So not sure someone
would be affected by that, yet?
On Thu, Sep 06, 2018 at 01:01:52PM -0500, Alan Tull wrote:
> Documentation/devicetree/bindings/fpga/fpga-region.txt has an error
> regarding the freeze controller bridge, secifically:
>
>
Hi Alan,
looks like it's just the examples, right? So not sure someone
would be affected by that, yet?
On Thu, Sep 06, 2018 at 01:01:52PM -0500, Alan Tull wrote:
> Documentation/devicetree/bindings/fpga/fpga-region.txt has an error
> regarding the freeze controller bridge, secifically:
>
>
Hi!
I noticed the following check in smk_ptrace_rule_check():
if (tracer_known->smk_known == tracee_known->smk_known)
rc = 0;
else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)
rc = -EACCES;
else
Hi!
I noticed the following check in smk_ptrace_rule_check():
if (tracer_known->smk_known == tracee_known->smk_known)
rc = 0;
else if (smack_ptrace_rule == SMACK_PTRACE_DRACONIAN)
rc = -EACCES;
else
On 6 September 2018 at 22:13, Tony Lindgren wrote:
> Hi,
>
> Looks like next-20180906 now has a regression where mounting
> root won't work with commit fd0002870b45 ("vfs: Implement a
> filesystem superblock creation/configuration context").
I have noticed this problem
On 6 September 2018 at 22:13, Tony Lindgren wrote:
> Hi,
>
> Looks like next-20180906 now has a regression where mounting
> root won't work with commit fd0002870b45 ("vfs: Implement a
> filesystem superblock creation/configuration context").
I have noticed this problem
> On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
>
> at 10:17 AM, Peter Zijlstra wrote:
>
>>> On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
>>> In addition, there might be a couple of issues with your fix:
>>
>> It boots on my box ;-)
>>
>>> 1. __set_pte_vaddr() is not used
> On Sep 6, 2018, at 10:58 AM, Nadav Amit wrote:
>
> at 10:17 AM, Peter Zijlstra wrote:
>
>>> On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
>>> In addition, there might be a couple of issues with your fix:
>>
>> It boots on my box ;-)
>>
>>> 1. __set_pte_vaddr() is not used
On Thu 06-09-18 10:07:51, Dave Hansen wrote:
> On 09/06/2018 09:12 AM, Pasha Tatashin wrote:
> >
> > I do not want to make this feature less tested. Poisoning memory allowed
> > us to catch corner case bugs like these:
> >
> > ab1e8d8960b68f54af42b6484b5950bd13a4054b
> > mm: don't allow deferred
On Thu 06-09-18 10:07:51, Dave Hansen wrote:
> On 09/06/2018 09:12 AM, Pasha Tatashin wrote:
> >
> > I do not want to make this feature less tested. Poisoning memory allowed
> > us to catch corner case bugs like these:
> >
> > ab1e8d8960b68f54af42b6484b5950bd13a4054b
> > mm: don't allow deferred
> > Looks awesome! Thanks!
> >
> > Reviewed-by: Brendan Higgins
> >
>
> Thanks a lot for your review Brendan!
Please don't quote the whole message. Everyone else has to scroll down
a lot to find the relevant information. Thanks!
signature.asc
Description: PGP signature
> > Looks awesome! Thanks!
> >
> > Reviewed-by: Brendan Higgins
> >
>
> Thanks a lot for your review Brendan!
Please don't quote the whole message. Everyone else has to scroll down
a lot to find the relevant information. Thanks!
signature.asc
Description: PGP signature
On 9/6/2018 3:35 PM, Will Deacon wrote:
On Fri, Aug 24, 2018 at 08:15:27PM +0530, Sai Prakash Ranjan wrote:
Introduce dynamic debug filtering mechanism to register
tracing as dynamic_rtb() which will reduce a lot of
overhead otherwise of tracing all the register reads/writes
in all files.
Now
On 9/6/2018 3:35 PM, Will Deacon wrote:
On Fri, Aug 24, 2018 at 08:15:27PM +0530, Sai Prakash Ranjan wrote:
Introduce dynamic debug filtering mechanism to register
tracing as dynamic_rtb() which will reduce a lot of
overhead otherwise of tracing all the register reads/writes
in all files.
Now
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
*
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
---
Changes for v3:
* Fix the indentation and whitespace warnings.
Changes for v2:
*
Documentation/devicetree/bindings/fpga/fpga-region.txt has an error
regarding the freeze controller bridge, secifically:
compatible = "altr,freeze-bridge";
The compatibility string should be "altr,freeze-bridge-controller"
as set forth in altera-freeze-bridge.txt.
Signed-off-by: Alan Tull
Documentation/devicetree/bindings/fpga/fpga-region.txt has an error
regarding the freeze controller bridge, secifically:
compatible = "altr,freeze-bridge";
The compatibility string should be "altr,freeze-bridge-controller"
as set forth in altera-freeze-bridge.txt.
Signed-off-by: Alan Tull
at 10:17 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
>> In addition, there might be a couple of issues with your fix:
>
> It boots on my box ;-)
>
>> 1. __set_pte_vaddr() is not used exclusive by set_fixmap(). This means
>> the warning might be
at 10:17 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
>> In addition, there might be a couple of issues with your fix:
>
> It boots on my box ;-)
>
>> 1. __set_pte_vaddr() is not used exclusive by set_fixmap(). This means
>> the warning might be
Hi,
I just wanted to check if you would be interested in a list of Managed
Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?
We also have the data intelligence of:
• Managed Service Providers (MSP’s) – 25,000 unique companies
• Managed Security Service
Hi,
I just wanted to check if you would be interested in a list of Managed
Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?
We also have the data intelligence of:
• Managed Service Providers (MSP’s) – 25,000 unique companies
• Managed Security Service
Bjorn,
On Sat, Sep 1, 2018 at 3:19 PM, Bjorn Andersson
wrote:
> Add regulator definitions for pm8998 and pmi8998 regulators on the MTP.
>
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 216
> 1 file changed, 216 insertions(+)
I'm
Bjorn,
On Sat, Sep 1, 2018 at 3:19 PM, Bjorn Andersson
wrote:
> Add regulator definitions for pm8998 and pmi8998 regulators on the MTP.
>
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 216
> 1 file changed, 216 insertions(+)
I'm
> On 6 Sep 2018, at 16:51, Jonathan Corbet wrote:
>
> On Wed, 5 Sep 2018 20:07:50 +0100
> Grant Likely wrote:
>
>> The dtb= parameter is no longer the primary mechanism for providing a
>> devicetree to the kernel. Now either firmware or the boot selector (ex.
>> Grub) should provide the
> On 6 Sep 2018, at 16:51, Jonathan Corbet wrote:
>
> On Wed, 5 Sep 2018 20:07:50 +0100
> Grant Likely wrote:
>
>> The dtb= parameter is no longer the primary mechanism for providing a
>> devicetree to the kernel. Now either firmware or the boot selector (ex.
>> Grub) should provide the
On 09/06/2018 08:50 AM, Sean Christopherson wrote:
...
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my book.
Why can't you simply free everything in .data..decrypted on !SVE guests?
That would prevent adding __decrypted to
On 09/06/2018 08:50 AM, Sean Christopherson wrote:
...
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my book.
Why can't you simply free everything in .data..decrypted on !SVE guests?
That would prevent adding __decrypted to
Em Thu, Sep 06, 2018 at 07:42:51PM +0800, Ding Xiang escreveu:
> use PTR_ERR_OR_ZERO for bpf__setup_stdout return code
>
> v2: add macro PTR_ERR_OR_ZERO to err.h
This really should be done in two patches, one introducing the
PTR_ERR_OR_ZERO() macro, and then the use of it in bpf-loader.c.
Em Thu, Sep 06, 2018 at 07:42:51PM +0800, Ding Xiang escreveu:
> use PTR_ERR_OR_ZERO for bpf__setup_stdout return code
>
> v2: add macro PTR_ERR_OR_ZERO to err.h
This really should be done in two patches, one introducing the
PTR_ERR_OR_ZERO() macro, and then the use of it in bpf-loader.c.
Hi Jarkko,
On Thu, Sep 6, 2018 at 11:21 AM, Jarkko Sakkinen
wrote:
> There is another open. If I grep through the kernel tree I see SPDX
> headers that are decorated both with C99- and C89-style comments. I
> guess I ended up using C99-style because when I was instructed to add
> SPDX headers in
Hi Jarkko,
On Thu, Sep 6, 2018 at 11:21 AM, Jarkko Sakkinen
wrote:
> There is another open. If I grep through the kernel tree I see SPDX
> headers that are decorated both with C99- and C89-style comments. I
> guess I ended up using C99-style because when I was instructed to add
> SPDX headers in
On 9/6/2018 10:26 AM, Brendan Higgins wrote:
On Thu, Aug 23, 2018 at 3:58 PM Jae Hyun Yoo
wrote:
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single
On 9/6/2018 10:26 AM, Brendan Higgins wrote:
On Thu, Aug 23, 2018 at 3:58 PM Jae Hyun Yoo
wrote:
In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single
On 08/31/2018 08:42 PM, Andy Lutomirski wrote:
> One of Linus' favorite hobbies seems to be looking at OOPSes and
> decoding the error code in his head. This is not one of my favorite
> hobbies :)
I just work around this by having a screenshot of 'enum
x86_pf_error_code' as my desktop
On 08/31/2018 08:42 PM, Andy Lutomirski wrote:
> One of Linus' favorite hobbies seems to be looking at OOPSes and
> decoding the error code in his head. This is not one of my favorite
> hobbies :)
I just work around this by having a screenshot of 'enum
x86_pf_error_code' as my desktop
On Thu, Aug 23, 2018 at 3:58 PM Jae Hyun Yoo
wrote:
>
> In most of cases, interrupt bits are set one by one but there are
> also a lot of other cases that Aspeed I2C IP sends multiple
> interrupt bits with combining master and slave events using a
> single interrupt call. It happens much more in
On Thu, Aug 23, 2018 at 3:58 PM Jae Hyun Yoo
wrote:
>
> In most of cases, interrupt bits are set one by one but there are
> also a lot of other cases that Aspeed I2C IP sends multiple
> interrupt bits with combining master and slave events using a
> single interrupt call. It happens much more in
On 9/6/18 1:03 PM, Michal Hocko wrote:
> On Thu 06-09-18 08:41:52, Alexander Duyck wrote:
>> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
>>>
>>> On Thu 06-09-18 07:59:03, Dave Hansen wrote:
On 09/05/2018 10:47 PM, Michal Hocko wrote:
> why do you have to keep DEBUG_VM enabled
On 9/6/18 1:03 PM, Michal Hocko wrote:
> On Thu 06-09-18 08:41:52, Alexander Duyck wrote:
>> On Thu, Sep 6, 2018 at 8:13 AM Michal Hocko wrote:
>>>
>>> On Thu 06-09-18 07:59:03, Dave Hansen wrote:
On 09/05/2018 10:47 PM, Michal Hocko wrote:
> why do you have to keep DEBUG_VM enabled
On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
> I’ll give your patch a try once my server goes back online. I was (and still
> am) worried that interrupts would be disabled when __set_pte_vaddr() is
> called, which would make the fix more complicated.
Thing is, we only need the TLB
On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
> I’ll give your patch a try once my server goes back online. I was (and still
> am) worried that interrupts would be disabled when __set_pte_vaddr() is
> called, which would make the fix more complicated.
Thing is, we only need the TLB
On 06-Sep 16:59, Juri Lelli wrote:
> On 06/09/18 15:40, Patrick Bellasi wrote:
> > On 04-Sep 15:47, Juri Lelli wrote:
>
> [...]
>
> > > Wondering if you want to fold the check below inside the
> > >
> > > if (user && !capable(CAP_SYS_NICE)) {
> > >...
> > > }
> > >
> > > block. It would
On 06-Sep 16:59, Juri Lelli wrote:
> On 06/09/18 15:40, Patrick Bellasi wrote:
> > On 04-Sep 15:47, Juri Lelli wrote:
>
> [...]
>
> > > Wondering if you want to fold the check below inside the
> > >
> > > if (user && !capable(CAP_SYS_NICE)) {
> > >...
> > > }
> > >
> > > block. It would
On 09/02/2018 11:14 AM, Nadav Amit wrote:
> When page-table entries are set, the compiler might optimize their
> assignment by using multiple instructions to set the PTE. This might
> turn into a security hazard if the user somehow manages to use the
> interim PTE. L1TF does not make our lives
On 08/20/2018 07:46 PM, Eric Biggers wrote:
> On Wed, Aug 15, 2018 at 09:35:03AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>> git tree: linux-next
>> console output:
On Thu, Sep 06, 2018 at 12:05:21PM +0800, Jason Wang wrote:
> This patch split out XDP logic into a single function. This make it to
> be reused by XDP batching path in the following patch.
>
> Signed-off-by: Jason Wang
> ---
> drivers/net/tun.c | 84
On 09/02/2018 11:14 AM, Nadav Amit wrote:
> When page-table entries are set, the compiler might optimize their
> assignment by using multiple instructions to set the PTE. This might
> turn into a security hazard if the user somehow manages to use the
> interim PTE. L1TF does not make our lives
On 08/20/2018 07:46 PM, Eric Biggers wrote:
> On Wed, Aug 15, 2018 at 09:35:03AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>> git tree: linux-next
>> console output:
On Thu, Sep 06, 2018 at 12:05:21PM +0800, Jason Wang wrote:
> This patch split out XDP logic into a single function. This make it to
> be reused by XDP batching path in the following patch.
>
> Signed-off-by: Jason Wang
> ---
> drivers/net/tun.c | 84
On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
> In addition, there might be a couple of issues with your fix:
It boots on my box ;-)
> 1. __set_pte_vaddr() is not used exclusive by set_fixmap(). This means
> the warning might be wrong, but also means that these code patches (Xen’s
On Thu, Sep 06, 2018 at 05:01:25PM +, Nadav Amit wrote:
> In addition, there might be a couple of issues with your fix:
It boots on my box ;-)
> 1. __set_pte_vaddr() is not used exclusive by set_fixmap(). This means
> the warning might be wrong, but also means that these code patches (Xen’s
On 06/09/18 17:59, Olof Johansson wrote:
> Hi,
>
> On Thu, Sep 06, 2018 at 04:10:39PM +0100, Sudeep Holla wrote:
>> Firmware can provide zero as values for sustained performance level and
>> corresponding sustained frequency in kHz in order to hide the actual
>> frequencies and provide only
On 06/09/18 17:59, Olof Johansson wrote:
> Hi,
>
> On Thu, Sep 06, 2018 at 04:10:39PM +0100, Sudeep Holla wrote:
>> Firmware can provide zero as values for sustained performance level and
>> corresponding sustained frequency in kHz in order to hide the actual
>> frequencies and provide only
On Thu 06-09-18 09:09:46, Dave Hansen wrote:
[...]
> Has anyone ever seen a single in-the-wild report from this mechanism?
Yes. See the list from Pavel. And I wouldn't push for it otherwise.
There are some questionable asserts with an overhead which is not
directly visible but it just adds up.
On Thu 06-09-18 09:09:46, Dave Hansen wrote:
[...]
> Has anyone ever seen a single in-the-wild report from this mechanism?
Yes. See the list from Pavel. And I wouldn't push for it otherwise.
There are some questionable asserts with an overhead which is not
directly visible but it just adds up.
On 9/6/2018 10:03 AM, Olof Johansson wrote:
On Thu, Sep 06, 2018 at 09:58:54AM -0700, Santosh Shilimkar wrote:
Hi Arnd, Olof,
On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Platform data pointer may be NULL. We check it everywhere but in one
place. Fix it.
Fixes:
On 9/6/2018 10:03 AM, Olof Johansson wrote:
On Thu, Sep 06, 2018 at 09:58:54AM -0700, Santosh Shilimkar wrote:
Hi Arnd, Olof,
On 9/6/2018 5:12 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Platform data pointer may be NULL. We check it everywhere but in one
place. Fix it.
Fixes:
801 - 900 of 1950 matches
Mail list logo
